Avoiding SQL injection attacks

One of the reasons the web is so popular with attackers today is that innocent sites can be compromised and used to infect large numbers of victims. As I have commented previously [1], web sites/servers have proved to be fairly soft targets – something attackers have taken full advantage of. It is easy to think that the only victim of these attacks is the user, who gets exposed to malicious code when browsing compromised sites. However, there are two victims – in addition to the user, the owner/administrator of the site also suffers.

This is particularly apparent with the recent SQL injection attacks [2,3], in which back end databases are “peppered” with malicious code (in this case script tags). Clean up can be fairly painful, and there are numerous cases of folks cleaning up their database only to be hit again a few hours later. The best solution is prevention, to avoid being hit in the first place.

This blog post is intended to summarize a few tips that site owners/administrators/developers can follow in order to minimize their chance of being hit. Much of the information is already publicly available, (for example within or linked from the recent Microsoft advisory [4]).

1. Development best practice. SQL injection [5] is not new, attackers have been this technique for years. There have been numerous articles published in recent years providing resources to assist developers write secure code. More recently OWASP have brief guidelines published here, and there is an excellent article from Michael Howard here. The latter article describes three key actions: the use of parameterized queries, stored procedures and execute-only permission.

   Aside from developing an application securely in the first place, it is important to assess existing (and in some cases, third party) applications. To assist developers finding vulnerable pages, HP released a tool last week called Scrawlr. Numerous other tools exist to help developers assess their site (for example OWASP’s WebScarab). Yesterday, I noticed the release of Ratproxy (beta), a free web application security audit tool from Google.

2. Lowest possible privilege. Developers should ensure the web applications run with the least privilege necessary (never use administrative accounts such as db_owner or sysadmin).

3. Server logs. Everyone’s friend, the humble transaction log, can be very useful to diagnose attacks. The recent SQL injection attacks occur via malicious HTTP requests – inspection of the server logs for odd URI query strings can help to identify attempted attacks, and trigger subsequent investigations.

4. Third party vendors. If using code developed by a third party, ensure they adhere to best practice (quiz them specifically on their testing).

5. Defending web applications. There are various security products available that are designed to harden web applications against attacks, but it is important to note that these should not be seen as a replacement for adhering to development best practice and the tips outlined above.

   For example, web application firewalls, of which there are numerous commercial products available. One of the most widely used firewalls is ModSecurity (an open source solution). IIS users may be interested in a tool Microsoft released back in June, UrlScan v3.0 beta. IPS solutions can also help to protect web servers from attack, blocking malicious requests before they hit the server.

As is often the case with security, there is no simple solution, no silver bullet. But a combination of education and best practice can really help to prevent against web servers being compromised through injection attacks. Of course there are many other ways in which pages are compromised, and readers interested in the wider topic of web server security should consult the recently published paper.