The most common type of code injection is SQL injection. In an SQL injection attack, you can modify one or more of the four basic functions of SQL querying (selecting, inserting, deleting, and updating data) by embedding code in some input within the web app, causing it to execute your own set of queries using SQL.

To identify SQL injection vulnerabilities in a web app, you should test every single input to include elements such as URL parameters, form fields, cookies, POST data, and HTTP headers. The simplest and most common method for identifying possible SQL injection vulnerabilities in a web app is to submit a single apostrophe and then look for errors. If an error is returned, you can see if it provides you with SQL syntax details that can then be used to construct a more effective SQL injection query.

To see this in action, consider the following SQL query that selects a user name and password from the database:

SELECT * FROM users WHERE username = 'Bob' AND password 'Pa22w0rd'

In the user name field of the login form, you insert an apostrophe and select the submit button. Without proper input validation, the SQL query might be submitted as:

SELECT * FROM users WHERE username = ''' AND password 'Pa22w0rd'

Because the apostrophe is not a valid input for the username field, the server may respond with an error and reveal its query format or other useful information about the database, including column names. The response might also reveal where you can inject opening or closing parentheses into the query to properly complete its syntax.

Another way to execute a syntactically correct query is to use a value that is always true, such as 1=1, and then use the built-in capability to insert inline comments within the query by inputting the -- characters. SQL will ignore anything following these comment characters. So, to put it together, you enter the string ' or 1=1-- into the user name field. The SQL query is as follows:

SELECT * FROM users WHERE username = '' or 1=1--' AND password 'Pa22w0rd'

The SQL syntax is now correct, and the database will not return an error if this SQL statement is sent to it. Instead, the database will return all user rows, since the 1=1 statement is always true. Everything after the -- comment characters will not execute.

Certain web app APIs also allow you to stack multiple queries within the same call. This can be useful for injecting new query types into a form's existing query type. For example, SQL has a UNION operator that combines the results of two or more SELECT statements. You can use this operator to obtain data from other tables that might not be directly exposed by the app.

For example, let's say you have a product search form that you've probed for SQL injection weaknesses. You could perform the following query on the search form to try to merge the users table with the products table, looking for the first two values from users:

UNION SELECT '1', '2' FROM users--

However, UNION operations only work when both queries (i.e., the initial SELECT from products and the UNION SELECT from users) have the same number of columns. So, if the products table has five columns, you need to adjust your injection to include them:

UNION SELECT '1', '2', '3', '4', '5' FROM users--

These queries are using placeholder values, whereas you may need to provide the actual columns names of the table you're trying to merge. For example, you might want to display the username and password columns:

UNION SELECT '1', username, password, '4', '5' FROM users--

This will merge the user name and password fields of each row of the users table into the search page, replacing the second and third columns with the credentials.

Note: There are many more SQL injection methods than the ones discussed here. For a more exhaustive list, navigate to www.owasp.org/www-community/attacks/SQL_Injection

Check out the SQLMap post for automated attacks:

SQLMap
Shallow dive into an automated tool for SQL Injection