This article is based on a talk I gave at the Phoenix OWASP chapter on May 10th.My intention is to summarize the methods used to assess the security of web applications, identify what they are good and not so good at finding, and outline their varying strengths and weaknesses. If you’ll indulge me, I’d like to spend some time building up to that with some background material.
What’s the big deal, anyway?
I am very pleased about the about the growing awareness surrounding web application security threats. Several organizations have been formed to promote the issue, such as OWASP and the Web Application Security Consortium, and for good reason: it is currently the most prolific attack vector. In fact, Gartner estimates that 75% of all attacks now come at the application layer.
The reason why is no mystery. Whereas in the 90’s, system configuration, buffer overflow, and other platform level type flaws were all the rage, these have become increasingly easy to manage. Economies of scale have given ubiquity and commodity status to packet-filtering firewalls, multi-platform patch management systems, vulnerability scanners, and intrusion prevention systems. The kinds of attacks most often prevented by these technologies are now considered ‘low hanging fruit.
At the same time, the population of attackers has vastly increased. The maxim goes that a security system is only as strong as its weakest link, so that’s what attackers look for. Attacks have moved both up and down the stack. By this I mean, up to the application and even client level, and down to the system internals and driver level. Blue Pill, a virtual machine malware platform, is one such example that takes advantage of hardware features at the bottom level, while at the top level you have the world of web application attacks, where web applications are used as proxies to attack the integrity of the application as well as its architectural dependencies, and Javascript attacks, which are used to attack the softest target of all – the end user. At the Javascript / client attack level, state of the art is represented by PDP’s AttackAPI.
Custom web application security is different than platform security, to say the least. There are no vendor advisories or patches. Attackers like web applications because they have built in, exposed mechanisms that must have connectivity to the data the attacker is after. The attacker thinks, why compromise an entire system when you can manipulate the application into coughing up what you’re looking for? Most protection is at the network, not application layer, so the chances of getting caught are much lower. Application attacks are much harder to catch and prevent at the network layer, because the network components don’t understand the application, it’s logic, or which resources should be accessed and by which user roles. Web Application Firewalls (WAF) are an incomplete solution, often being network layer devices. The WEBAPPSEC mailing list has a great thread on this topic going on, right now. (See the May/June 2007 thread called “PCI 6.6 Questions) I’m not even certain WAF should be called a “firewall,” since they’re more of an Application layer Intrusion Prevention System, only they typically operate at the network layer, having no visibility into application internals. Fortify Defender is a notable exception. I’m starting to stray – this should probably be the subject of a future blog article…
As a result, it is incumbent upon organizations to understand the attackable surface area represented by web applications, particularly those that store and process confidential personal or payment card data.
Integrating Web Application Security Testing Approaches
One of the many hats I wear at QuietMove is to create our testing methodologies such that they maximize the efficiency and effectiveness of the time scoped for a particular assessment activity. I tackle this in two ways. One is by identifying the most comprehensive automated tools. I am a big proponent of automation – computers are good at automating things in a repeatable, measurable way. The second is in accounting for the fact that there are many classes of vulnerabilities which automated tools have serious trouble finding. This is partly a function of the perspective from which the tool operates, such as Source Code Analysis vs Fault Injection (more on this later), as well as the state of the art of each of these evolving technologies. Therefore, the second way recognizes that it’s critical we understand what automated tools can and can’t find, and develop other methods for identifying the “false negatives” – vulnerabilities that exist, but were missed.
The two main approaches that exist at present for web application testing are “Fault Injection” and “Source Code Analysis.” There are also two more philosophical approaches, “white box,” and “black box.” The results gained from a test are in no small way closely related to the assessment approach taken.
I’m going to define four terms that are key to this discussion:
White Box - a “full knowledge” approach to an assessment. This includes access to things like functional specifications and other design documents, network architecture, and source code.
Black Box – a “zero knowledge” approach to an assessment. The assessor starts off with no advance knowledge of the application. This is typically performed using automated fault injection tools, a web browser, and an HTTP proxy like Paros, Burp Proxy, or one of their many equivalents.
Fault Injection – interactive testing of a website that includes spidering, querying for known vulnerable scripts or components, testing for conditions like forceful browsing, directory traversal, and using the results of spidering to identify all points of user input to test for flaws like SQL injection, XSS, CSRF, command execution, etc. Typically a combination of fuzzing and injection of strings known to cause error conditions are used.
Static Code Analysis – is also often known as “Source Code Analysis.” This is often employs a mix of techniques such as searching for strings, identifying user input vectors, tracing the flow of data through the application, and mapping execution paths. Depending on the tool, it’s employed against source code or binaries.
Awareness is growing for a different technique often referred to as “Grey Box assessment,” which integrates the approaches described above. This approach combines static and fault injection testing techniques, in order to compensate for their different detection capabilities, and also integrates elements of white and black box methodologies. In practice, my observation is that the most comprehensive results are achieved through an iterative process involving an initial “white box” fault injection assessment, followed by static code analysis. The results of the static/source code analysis assessment are then fed back into further “fault injection” testing to validate the code analysis results and better inform the tester about the application architecture and areas to examine for further vulnerabilities using hands-on techniques. In my experience, this is the most comprehensive methodology, though for obvious reasons it’s also the most time consuming.
The following matrix was developed to present a high level view of the strengths and weaknesses of each approach. Suggestions for additional strengths and weaknesses would be welcomed.
The matrix view demonstrates some of the trade-offs at play: Detection capability, expense, and time. It visualizes a common theme of public talks I give about web application security, specifically how the testing methodology chosen impacts the results that will be achieved. It brings to mind the old engineering maxim. “Good, cheap, fast: Pick any two.” It demonstrates t
This is the first of several blog posts I’ll be posting at Security Catalyst about web application security testing. The next will be about several different approaches to planning test scenarios, and the relative strengths and weaknesses of each.
Print this post
|
Permalink |
Comments 
