This is Part I of a serialization of a paper I have written on the SQL Injection defenses. As portions of the paper are finished I will post them on this blog. Topics will include a discussion on access control, security models, classification of attacks, and intrusion detection techniques.
SQL injection is a technique often used to exploit database systems through vulnerable web applications. The techniques allows the attacker to not only steal the entire contents of relational databases but also, in many cases, to make arbitrary changes to the both the database schema and contents. Relational database server products have no mechanism to deal with SQL inject as the problem is rooted not in the database server itself but in vulnerable applications with excessive privileges granted to users. In most cases a victim of a SQL injection attack does not even know that information is compromised until long after the attack has passed, perhaps through an angry e-mail from a customer who found his credit card number was stolen or from the attacker himself seeking some form of blackmail, or the victim might never realize that their database system has been compromised. While the details of SQL injection attacks vary from implementation to implementation all relational database systems on all platforms, both commercial and open source, are potentially susceptible to attack.
Most SQL injection attacks are executed through an application that takes user-supplied input for query parameters. The attacker supplies carefully a crafted string to form a new query with results very different than what the application developer intended. For example, consider a script on a website that takes a search parameter to return selected results from a database. A very simple attack may be possible by simply providing something like “1 OR 1=1” in the text field which causes the SQL server to return all records from a particular table. An attacker can often gain access to anything available with the script’s privileges, which in many cases is full access to one or more databases.
While SQL injection attacks could be be executed against any application, web applications are the most commonly vulnerable since the attacker can easily explore a site for vulnerabilities without being caught or having to work through sophisticated network intrusion techniques as most prospective targets leave their website applications wide open. Firewalls and traditional network intrusion detection systems are useless against SQL injection since it is an application exploit that in most cases is indistinguishable from expected use. Some signature-based detection systems have been developed for web servers to protect vulnerable scripts from malicious input. However, these signature-based systems are inherently susceptible to evasion methods that take advantage of the expressiveness of the SQL language or alternate character encodings. Remarkably, writing scripts that are not vulnerable to SQL injection is as simple as passing all user-provided text through a string escaping function prior to use as a parameter in a SQL statement, but as past experience has shown, vulnerable scripts are everywhere to be found.
SQL injection affects every database on every platform. Attacks can be used to gain information disclosure, to bypass authentication mechanisms, to modify the database, and to, in some cases, execute arbitrary code on the database server itself!
- “SQL Injection: Are Your Web Applications Vulnerable?” SPI Dynamics.
- “Blind SQL Injection: Are Your Web Applications Vulnerable?” SPI Dynamics.
- “Blindfolded SQL Injection” by Ofer Maor and Amichai Shulman. Imperva.
- “SQL Injection Signatures Evasion: An overview of why SQL Injection signature protection is just not enough.” Imperva.