WEB Application Security

This article is the fifth and final in a series that is designed to help readers to assess the risk that their Internet-connected systems are exposed to. In the first installment, we established the reasons for doing a technical risk assessment. In the second article, we started to discuss the methodology that we follow in performing this kind of assessment. The third part discussed methodology in more detail, focussing on visibility and vulnerability scanning. The fourth installment discussed a relatively unexplored aspect of Internet security, custom Web applications. This article will conclude the discussion of security risks of Web applications.

Risk Categories

A detailed discussion of all the possible vulnerabilities associated with custom Web applications would be somewhat beyond the scope of this paper. What I've done instead is to list and describe all the categories. I'll then single out some specific instances and describe them in more detail as examples.

Here then a list of mistakes that are commonly made, even by experienced programmers. Having answered all the other questions from the previous list, we will carefully search for the following common vulnerability categories:

1. Server Application Vulnerabilities:

As with any network service, Web servers are applications that are often exploitable via the known vulnerabilities we discussed in the "Vulnerability Scanning" section in the third installment in this series. Specialized "CGI" scanners like Whisker, Nikto and the appropriately named CGI-Scanner are especially designed to find vulnerabilities in Web servers. We've discussed this concept at length already, so I won't spend much time on it again.

2. Sample Scripts:

Many Web servers and Web development platforms ship with sample applications built in to serve as examples of what can be achieved. These applications are designed to serve as examples only and have not been built with security in mind. Indeed, sample scripts are often blatantly insecure. Once again, most of these scripts are commonly known and can quickly be identified with a CGI scanner.

3. Hidden directories:

Directories that are accessible to the Web server but are considered "hidden" because there are no references or HTTP links to them. Once more, scanners like Nikto and Whisker make short work of discovering such directories through brute force.

4. Administrative Back-ends:

Complex Web sites are often developed by specialists at a high price. To facilitate cost-effective management and updates of such sites the developers often provide an administrative back-end through which the site owner can easily add or modify content without having to understand the HTML and other underlying technologies. Discovering such a back-end (again via brute force) presents an easy vector for Web site defacement and other attacks.

5. Directory Traversal:

A directory traversal attack involves stepping through multiple levels of the file system structure using "..\". This feature is often used by attackers to trick an application into accessing a part of the file system it was never meant to.

6. Input sanitation:

These wise words from my colleague Haroon Meer sum up the problem with input sanitation: "People have been screaming about poor (non) validation of user input for as long as I can remember, so I don't even think that any of the normal excuses apply anymore. By now developers should simply have learned that all user input should be inherently distrusted and therefore sanitized. Unfortunately, most of the sites you come across seem to ignore sanitization of user input completely or do it selectively (often forgetting hidden fields)."

A common mistake in developing Web applications is to make assumptions about the inputs that user will provide, whether it is done manually or via some automated process. Manual inputs include the data entered by users into fields and forms. Automated inputs are submitted without the user being directly involved and include things like cookies, URLs and hidden HTTP fields. Nothing that is provided by the user should ever be trusted and an application that does so is opening itself up to abuse. Possibly the most significant category of attack that stems from inappropriate input sanitation is SQL Injection.

7. State Tracking:

An enormous problem facing any Web application developer is the question of how to keep track of a single user as he or she makes their way through the various areas of the Web site. This is difficult for many reasons. The primary obstacle is the fact that each page of an HTML application and each object on an HTML page is fetched using a new HTTP session. Unlike "stateful" applications like Telnet or FTP, HTTP is stateless and there is no standard way for the application to keep track of a user who has logged in. Mechanisms used for this include cookies, session keys and hidden fields. Mistakes made in the way state is tracked can allow an attacker to "highjack" a session and gain access to applications and data without being properly authenticated.

8. Cross-Site Scripting:

