Reading a different script

Any security professional worth their salt knows that relying on client-side scripting to validate customer data submissions is not a smart idea, because it can be trivially bypassed.

The attacks being targeted at online transactional websites such as e-banks and e-retailers have become much more efficient and organised over recent years. A quick search of popular hacking sites will yield thousands of tools specifically designed to trawl through a website for valuable content, discover hidden or forgotten files and backups, identify specific security vulnerabilities, fuzz data submission variables to discover overflows and code injection parameters, and even brute-force guess customer account details.

Coupled with botnets and other remotely controlled hosts, the likelihood of achieving attack success before any active prevention systems or processes kick into effect is getting higher.

But things can be done to a web-based application to degrade or even thwart many of these attack tools.

For example, simply by configuring the web server to respond with a "200 OK" message for everything – even if the requested page did not exist (404) or a server side error (500) is encountered – many of the basic (i.e. fastest) hacking tools will fail to yield worthwhile results.

An important thing to note about almost every vulnerability scanner or web-hacking tool is that they cannot actually process client-side scripts contained within HTML responses.

While some can parse languages such as JavaScript, VBScript and Java for URL information and key words, only an insignificant number of them are capable of executing client-side scripts.

Therefore, any web-based application that forces the client to execute some client-side script to calculate an additional value, which is then submitted in addition to any customer-supplied data is not going to work.

As long as the server-side application validates this "calculated" data first, any submissions that come from the standard automated attack tools will not work.

The solution is quite simple.

Going one step further, the use of "resource metering" routines that force the client-side to evaluate a computationally intensive value – but which can be quickly verified by the server-side – can help slow down attacks. When used in conjunction with incremental steps in calculation complexity, the technique can even be used to help thwart an attacker's code that has been custom designed to target a particular web-based application.

These solutions naturally depend upon client-side scripting being available and enforced. Depending on the nature of the application and the likelihood of being targeted with automated hacking tools, I've discovered that many of my clients can actively benefit from such simple script inclusions.

As always, the strength of any security solution lies in the art of compromise. But do not give up – client-side scripting really can increase web application security.

Gunter Ollmann is director of professional services at Next Generation Security Software