SQL Injection is a common type of web database related vulnerability. SQL injection is common to web site applications that interact with a database backend. These sites construct SQL commands or queries based on user input. For example they might search a product database based on a description a user typed in a web form. An application is vulnerable to SQL injection when it builds SQL queries without filtering the user's input, without using store procedure, or without binding parameters variables. This can lead to an attacker adding additional clauses, conditions, or even commands that execute along the original query. Attackers can use SQL Injection bugs to execute different types of attacks such as data theft and tampering, authentication bypass, information disclosure, and elevation of privileges.
Below is a summary of steps needed for testing for SQL injection bugs
- Step 1: Understand SQL injection attack scenarios
- Step 2: List high risk components and entry points
- Step 3: Start testing and exploring
- Step 4: Tune of test data
The next step for SQL Injection testing is to list all the places where code builds SQL statements from user supplied input; to understand how and where our application manipulates statement and talks to a database. The most common are:
- Search web pages
- Profile-related web pages
- Authentication forms
- E-Commerce or financial account-related pages
- Database interaction public API's and DCOM methods
- Database system-level clients
Identify all high risk components
After understanding the details of SQL Injection, list their high risk components in a table that includes the method that hosts the code, the name of the query string if available, and the variable names that influence the construction of the query
Look at code like the one shown in the scenarios above; code where SQL statements are built using web input. Then list all of these web pages as high risk components.
Match High Risk Components with Entry Points
After listing all areas in the application where SQL statements are built at run-time, you must identify the ways in which data gets to these places. For example, you listed a web page named "search.asp" above that constructs SQL statements dangerously. Here you list how this page gets its input; what are its entry points. Keep in mind that entry points can be both intended (expected by the program or application) and unintended (unexpected by program or application). A common list of entry points for SQL injection high risk components include:
- URL bar contents
- Web form input values
- Web service methods
- Network packets
- Public API's
- DCOM methods
- Application UI text fields
- Inter Process Communication pipe
The first three are the most common entry points for web services and application. Nonetheless, always look for new entry points additional entry points not listed here. Make sure that the data manipulated by the component at risk is not passed by any other means.
Ideally by the end of step 2 you will have a table like the one shown above to systematically guide test execution.
