SQL injection attacks are executed via front-end Web applications that don't properly validate user input. Malformed SQL queries, including SQL commands, can be inserted directly into Web URLs and return informative errors, commands being executed and more. These attacks can be carried out manually -- if you have a lot of time. Once I discover that a server has a potential SQL injection vulnerability, I prefer to perform the follow-through using an automated tool, such as SPI Dynamics' SQL Injector
 |
SPI Dynamics' SQL Injector tool automates the SQL injection process.
|
7. Blind SQL injection
These attacks go about exploiting Web applications and back-end SQL Servers in the same basic fashion as standard SQL injection. The big difference is that the attacker doesn't receive feedback from the Web server in the form of returned error messages. Such an attack is even slower than standard SQL injection given the guesswork involved. You need a good tool for this situation, and that's where Absinthe, shown in Figure 4, comes in handy.
 |
| Absinthe tool takes the pain out of blind SQL injection testing. | |
8. Reverse engineering the system
The reverse engineering trick looks for software exploits, memory corruption weaknesses and so on. In this sample chapter from the excellent book Exploiting Software: How to Break Code by Greg Hoglund and Gary McGraw, you'll find a discussion about reverse engineering ploys.
9. Google hacks
Google hacks use the extraordinary power of the Google search engine to ferret out SQL Server errors -- such as "Incorrect syntax near" -- leaking from publicly accessible systems. Several Google queries are available at Johnny Long's Google Hacking Database. (Look in the sections titled Error Messages and Files containing passwords.) Hackers use Google to find passwords, vulnerabilities in Web servers, underlying operating systems, publicly available procedures and more that they can use to further compromise a SQL Server system. Combining these queries with Web site names via Google's 'site:' operator often turns up juicy info you never imagined you could unearth.
10. Perusing Web site source code
Source code can also turn up information that may lead to a SQL Server break in. Specifically, developers may store SQL Server authentication information in ASP scripts to simplify the authentication process. A manual assessment or Google could uncover this information in a split second.