Simon Heron – SecureNet

SQL Injection attacks (where a hacker ‘injects’ malicious code into an application, exploiting a vulnerability in that application) have continued to increase in recent months. As a result, it is vital for companies to review their applications for any vulnerabilities and patch them where possible.

These attacks are extremely difficult to stop at the gateway because they emanate from errors in the coding of a genuine application that allows that application to be exploited.  These attacks should be differentiated from attacks that focus on a browser like the recent discovery of a bug in Firefox 3.5 can crash the browser and is independent of the application running in the browser.

Security firms, like Network Box, operate sophisticated Intrusion Detection and Prevention systems that can block many exploits, (such as public web applications), but even these type of systems can only offer a limited amount of protection in the case of private, internal applications. This is why companies must review application scripts and ensure they are kept up to date with the latest patches, on a regular basis.

In the advisory that we have just issued, we provide the following example of an SQL Injection attack:

A web server runs a news search application (called, for example, news.cgi), that uses a single parameter ‘id’ to retrieve a news story from a data source. The application is genuine, and the data source is used to receiving instruction from it.

A hacker exploiting a vulnerability in the application is able to change the ’id’ value, to instruct the application to do something different. So, for example, if a hacker was to insert ‘XX;truncate%20table%news’ into the parameter field, an application that does not validate or protect itself will compare the id with ‘XX’ and then execute the command ‘truncate table news’ which could delete news from the data source.

We would advise these methods to prevent such attacks from occurring:

1.    Use ‘parameterised’ SQL statements – put clear parameters into SQL instruction.
2.    Validate each parameter ID. For example, the ID parameter must be a number, or is restricted to certain terms.
3.    Use ‘escape’ parameters before insertion to the SQL statement. This ensures the commands inserted by the hacker are treated as a variable rather than a command.  So instead of comparing the id with ‘XX’ and then executing ‘truncate table news’, the id is compared with ‘XX; truncate table news’ which is not a legitimate id and is rejected.

This entry was posted on Thursday, July 23rd, 2009 at 12:06 pm and is filed under Security. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.