Addressing Input Sanitization Bugs and CVE 2021-21321

What is a sufficient number of packages for a javascript package manager to have? Thousand? Ten thousand?

On June 4th, npm indexed its millionth package into its public registry. When starting a development project, there are many packages to choose from. However, one must be mindful of their security implications. The security incident of the npm package event-stream is one example of why this is very important.

Upon investigating an issue raised on event-stream’s GitHub repository, it was discovered that event-stream’s package contained a malicious package named

flatmap-stream

. The event-stream package was very popular and helpful. It had almost 2 million downloads every week. This meant that the malicious package flatmap-stream had been downloaded over 8 million times.

Other than malicious actors using legitimate popular packages to deliver their malware, vulnerabilities being part of packages is a serious issue that has the potential to compromise your application and user data. 

CVE 2021-21321 indicates a vulnerability in the

fastify-reply-from

package. This is a fastify plugin to forward current HTTP requests to another server. In a scenario where a developer has set up a proxy server on the directory

/pub

, they will expect that a user will not access a private directory, i.e.,

/private

.

As the bug mentioned above is an input sanitization bug, an attacker can pass a specially crafted URL to bypass the package’s mechanism and access the private directory. As per the package’s GitHub changelog, this bug was fixed in version 4.0.2 of the package.

You can find more details about CVE 2021-21321 and other vulnerabilities through the WhiteSource Vulnerability Database, which is what I used for this. The database is a free service that provides valuable information that we can use to learn more about vulnerability. It covers over 200 programming languages and vulnerabilities collected from a wide variety of resources. For each vulnerability, the database provides not just vulnerability details such as severity, weakness type, additional resources but also suggests a top fix that can help you make your application secure.

As we can see, it is an input validation vulnerability, and its severity score is 10.0. This means it has a critical bug. One should not use the

fastify-reply-from

package.

We can also see that this bug’s results concerning all three elements of the CIA triad—confidentiality, integrity, and availability—show that it is highly compromising and should be fixed.

Input sanitization bugs are very common in web applications. Instead of verifying the user input first, if the user input is directly processed, it can lead to input sanitization bugs.

As per OWASP Top 10, injection attacks are the top most common attacks on web applications. An injection attack is the result of improper or no input sanitization. One such injection attack is SQL injection.

SQL injection has been around for more than two decades. Yet, it is even now common to see websites vulnerable to SQL injection.

SQL injection is possible when user input is passed to the database without performing proper checks.

Consider the following login page for an application: 

This login page does not have any input sensitization in place.

Therefore, when a user enters a username and password into the form and logs in, the backend transforms it into an SQL query that is directly passed to the database.

If the username is entered as [email protected] and password as test123, the following query will be generated.

Select * FROM users where username=’[email protected]’ AND password=’test123’.

If there is a user account “[email protected]” with the password “test123”, the database will return the user account’s records.

But, as there is no input sanitization in place, an attacker can take advantage of this situation to log in without a password.

In SQL, characters “--” are treated as special characters. If there are two minus signs (--) in a query, anything after these is considered a comment and is not passed to the database.

So, instead of entering a username and password, the attacker can just enter ‘[email protected]--’ as the username and enter any random characters in the password field.

Now, the query generated by the backend would be,

SELECT * FROM users where username=’[email protected]’ OR 1 = 1 ‘ -- AND PASSWORD=’asd’

As you can see, the ‘ (quote) passed by the attacker has been used to end the username field in the query, and “OR 1 = 1 --” has been appended to the query and passed to the database.

Due to the “--” characters, the database will ignore anything coming after “--”. So, the database will let the attacker log into the website as the first user without specifying the correct username or password.

One possible way to prevent SQL injection is to properly sanitize the user input before processing it into the database.

For example, developers can put proper constraints on the user input, such as user input length should be within a specified range, it should not contain special characters, etc.

The use of prepared statements while writing an SQL query can also help prevent unauthorized access to the database.

Another common injection attack is cross-site scripting, also known as XSS. Unlike SQL injection, this attack can be performed in the victim’s browser. In XSS, attackers take advantage of improper input sanitization in a web application to inject malicious Javascript code into the website.

Consider the following scenario: a website takes a user’s message by performing a GET request and processes it.

Consider a scenario in which an attacker injects their malicious script into a website that does not have proper input sanitization in place. If a user now visits the vulnerable website, his browser would automatically download the injected malicious script and execute it on the victim’s browser.

This can lead to many more potential compromises. If the page injected with the malicious code is a checkout page or payment page, attackers can compromise many users’ payment details. The injection of a malicious script inside a webpage to steal data is called a formjacking attack.

Generally, websites use cookies to store session data for users. If there is a stored XSS vulnerability in a website, attackers can leverage that to fetch cookies of users, which can eventually compromise user accounts.

According to Forbes, over 30,000 websites are hacked daily. This underlines the importance of developing a secure web application. But in addition to compromises, many vulnerabilities are made public by various vulnerability databases such as the WhiteSource Vulnerability database. In addition to implementing multiple security solutions and checks, keeping an eye on the security of the components on vulnerability databases can help you detect potential vulnerabilities that can be fixed before attackers can take advantage of them.