SQL Injection Attack

From Guidance Share
Jump to navigationJump to search


A SQL injection attack exploits vulnerabilities in input validation to run arbitrary commands in the database. It can occur when your application uses input to construct dynamic SQL statements to access the database. It can also occur if your code uses stored procedures that are passed strings that contain raw user input. Using the SQL injection attack, the attacker can execute arbitrary commands in the database. The issue is magnified if the application uses an over-privileged account to connect to the database. In this instance it is possible to use the database server to run operating system commands and potentially compromise other servers, in addition to being able to retrieve, manipulate, and destroy data.


  • Sensitive data can be revealed to unauthorized parties
  • Data can be deleted from the database
  • Entire tables and databases can be dropped
  • Command shells can be launched from where additional attacks can be mounted

The capabilities of an attacker are constrained by the permissions of the account you use to connect to the database. For this reason, you should use an account that has minimal permissions in the database.


  • Weak input validation.
  • Dynamic construction of SQL statements without the use of type-safe parameters.
  • Use of over-privileged database logins.


  • Constrain input. Validate untrusted input against a whitelist. The whitelist defines the set of acceptable characters. This prevents special characters from being entered in a different format like hex. Use regular expressions to implement whitelist validation.
  • Use parameters with stored procedures or SQL statements. Parameterized SQL statements will accept characters that have special meaning to SQL (like single quote) without problems because they are strongly typed.
  • Use escaping routines. If you cannot use parameters and must use dynamic SQL, use escaping routines to handle special characters that have meaning to the database.
  • Use an account with limited permissions in the database. Ideally the account should only have execute permissions on the set of stored procedures that you application needs to use and it should have no direct table access.
  • Do not echo database errors. Catch exceptions on the server and return generic error messages to the client.

Attack Patterns


How Tos