Solutions for SQL Injection

Developers and administrators can take a number of different steps in order to solve the SQL injection problem.

These are some solutions for developers:

•  Filter all input fields for apostrophes (’) to prevent unauthorized logins.

•  Filter all input fields for SQL commands like insert, select, union, delete, and exec to prevent server manipulation. (Make sure you do this after filtering for the apostrophes.)

•  Limit input field length (which will limit attackers’ options), and validate the input length with server-side scripts.

•  Use the option to filter “escape characters” (characters that can be used to inject SQL code, such as apostrophes) if the database offers that function.

•  Place the database on a different computer than the web server. If the database is hacked, it’ll be harder for the attacker to reach the web server.

•  Limit the user privileges of the server-side script. A common practice is to use the administrative user when logging in from the server-side script to the database, but this can allow an attacker to run database tasks (such as modifying tables or running stored procedures) that require the administrative user. Assign a user with minimal privileges for this purpose.

•  Delete all unneeded extended stored procedures to limit attackers’ possibilities.

•  Place the database in a separate container (behind a firewall), separated from the web container and application server.

Unlike developers, the administrator has no control over the code and can’t make changes on behalf of the programmers. However, the administrator can mitigate the risks by running some tests and making sure that the code is secure:

•  Make sure the web server returns a custom error page. This way, the server won’t return the SQL error, which will make it harder for the attacker to gain data about the SQL query. (A custom error page should not contain any information that might aid the attacker, unlike the regular error page, which will return part of the SQL statement.)

•  Deploy only web applications that separate the database from the web server.

•  Hire an outside agency to perform penetration tests on the web server and to look for SQL injection exploits.

•  Use a purpose-built automated scanning device to discover SQL injection exploits that result from programmers’ mistakes.

•  Deploy security solutions that validate user input and that filter SQL injection attempts.