Custom Flaws for Custom Applications
First Published: SC Magazine

For a number of years now, I have specialised in the security assessment of custom web applications. It is with a little despair that I note this is the one area of corporate security that has gotten increasingly worse each year – not through any fault of my own I hasten to add. While organisations have finally begun to master the fine art of deploying firewalls and patch management, their sophisticated custom-developed web applications frequently find themselves open to a new host of security vulnerabilities.

A lot of the problems associated with these custom web applications can be linked to the corporate development lifecycle and the resources used.

Organisations tend to have two choices when developing a new web-based application; they can develop it using internal resources or outsource it to an agency. Using internal development resources, on the whole, tends to result in an application with more security vulnerabilities. This tends to be due to three factors.

Firstly, internal developers have a greater understanding of the existing business systems and are less inhibited when building data conduits to existing infrastructure. This means that they can write more sophisticated and integrated business applications. Consequently, their web applications can provide many more avenues or vectors for attack.

Secondly, they have skills relating to the development of internal applications - of which security was traditionally only a distant consideration. Thus, not only do they not have a great deal of experience developing to secure coding practices, their understanding of current external security threats is also very limited. This results in the inclusion of many trivial flaws that can adversely affect the security of the application.

Finally, there is a reliance on the latest development tools and visual impact aids to build the application - without any consideration for the security impact of the additions. The fusion of ideas from developers, graphics designers and client usability analysts into a single custom application means that the “wiz-bang” factor increases in addition to more eye-candy components, while security suffers in light of universal usability issues.

The net effect is that security is inversely proportional to the size and sophistication of the web application.

This is not to say that using a third-party development agency is the only solution. Approximately one-third of all the applications I have assessed were developed externally, and also suffered from similar security vulnerabilities. However, on average, there tended to be fewer vulnerabilities and have less impact on the organisation. I believe this is largely due to better defined scoping documentation and greater restrictions on internal corporate data connectivity.

Examples of poor web application coding techniques that result in security threats are abundant on the Internet. Just the other day I was explaining to an acquaintance the simple security concept of content checking while she happened to be browsing for tourist day-trips in Thailand. All of the sites she was browsing had the ability to “Search” using keywords. Of the nine websites she visited, just typing a single-quote in to the search box of seven of them resulted in a detailed application error message. Of these seven, it was clear that four of the sites could probably be exploited through a SQL insertion attack, just by analysing the resultant error messages.

This type of attack, SQL Insertion, represents the cutting edge of custom application security failure. Through various publications and public disclosure lists, the diversity of techniques to take advantage of it has increased exponentially in just the last year. It is now the single most effective way of bypassing perimeter security defences and gaining access to any organisations most valuable assets – their confidential customer data.
    Copyright 2001-2007 © Gunter Ollmann