SQL Injection
SQL Injection describes malicious attacks that introduce unintended SQL commands via application input codes. SQL Injection attacks continue at epidemic proportions.
In April of 2008 a large number of well known and previously trusted web sites were infected with malicious JavaScript via SQL Injection resulting in subsequent infection to the visitors at those sites. After much finger pointing and a resurgence of the 'sky is falling' rumors, there was little that could be done by software vendors or Internet security organizations to abate the attack. Restoring from the last kown good backup was the recommended solution for the infected sites. The public was advised by US-CERT to disable JavaScript and ActiveX.
In 2011 it became obvious to anyone looking critically at the situation that expensive compliance actions to meet codified standards of government and business were woefully ineffective in preventing SQL injection and variants of cross-site scripting that rely upon codes injected into a column as valid data of a dynamically generated web site.
Purpose (High level description ot explaination)
Prevention is the key to elimination of SQL Injection. This is achieved though good software design, development and testing practices. Stopping a SQL Injection attack in progress is a lot like trying to catch thunderbolts.
Fundamentals (Principles and skills requires)
SQL Server Administrator's must rely upon developer's skill and diligence combined with code review to identify code suseptable to SQL Injection to avoid SQL Injection attacks.
Dependencies (external factors that must be considered)
legacy web pages, coding standards, developer training
Best Practices (preferred strategic and tactical activities)
Always validated user supplied data in the application immediately after input.
Never display validation failure details (or any database or other backend server errors) to the application user. It may be more secure to contrive a false positive than to raise any exception when protecting against SQL injection.
Ensure type safety by using only prepared statements or stored procedures to access the database from the application.
Do not allow queries to be dynamicaly built from unvalidated or unverified user input.
Secure direct table access from the application code using principle of least privledge.
Monitor Web/Appliction logs for SQL Injection like activity.
Test for SQL Injection.
Give every user exactly (and only) the permissions required.
In an ORM based application and rules that create incompatiblilties between the ORM and the database must instead be enforeced betwqeen the ORM and application.
How-to (heuristic activities)
SQL Injection Code Review
Use search the application source, and search the application's stored procedure collection to identify any query that:
is not prepared (e.g. CommandType = Text in ADO/ADO.NET or
submit SELECT, INSERT, UPDATE or DELETE statements sent directly from the application
dynamically build queries or parts of queries
invoke the EXEC(<query>) or sp_executesql <query> T-SQL commands
Review the database
Devise a plan to eliminate or harden all occurences
SQL Injection Monitoring
Watch web logs for exploit attempts
Enable SQL Server Audit Logging and watch for failed login attempts
Frequently check the SQL Instance for changed objects
Alternatives (descriptive information and explainations concerning approachs other than best practices)
Relying on new technologies for SQL Injection protect is a slippery slope. Newer technolgies are under great pressure to maintain backward comptabilities, improved usability and get the release out the door. In some undetermined subset of the backward compatible feature set and the current design, the ability to produce code vulnerable to SQL Injection remains. Unless the developers are equipped with the training and tools to avoid the vulnerabilities, the risk remain quite high.
There are many web site security consultancies and software packages that can identify SQL Injection vulnerabilities. In too many cases, identifying SQL Injection vulnerabilities is comically easy. Fixing them is more often not so easy. Planning for SQL inject prevention is more effective. Therefore educating developers is the real need. Otherwise, after the consultant finishes the analitics, new vulnerabilities will be introduced. Similarly, sophisticated hackers will also have access to any commercial software packages that identify vulnerabilities, sometimes giving them another avenue of discovery for developing and testing exploits that get pasts the limitations of the software.
Consistent with most other hacking activities, SQL Injection attacks at this time are often sophisticated and ingenious. As a Consequence, attemps to anticipate hacker tactics seldom bear fruit. Furthernmore, as the transparent defences agains SQL Injection evolve, so do the capabilitie of the hackers.
The most viable long term alternative is to modify and test the application to prevent SQL Injection before an attack rather than to continue to engage in any variation of the never-ending and inefficient patch and release cycles that tend to shift the problem rather than actually solve it. Additionally, if SQL Injection protection is left as a post-release activity in any form, the likelyhood that an attack occurs before the software lifecycle was 'ready' for it is increased.
More Information