SQL Injection describes malicious attacks that introduce unintended SQL commands into UI data input fields. 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.
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 database errors to the web user.
Use only prepared (type safe parameters) stored procedures to access the database from the application.
Do not allow queries to be dynamicaly built from user input.
Do not allow direct table access from the application code.
Monitor Web/Appliction logs for SQL Injection like activity.
Test for SQL Injection.
Give every user exactly (and only) the permissions required.
How-to (heuristic activities)
SQL Injection Code Review
Use SQLTrace, 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
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
Alternatives (descriptive information and explainations concerning approachs other than best practices)
Relying on new technologies such as .ASP 2.0 for SQL Injection protect is a slippery slope. Newer technolgies are under great pressure to maintain backward comptabilities. In some undetermined subset of the backward compatible feature set, 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 remains.
There are many web site security consultancies and software packages that can identify SQL Injection vulnerabilities. In most cases, identify SQL Injection vulnerabilities is comically easy. 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, giving them an avenue 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.