Injection Vulnerabilities

Injection vulnerabilities refer to any type of security issue that allows an attacker to execute code on the target machine by crafting specific input data.

The general pattern for these attacks is the following:

• an attacker calls an application with crafted input data
• the input is either used immediately or saved for later
• the input is then used to build a command in another language like SQL, Javascript, OS scripting, XML, etc
• when the command is executed, due to the crafted input data, it injects an additional command that is executed with the permissions of the identity used by the application
• the result can be extraction of data, destruction of data, accessing other resources such as files stored on the server or network resources, installation of a malwareMalware, or malicious software, is a type of computer program designed to damage or disrupt a computer system. It can be spread through email attachments, downloads from the internet, and even USB drives. Researchers tend to classify malware into one or more sub-types (i.e. computer viruses, worms, Trojan horses, ransomware, spyware, adware, rogue software, wiper and keyloggers). etc.

Multiple defense mechanisms are needed against any security vulnerability. The defenses against the injection vulnerabilities include:

• using a Web Application Firewall (WAF)
• sanitizing all input data, including things you normally don’t think about like images, sound files, pdf files, video files etc.
• avoid using string concatenation in your code; use instead specific libraries that know how to correctly quote or encode the parameters such that they can’t be executed
• write specific automated tests that check for the common injection patterns
• review any piece of code that defers execution to another language against the possibility of injection attacks
• use HTTP Content Security Policy headers to limit the sources of client-side code execution

SQL Injection

The most known type of injection vulnerability is SQL injection. Imagine you use code as follows to search for a user:

For a normal username and password, this query works fine. Let’s see the resulting query for username 'admin' and password 'strong password 123#":

What if an attacker abuses the input to execute a different statement? For example username and empty password results in the following SQL statement:

Since '--' marks the beginning of a commentary in SQL, the statement executed is actually:

SELECT * FROM users where username = 'admin'Code language: JavaScript (javascript)

which returns the user with username "admin" without checking the password, thus enabling an attacker to login as the admin.

Another common technique is to inject in a SQL query code of the form , that effectively disables any condition from the WHERE statement. In the above example, using username and password “admin123” results in the SQL query:

This effectively runs the SQL statement:

SELECT * FROM users

thus allowing an attacker to potentially exfiltrate all the information from the users table, presumably including user names and (hopefully encrypted) passwords. Encrypted passwords can then be attacked with a dictionary attack, brute force etc. with a tool like John the Ripper, or just get sold at an auction.

SQL Injection can be used in a lot of ways. Here are the most common ones:

• Retrieving hidden data, by modifying a SQL query to return additional results. We can see an example with getting all the users instead of just one user
• Subverting application logic. We see this in practice in the example where the attacker logs in as the admin user
• Expanding the query to other tables. For example, by injecting a UNION statement, an attacker could retrieve data from any other table in the database
• Getting information about the database. By querying the database metadata, an attacker can find out information about the database engine version, database structure, database users etc.
• Blind vulnerabilities. These are harder to perform, since they don’t immediately return data. Instead, they can change the logic of the application, exfiltrate data through other means (eg. by DNS lookup for a domain controlled by the attacker), or using a conditional time delay
• Second order SQL injection. This attack uses existing ways to store data that is later used in SQL queries. For example, register a username that is an UPDATE sql query that changes the admin’s password to something the attacker knows; next time a login request happens the query is executed and allows the attacker to login as the admin.

Cross-Site Scripting (XSS)

Cross-site scripting is an injection vulnerability that takes advantage of the execution of Javascript inside a web page. Similarly with SQL Injection, an attacker injects Javascript code through an application input. The code is then executed in the context of a web page, either confusing the user into posting sensitive data, extracting information from a logged in user, or impersonating the user.

A simple test for a XSS vulnerability is to inject an alert or print statement in an input data. If this works, then any Javascript code is likely to be executed.

For example, try introducing this value in a form field:

Newer browser versions limit the calls to alert, so you may need to use print instead and verify the console output in your browser’s developer tools:

Another example of a canonical XSS vulnerability check is to use HTML fields:

XSS attacks can take advantage of encoding supported by HTML such as UTF-8 characters and base64. For example, a simple pattern matching validation for XSS can be avoided by using UTF-8 encoding of the letter ‘a’ as &\#X41:

For more examples, check out the OWASP XSS Filter Evasion Cheatsheet.

Three big types of XSS exist:

• Temporary: when the application includes data received in an HTTP request into the immediate response. This can be used to craft specific URLs that are shared with users who are then misled by a website they trust
• Stored: when the application saves unsafe data from an HTTP request and uses it later
• DOM-based: when the application uses unsafe data to create Javascript statements that modify the DOM

Other Injection Attacks

The same principle applies to other injection attacks. For example, if a web application builds an OS command to execute locally, crafting a specific payload can result in the command being executed as the user running the web application process. This can result in the extraction of data like uploaded files stored on disk and accessible to the web application. Alternatively, the attacker might find ways to send emails to user asking for specific details, directing them to a login or payment form, or giving them false information that looks like it’s coming from a trusted source.

Any user input can be exploited in this way. Image files for example can be eventually read by external libraries, for example for generating thumbnails. If the library has a vulnerability, a crafted image can be injected through an upload to a comment form for example, and install malwareMalware, or malicious software, is a type of computer program designed to damage or disrupt a computer system. It can be spread through email attachments, downloads from the internet, and even USB drives. Researchers tend to classify malware into one or more sub-types (i.e. computer viruses, worms, Trojan horses, ransomware, spyware, adware, rogue software, wiper and keyloggers). or access data from memory. See for example CVE-2016-8332, a 2016 vulnerability allowing injection of code through a JPEG-2000 image processed by the OpenJpeg library.

Same with sound files, email addresses, XML etc.