| ||
When reviewing code for SQL injection attacks, look for code that queries a database in the first place. Any code that does not perform database work obviously cannot have a SQL injection attack. We like to scan code looking for the constructs that load the database access code. For example:
Language | Key Words to Look For |
---|---|
VB.NET | SqlClient, OracleClient |
C# | SqlClient, OracleClient |
PHP | mysql_connect, |
Perl 1 | DBI, Oracle, SQL |
Java (including JDBC) | java.sql, sql |
Active Server Pages | ADODB |
C++ (Microsoft Foundation Classes) | CDatabase |
C/C++ (ODBC) | #include "sql.h" |
C/C++ (ADO) | ADODB, #import "msado15.dll" |
SQL | exec , execute, sp_executesql |
ColdFusion | cfquery |
1 A list of Perl database access technologies is available at http://search.cpan.org/modlist/Database_Interfaces |
Once you have determined the code has database support, you now need to determine where the queries are performed and determine the data trustworthiness used in each query. A simple way of doing this is to look for all the places where SQL statements are executed, and determine if string concatenation or replacement is used on untrusted data, such as that from a querystring, a web form, or a SOAP argument. In fact, any input used in the query for that matter!