A SQL Injection vulnerability is a type of security hole that is found in a multi-tiered application; it is where an attacker can trick a database server into running an arbitrary, unauthorized, unintended SQL query by piggybacking extra SQL elements on top of an existing, predefined query that was intended to be executed by the application. The application, which is generally, but not necessarily, a web application, accepts user input and embeds this input inside an SQL query. This query is sent to the application’s database server where it is executed. By providing certain malformed input, an attacker can manipulate the SQL query in such a way that its execution will have unintended consequences.
This all sounds like a bit of a mouthful – one that can be more easily swallowed with an example.
Consider an online bookstore. This bookstore’s web server allows users to search for books by a given author. This search facility is implemented by querying a list of book titles in a backend database server limited by who (or what) the user enters as the author. This search functionality happens to be vulnerable to SQL injection. Instead of returning a list of book titles, by exploiting the vulnerability an attacker can trick the application into returning a list of all usernames, passwords, email addresses and credit card numbers of everyone that has ever used the bookstore. This scenario is not sensationalist - it's an easy attack that can be leveled against a SQL injection vulnerability.
In terms of risk, SQL injection is right up there at the top with problems like buffer overflows. I recently had an argument with a large database software vendor about this. They rated SQL injection problems as a low risk issue and were greatly more concerned with buffer overflows in their RDBMS offering. I pointed out to them that to exploit a buffer overflow in the database server one must first get past the organization’s firewall. A nice easy way of doing this is through SQL injection: the firewall must allow inbound connections to the web server from the Internet so customers can access the web application; and if the application is vulnerable to SQL injection then the attacker can get access to the database and exploit the buffer overflow vulnerability. But here’s the kicker – why would an attacker bother exploiting the buffer overflow vulnerability if they can arbitrarily gain access to the data in the database anyway? Since this discussion, I’m glad to report that the large database software vendor has since “upgraded” the status of SQL injection vulnerabilities and give them the respect they’re due. In terms of prevalence, 6 in 10 web applications that connect to a database server are vulnerable to SQL injection. This statistic is based upon the number of new applications that were found to be vulnerable when performing security assessments for clients over 2003/2004. This is shockingly high.
SQL injection is vendor agnostic: it doesn’t matter whether the application is running Oracle, SQL Server, DB2, MySQL or Informix on Active/Java Server Pages, Cold Fusion Management, PHP or Perl – it can be vulnerable to SQL injection – though, as we’ll see later, some are more at risk that others.
This all sounds like a bit of a mouthful – one that can be more easily swallowed with an example.
Consider an online bookstore. This bookstore’s web server allows users to search for books by a given author. This search facility is implemented by querying a list of book titles in a backend database server limited by who (or what) the user enters as the author. This search functionality happens to be vulnerable to SQL injection. Instead of returning a list of book titles, by exploiting the vulnerability an attacker can trick the application into returning a list of all usernames, passwords, email addresses and credit card numbers of everyone that has ever used the bookstore. This scenario is not sensationalist - it's an easy attack that can be leveled against a SQL injection vulnerability.
In terms of risk, SQL injection is right up there at the top with problems like buffer overflows. I recently had an argument with a large database software vendor about this. They rated SQL injection problems as a low risk issue and were greatly more concerned with buffer overflows in their RDBMS offering. I pointed out to them that to exploit a buffer overflow in the database server one must first get past the organization’s firewall. A nice easy way of doing this is through SQL injection: the firewall must allow inbound connections to the web server from the Internet so customers can access the web application; and if the application is vulnerable to SQL injection then the attacker can get access to the database and exploit the buffer overflow vulnerability. But here’s the kicker – why would an attacker bother exploiting the buffer overflow vulnerability if they can arbitrarily gain access to the data in the database anyway? Since this discussion, I’m glad to report that the large database software vendor has since “upgraded” the status of SQL injection vulnerabilities and give them the respect they’re due. In terms of prevalence, 6 in 10 web applications that connect to a database server are vulnerable to SQL injection. This statistic is based upon the number of new applications that were found to be vulnerable when performing security assessments for clients over 2003/2004. This is shockingly high.
SQL injection is vendor agnostic: it doesn’t matter whether the application is running Oracle, SQL Server, DB2, MySQL or Informix on Active/Java Server Pages, Cold Fusion Management, PHP or Perl – it can be vulnerable to SQL injection – though, as we’ll see later, some are more at risk that others.
No comments:
Post a Comment