Assessing the Security of Your Web Applications

Web sites are moving away from static HTML to dynamic interactive web applications. It is the dynamic, interactive web application that is making the Internet the universal medium. Web applications bring a new level of risk to web sites. Security of these web applications is paramount to the security of the site.

Awareness of security threats from the Internet is increasing the adoption of secure technologies. Deploying firewalls is a standard first step adopted by many organizations. Firewalls protect against many attacks on the network and system infrastructure. In addition, some firewalls provide filtering capability and contain inbound malicious Java and Active-X applications. However, firewalls do little to protect against inbound malicious requests to legitimate applications. Web-based applications are very popular due to the ubiquity of the Internet. Providing access to customer information, user profiles, financial records and health records are common examples of services that web applications can provide. Most often, these applications access a back-end database to serve dynamically generated content to the users. Applications designed without security in mind may result in loss of data integrity, availability, confidentiality and privacy.

Most web application testing can be classified as static or dynamic. Static testing involves manually inspecting the source code and automatically testing for dangerous constructs. On the other hand, dynamic testing involves executing the web application to detect anomalous behavior on unexpected inputs. The focus of this article is on dynamic testing.

Some information seekers think maliciously. Hackers are sometimes able to anticipate inadequacies and the coding practices adopted by programmers. Often, the “speed to market” attitude pushes application developers to overlook standard and secure coding practices. This is especially true in the e-commerce environment, where standard practices such as Change Management are often overlooked. Security is thus usually an afterthought. Often, this results in a vulnerable first release of an application. The process of fixing the vulnerabilities is a fairly expensive one.

Code templates and examples in different development environments provide developers with an approach to implement the desired functionality. These code snippets may not, however, account for application security. The malicious user is sometimes able to identify the development environment just by viewing the HTML code generated by a web application. Comments and some HTML tags can provide information on the development environment. Upon identifying the development environment, a malicious user is able to exploit vulnerabilities where the example or template may have been used.

Another common area for exploitation is the way the application maintains session state information. The HyperText Transport Protocol (HTTP) by itself is stateless. Cookies are commonly used to maintain state information between subsequent HTTP requests. Cookies are simply sets of strings written to the browser by the web application server. They are used to maintain session state, remember passwords and user names, for personalization and configuration features. A malicious user could hijack applications that do not implement strong session controls.

Application vulnerabilities are important because they give access to confidential information such as credit card numbers, account numbers or names and customer lists, without having to break into the web server. The difference between a malicious user and a regular user is intent.

In a recent incident that stunned the on-line community, a hacker posted up to 25,000 stolen credit-card numbers on a public web site (see Resources). These numbers were stolen from the CD Universe web site. The hacker claims to be in possession of more than 300,000 credit card numbers from this site. Further, the hacker claimed that the credit card numbers were compromised due to a flaw in the software used to process credit card transactions. Are you at risk? It depends. You may be at risk if:

If you do not fit any of the above categories, you may still be vulnerable. In the event of a compromise, only your organization's data classification policy and the value of the data lost will determine the extent of the damage. Just last year, the numbers of web site defacements rose over 900% (see Resources). This can result in embarrassment and unnecessary media exposure. Some publicly traded companies have seen their stock value go down as a result of a breach in the security of their web site.