Cross-site scripting (also called XSS) is somewhat different to the other attacks discussed thus far. Rather than attack the server or the application XSS attacks are aimed at the end-user's browser. XSS is not a problem of input sanitation, but rather a problem of output sanitation. It is typically used against sites that redisplay values that are input by the user. If the information presented by the user is not properly sanitized before it is displayed then an attacker may be able to use HTML tags to influence the way it is displayed by the site. This becomes particularly dangerous when the attacker inserts the <SCRIPT> tag, thereby forcing other users' browsers to execute the code the attacker specifies. An easy way to test for this is to insert HTML like this:

<SCRIPT>alert('Vulnerable!')</SCRIPT>

If the Web site does not clean this up before displaying it will cause a pop-up message to be displayed by the visitor's browser. Obviously an attacker could do much worse than cause pop-ops, particularly when the site is trusted by other users.

Web Security Assessment Tools

Having looked at a number of different threat categories at a very high level,

Allright, so if you've decided to assess the security of your Web applications and you just can't bear the thought of paying someone like me to do it, what do you need in your tool box? Here's a good start:

• Whitehat Arsenal To the best of my knowledge the WhiteHat Arsenal is the first (and, to date, only) comprehensive Web application security scanning tool. The tool was written by Jeremiah Grossman and is commercially available from the address given above. All of the other tools I'll be discussing are available under some form of freeware arrangement.
• @Stake Web Proxy The @Stake proxy is an amazingly tight and powerful tool that allows you to intercept and manipulate the data that your browser would normally send to a server. Thus one can play around with fields, URLs, cookies and the like through a handy graphical interface. This tool is by far the slickest offering of its kind and serves to suggest that @stake may well have been well ahead of the rest us in this particular game. The @stake proxy is a must.
• Spike v2.6 The Spike proxy is written by Dave Aitel and is really two programs combined into one. The Spike proxy does very much the same thing as the @stake proxy, though with perhaps a little less finesse. The second component is what's known as a protocol "Fuzzer", which is essentially used to brute-force applications over the network in search of possible overflow conditions. This element of the tool is relatively new and exciting, but is a little beyond the scope of this paper.
• HTTrack HTTrack is what's known as a Web site "whacker". It basically performs a mirror of the selected site to your local drive, mimicking the site's structure and recreating each file. A local mirror allows one to examine and analyze the site at his or her leisure. We use a mirror, amongst other things, to search for active content, to search for links to other sites, and as an input to the Mieliekoek SQL Injection scanner. HTTrack is both smart and robust and has to be one of the best of this generation of tools.
• Mieliekoek v2 Mielielkoek can probably best be described as an SQL Injection brute-forcer. You have to have a locally mirrored copy of the site, as provided by HTTrack. Point Mieliekoek at the mirror and it will identify every field in every form. For each field identified, Mieliekoek will then attempt to inject the character you specify (typically ') and measure the server's response. The correct kind of SQL error indicates that the site may be vulnerable to attack. Mieliekoek will allow you to browse through the findings and also to experiment with different inputs to measure their impact on the site.
• WebSleuth Call WebSleuth the hacker's browser. It's essentially a standard Web browser that affords you a higher level of interaction and control over the site you're browsing. Available functions include the ability to disable scripts, to view hidden fields and to edit data before it is submitted to the site. WebSleuth supports the use of independently written plugins and has gained the support of various respected security practitioners in this way.
• Nessus: Nessus is the excellent open source network security scanner written by Renaud Derraison. Although this not a Web-specific tool it does include a number of scripts that search for issues like cross-site scripting. Nessus was discussed in more detail in the previous section.
• Nikto Nikto, like Whisker, Arirang and others, is probably best described as a CGI-scanner. As discussed in earlier sections, the CGI scanner is a specialized vulnerability scanner that has been optimized to find known problems with Web server vulnerabilities. Apart from the usual stuff, CGI scanners can also be used to track down false positives and the like.

Conclusion

This concludes our basic overview of Internet security risk assessments. Certainly, this procedure is a valuable process for anyone who is charged with maintaining the security of a network that is connected to the Internet. While this series should not be taken as a comprehensive, in-depth guide to assessing Internet security risks, we hope that it has given readers an idea of what needs to be taken into account when conducting assessment of the security risks that their Internet-connected network may face.