Injection occurs when a malicious user is able to modify the query or a command sent to an operating system, database or any interpreter. SQL injection and command injection attacks are the most common ones. Both of these flaws exist due to poor input validation, where the application and the web server both fail to strip the user input of all malicious data before executing it on the server.
At times, the web application may require the help of the underlying operating system to complete certain tasks. For example, the application may want to display the contents of a file saved on the server back to the user, and the web application may invoke a call to the shell to retrieve the contents of the file. This may reduce the development time of the application, as the developer won't have to write separate functions. If the input from the user is not properly validated, it may become a candidate for a command injection flaw.
In an application vulnerable to command injection flaw, the attacker may try to insert shell commands along with the user input, with the hope that the server would run the commands. The shell commands would then run with the privileges same as that of the web server. The vulnerable application may or may not display the output of the command back to the attacker. If it does not display the output, it is known as blind command injection and the attacker will have to use other techniques to determine if the commands indeed ran or it was just a false positive. A trick that is often used by malicious as well as white hat hacker is to invoke a reverse TCP connection using a shell command in the vulnerable field of the target application and then wait for a connection to be initiated from the web server to your machine.
Like most web application flaws, the success of finding a command injection flaw depends a lot on the skills of the attacker and their imagination of using different commands in the input field.
As shown in the following screenshot, in a vulnerable application, an additional command was injected using && and a listing of all files in the folder was displayed, along with the actual resolution of the DNS name:
A web application is incomplete without a backend database. When interacting with the end user, the application will have to pull data from the database as requested by the user. The most common method to interact with the database is by using SQL. Poorly written web applications will build the SQL statement by combining it with the user input. If the input from the user is not carefully validated, the attacker could enter SQL statements via the user input, which is then passed to the backend database for processing.
In order to exploit a SQL injection flaw, we need to first identify the input fields in the application. Input to the application is not limited to form fields where a user enters information. An attacker can edit cookies, headers, or XML requests to submit malicious data back to the server; if the application builds the SQL query by using this data, you can trick the database to reveal data of other users. Every variable or field needs to be tested to see if the application behaves in a different way.
The response from the server will help you identify the database type. As an attacker, we are interested in the error messages from the server when it encounters a malicious input. The error message helps us reach two conclusions; it reveals the database type and also gives us an indication that the application may be vulnerable to a SQL injection flaw.
The following screenshot shows the example of an error message from the Microsoft SQL database:
The following screenshot shows the example of an error message from the MySQL database:
An error message does not guarantee that the server is vulnerable to a SQL injection flaw, but as an attacker, it will make your life easier. The manual method to discover a flaw is by using a proxy such as Burp, Paros, or ZAP and injecting data in the various fields. Tamper data and SQL Inject me are two well-known Firefox extensions that are very useful when testing input fields in the form for SQL injection flaws.
A dedicated attacker would be interested in querying the database in a more detailed way. They might want to identify the names of tables and columns to steal sensitive data. The metadata table stores the information about user defined tables and columns. If an attacker is successful in querying the metadata table, they can use the information obtained to pull information from user defined tables that store that may contain the actual sensitive client information. The SQL injection attack is not limited to extracting information from the database; it can also be used to write data and also perform command injection on the underlying operating system.
An illustration of the SQL injection flaw is shown in the following diagram:
I have dedicated the entire Chapter 5, Attacking the Server Using Injection-based Flaws, to injection flaws, and we will discuss the tools used to exploit such flaws and go through the entire methodology used to attack these flaws. This chapter will only provide you an overview of the injection flaws.