Blind SQL Injection
by: Kevin Spett, 10/26/2004
http://www.securitydocs.com/library/2651
Introduction
The World Wide Web has experienced remarkable growth in recent years. Businesses, individuals, and
governments have found that web applications can offer effective, efficient and reliable solutions to the
challenges of communicating and conducting commerce in the Twenty-first century. However, in the
cost-cutting rush to bring their web-based applications on line — or perhaps just through simple
ignorance — many software companies overlook or introduce critical security issues.
To build secure applications, developers must acknowledge that security is a fundamental component of
any software product and that safeguards must be infused with the software as it is being written.
Building security into a product is much easier (and vastly more cost-effective) than any post-release
attempt to remove or limit the flaws that invite intruders to attack your site. To prove that dictum,
consider the case of blind SQL injection.
What is Blind SQL Injection?
Let’s talk first about plain, old-fashioned, no-frills SQL injection. This is a hacking method that allows
an unauthorized attacker to access a database server. It is facilitated by a common coding blunder: the
program accepts data from a client and executes SQL queries without first validating the client’s input.
The attacker is then free to extract, modify, add, or delete content from the database. In some
circumstances, he may even penetrate past the database server and into the underlying operating
system.1
Hackers typically test for SQL injection vulnerabilities by sending the application input that would
cause the server to generate an invalid SQL query. If the server then returns an error message to the
client, the attacker will attempt to reverse-
engineer portions of the original SQL query using information
gained from these error messages. The typical administrative safeguard is simply to prohibit the display
of database server error messages. Regrettably, that’s not sufficient.
If your application does not return error messages, it may still be susceptible to “blind” SQL injection
attacks.
Detecting Blind SQL Injection Vulnerability
Web applications commonly use SQL queries with client-supplied input in the WHERE clause to
retrieve data from a database. By adding additional conditions to the SQL statement and evaluating the
web application’s output, you can determine whether or not the application is vulnerable to SQL
injection.
For instance, many companies allow Internet access to archives of their press releases. A URL for
accessing the company’s fifth press release might look like this:
http://www.thecompany.com/pressRelease.jsp ?pressReleaseID=5
Page
1
of
6
2/4/2005
http://www.securitydocs.com/link.php?action=detail&id=2651&headerfooter=no
