Security Testing Of Web App Code

Wouldn't it be great if code review was sufficient to catch all security bugs? Unfortunately, this is not the case for a variety of reasons, primarily because no single security assessment mechanism is perfect. Thus, no matter what level of code review is performed on an application, rigorous security testing of the code in a real-world environment always shakes loose more bugs , some of them quite serious. This section will detail some of the key aspects of web application security testing, including:

• Fuzz testing

• Test tools, Utilities, and Harnesses

• Pen-testing

Fuzzing

Fuzzing is sending arbitrary as well as maliciously structured data to an application in an attempt to make it behave unexpectedly, in order to identify potential security vulnerabilities. Numerous articles and books have been published on fuzz-testing , so a lengthy discussion is out of scope, but we'll briefly discuss off-the-shelf fuzzers as well as home-grown varieties here. For more information on fuzzing, see "References and Further Reading" at the end of this chapter.

Of course, fuzzing is also performed during black-box testing (see Chapter 6). In this section, we'll focus on the use of fuzzing in white-box scenarios, i.e., with a debugger hooked up to the target application so that faults can be easily identified and diagnosed.

Off-the-shelf Fuzzers

There are a number of off-the-shelf fuzzers. One of the better ones is Spike, which focuses on C and C++ applications. Spike Web Proxy applies the same fuzzing approach to web applications. Written in Python, it performs input validation and authorization attacks including SQL injection, form input field overflows, and cross-site scripting.

Spike Web Proxy is started by running a batch file (runme.bat), and then configuring the browser to use the local Spike proxy server (localhost on port 8080). Next, simply connect to the target web application. The Spike proxy takes over the connection and creates a test console available at http://spike. The console lists possible attack techniques against the application, including "Delve into Dir", "argscan", "dirscan", "overflow", and "VulnXML Tests". Select the individual links to perform these attacks against the application. Spike displays the results of the scans in the lower frame in the browser.

Spike Web Proxy can also be used to find the vulnerability in our secret.dll ISAPI that was created and used earlier for binary analysis. As we saw in that section, it's very useful to have something "pitch" so that the application under analysis can "catch" while being debugged , which reveals key aspects of the code while in motion. Fuzzers are great "pitchers."

For example, to find the vulnerability in the secret.dll ISAPI, load Ollydbg and attach to the web server process as before. Start Spike Proxy and browse to the application, then browse to the local Spike interface (http://spike). Select "Overflow" to perform a buffer overflow attack against the ISAPI.

As seen while using Ollydbg in the "Binary Analysis" section, the string passed from the URL is loaded into EDI. The string is written on the stack, as shown in the Stack pane. The overly long string crashes the ISAPI. The access violation is an indication that the ISAPI has crashed. EAX and ECX registers have been overwritten with the 41414141 (hex representation of AAAA). This is shown in Figure 12-11.

Figure 12-11: Ollydbg displays an access violation in secret.dll while being tested for buffer overflows using Spike Web Proxy.

Building Your Own Fuzzer

Any scripting language can be used to build your own fuzzer. Utilities like curl and netcat can also be wrapped in scripts to simplify the level of effort required to create basic HTTP request-response functionality. Of course, for faster performance, it is always better to write fuzzers in C/C++.

Next is a sample Perl script that makes a POST request to our example secret.dll ISAPI web application. Note that we've created a loop routine that iterates through several requests containing a random number (between 1 and 50) of A's.

 #!/usr/local/bin/perl -w use HTTP::Request::Common qw(POST GET); use LWP::UserAgent; $ua = LWP::UserAgent->new(); $url = "http://127.0.0.1/_vti_script/secret.dll";  //Loop  for ($i=0; $i <= 10; $i++) {  //Random A's generated  $req = $ua->post( $url, [MfcISAPICommand => SecretProc, Secret => 'A'x int(rand(50))]); my $content = $req->content; print $content; print "\n\n"; } 

This script is a very basic fuzzer.

Test Tools, Utilities, And Harnesses

There are numerous other tools for generic web application testing available, but at the time of this writing, the market is just starting to evolve quality assurance (QA) testing tools focused on web app security. Mercury Interactive provides some of the more popular general web application testing tools, which include some security testing functionality. One of the few tools specific to web application security is SPIDynamics QAInspect.

We find that many development shops like to cobble together their own test suites using low-cost (or free) HTTP analysis software. See Chapter 1 for a list of HTTP analysis utilities that can be used to create test harnesses.

Pen-Testing

Penetration testing (pen-testing) is most aptly described as "adversarial use by experienced attackers ." Other terms have been used to describe the same concept: tiger team testing, ethical hacking, and so on. The word "experienced" in this definition is critical: we find time and again that the quality of results derived from pen-testing is directly proportional to the skill of the personnel who perform the tests.

We believe pen-testing should be incorporated into the normal development process for every software product, at least at every major release. Since web applications are much more dynamic than traditional software applications (often receiving substantial updates on a weekly basis), we recommend at least an annual or semi-annual pen-test review for web apps.

Pen-testing requires a special type of person, someone who really enjoys circumventing, subverting, and/or usurping technology built by others. At most organizations we've worked with, very few individuals are philosophically and practically well-situated to perform such work. It is even more challenging to sustain an internal pen-test team over the long haul, due to this "cognitive dissonance" as well as the perpetual mismatch between the market price for good pen-testing skills and the perceived value by management across successive budget cycles. Thus, we recommend critically evaluating the abilities of internal staff to perform pen-testing, and strongly considering an external service provider for such work. A third party gives the added benefit of impartiality, a fact that can be leveraged during external negotiations or marketing campaigns . For example, demonstrating to potential partners that regular third-party pen-testing is conducted can make the difference in competitive outsourcing scenarios.

Given that you elect to hire third-party pen-testers to attack your product, here are some of the key issues to consider when striving for maximum return on investment:

• Schedule   Ideally, pen-testing occurs after the availability of beta-quality code but early enough to permit significant changes before ship date should the pen-test team identify serious issues. Yes, this is a fine line to walk.

• Liaison   Make sure managers are prepared to commit necessary product team personnel to provide information to pen-testers during testing. They will require significant engagement to achieve the necessary expertise in your product to deliver good results.

• Deliverables   Too often, pen-testers deliver a documented report at the end of the engagement and are never seen again. This report collects dust on someone's desk until it unexpectedly shows up on an annual audit months later after much urgency has been lost. We recommend familiarizing the pen-testers with your in-house bug-tracking systems and having them file issues directly with the development team as the work progresses.

Finally, no matter which security testing approach you choose, we strongly recommend that all testing focus on the risks prioritized during threat modeling. This will lend coherence and consistency to your overall testing efforts that will result in regular progress towards reducing serious security vulnerabilities.