Practical Identification of Sql Injection Vulnerabilities
Practical Identification of SQL Injection Vulnerabilities
Chad Dougherty
Background and Motivation
The class of vulnerabilities known as SQL injection continues to present an extremely high risk in the current network threat landscape. In 2011, SQL injection was ranked first on the MITRE Common Weakness Enumeration (CWE)/SANS Top 25 Most Dangerous Software Errors list.1 Exploitation of these vulnerabilities has been implicated in many recent high-profile intrusions. Although there is an abundance of good literature in the community about how to prevent SQL injection vulnerabilities, much of this documentation is geared toward web application developers. This advice is of limited benefit to IT administrators who are merely responsible for the operation of targeted web applications. In this document, we will provide concrete guidance about using open source tools and techniques to independently identify common SQL injection vulnerabilities, mimicking the approaches of attackers at large. We highlight testing tools and illustrate the critical results of testing.
SQL Injection
Causes
Simply stated, SQL injection vulnerabilities are caused by software applications that accept data from an untrusted source (internet users), fail to properly validate and sanitize the data, and subsequently use that data to dynamically construct an SQL query to the database backing that application. For example, imagine a simple application that takes inputs of a username and password. It may ultimately process this input in an SQL statement of the form string query = "SELECT * FROM users WHERE username = " '" + username + " ' AND password = '" + password + " '";
Since this query is constructed by concatenating an input string directly from the user, the query behaves correctly only if password does not contain a single-quote character. If the user enters
1
http://cwe.mitre.org/top25/archive/2011/2011_cwe_sans_top25.html
1
© 2012 Carnegie Mellon University.
Chad Dougherty
Background and Motivation
The class of vulnerabilities known as SQL injection continues to present an extremely high risk in the current network threat landscape. In 2011, SQL injection was ranked first on the MITRE Common Weakness Enumeration (CWE)/SANS Top 25 Most Dangerous Software Errors list.1 Exploitation of these vulnerabilities has been implicated in many recent high-profile intrusions. Although there is an abundance of good literature in the community about how to prevent SQL injection vulnerabilities, much of this documentation is geared toward web application developers. This advice is of limited benefit to IT administrators who are merely responsible for the operation of targeted web applications. In this document, we will provide concrete guidance about using open source tools and techniques to independently identify common SQL injection vulnerabilities, mimicking the approaches of attackers at large. We highlight testing tools and illustrate the critical results of testing.
SQL Injection
Causes
Simply stated, SQL injection vulnerabilities are caused by software applications that accept data from an untrusted source (internet users), fail to properly validate and sanitize the data, and subsequently use that data to dynamically construct an SQL query to the database backing that application. For example, imagine a simple application that takes inputs of a username and password. It may ultimately process this input in an SQL statement of the form string query = "SELECT * FROM users WHERE username = " '" + username + " ' AND password = '" + password + " '";
Since this query is constructed by concatenating an input string directly from the user, the query behaves correctly only if password does not contain a single-quote character. If the user enters
1
http://cwe.mitre.org/top25/archive/2011/2011_cwe_sans_top25.html
1
© 2012 Carnegie Mellon University.
References: [1] The Open Web Application Security Project (OWASP). “SQL Injection.” Last updated December 6, 2011. Available from https://www.owasp.org/index.php/SQL_Injection (accessed June 28, 2012). [2] Provos, Niels. “Lizamoon SQL Injection Campaign Compared.” April 3,2011. Available from http://www.provos.org/index.php?/archives/92-Lizamoon-SQL-Injection-CampaignCompared.html (accessed June 28, 2012). [3] Hipolito, J. M. “LizaMoon, Etc. SQL Injection Attack Still Ongoing.” March 32, 2011. http://blog.trendmicro.com/lizamoon-etc-sql-injection-attack-still-on-going/ (accessed June 28, 2012). [4] US-CERT/NIST. National Vulnerability Database, CVE-2008-1982. Last revised March 11, 2011. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-1982 (accessed June 28, 2012). [5] US-CERT. “SQL Injection” [background paper]. 2009. Available from http://www.uscert.gov/reading_room/sql200901.pdf (accessed June 28, 2012). [6] The Open Web Application Security Project (OWASP). “Guide to SQL Injection” [SQLi avoidance]. Last modified September 6, 2010. https://www.owasp.org/index.php/Guide_to_SQL_Injection (accessed June 28, 2012). [7] The Open Web Application Security Project (OWASP). “SQL Injection Prevention Cheat Sheet.” Last modified March 29, 2012. https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet (accessed June 28, 2012). [8] Friedl, Steve. “SQL Injection Attacks by Example.” Last modified October 10, 2007. Available from http://www.unixwiz.net/techtips/sql-injection.html (accessed June 28, 2012). 15