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:
Multiple defense mechanisms are needed against any security vulnerability. The defenses against the injection vulnerabilities include:
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:
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:
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.