Goals and Objectives

The goals and objectives of Hardanger are to bring an easy to use, open source web application penetration testing tool to the Microsoft Windows platform. Performance will be critical and the ability to extend the framework paramount to its success.

Open Source

Due to the lack of quality open source alternatives on the Microsoft Windows platform, Hardanger will be an open source project. The project will be hosted on Microsoft’s open source web site Codeplex. The open source Microsoft Reciprocal License (Ms-RL) will allow other people to modify and redistribute the Hardanger’s source code with the restriction that they must provide the source code and a copy of the license when the modified file is distributed as part of another program. I hope that the nature of this open source project will bring in other developers to contribute to its growth in the future.

How to measure:

-          Review open source license distributed with the software

Ease of Use

It will be critical for Hardanger to be easy to use like most other native Microsoft Windows applications. A large number of software developers already use Fiddler2 and making Hardanger look and feel integrated with it will be critical to its success and adoption. The choice to stay away from Java and non-standard application interfaces should help achieve the goal of ease of use.

How to measure:

-          Will perform user acceptance testing (UAT) with current users of Fiddler2.

Performance

Performance of the add-on will be important to its success. Users typically will disable an add-on and never use it again if they experience issues after using it. The choice of C# and the .NET CLR to run this application should help it significantly in this area compared to its main Java based competitors.

How to measure:

-          The add-on should be able to run for 24 hours with a stable memory footprint measured with Microsoft Perfmon.

-          The difference in launching Fiddler2 with or without the add-on enabled should not exceed one second.

Extensible

Hardanger will not simply be just another add-on, it will be a platform. Time spent designing the platform upfront will be paid back many times over as more features are added to the platform. While only one feature is in scope for this project, building a flexible foundation for its success is paramount to its succeess.

How to measure:

-          Add a dummy feature (mocked or stubbed) for brute forcing ensuring the process is straightforward.

-          It should take less than 15 minutes to add the new feature even though that new feature does not do anything yet.

Support Fuzzing of POST Requests

Hardanger should have the ability to fuzz POST requests. The basic fuzzer will need the ability to parse out all parameters from a POST request and let the user select which variables should be fuzzed. Figure 3 demonstrates the parts of a HTTP POST request.

POST /user/Login HTTP/1.0
Host: www.securitywire.com
User-Agent: MyWebBrowser
Content-Type: application/x-www-form-urlencoded
Content-Length: 32

username=luser&password=Apple

Figure 3. Sample POST Request

If a POST session like the one in Figure 3 is presented to the basic fuzzer module, it would challenge the user to provide fuzzing configuration for the variables username and password. Once the fuzzing engine is configured, the fuzzing could be launched producing a constant varying stream of requests to the server with different values every time in place of the “luser” and “Apple” values. The fuzzer will need to record the HTTP response codes and any error messages reported on the returned page so it can be included in a report for the user to review and look for any potential vulnerability to research further.

How to measure:

-          Use netcat in listen mode to monitor the stream of requests and construct responses.

-          Review the report for accuracy based on the constructed responses produced in the previous step.

Support Fuzzing of GET Requests

Hardanger should have the ability to fuzz GET requests. The basic fuzzer will need the ability to parse out all parameters from a GET request and let the user select which variables should be fuzzed. Figure 4 demonstrates the parts of a HTTP GET request.

GET /user/Login?username=luser&password=Apple HTTP/1.0
Host: www.securitywire.com
User-Agent: MyWebBrowser

Figure 4. Sample GET Request

If a GET session like the one in Figure 4 is presented to the basic fuzzer module, it would challenge the user to provide fuzzing configuration for the variables username and password. Once the fuzzing engine is configured, the fuzzing could be launched producing a constant varying stream of requests to the server with different values every time in place of the “luser” and “Apple” values. The fuzzer will need to record the HTTP response codes and any error messages reported on the returned page so it can be included in a report for the user to review and look for any potential vulnerability to research further.

How to measure:

-          Use netcat in listen mode to monitor the stream of requests and construct responses.

-          Review the report for accuracy based on the contructed responses produced in the previous step.

Support HTTP and HTTPS

With more and more sites using SSL extensively, even when not necessary, it will be critical for Hardanger to support both HTTP and HTTPS traffic. Hardanger will leverage the Fiddler2 platform which already support both of these protocols. It will leverage Fiddler2’s ability to generated a trusted self-signed certificate and install it on the machine running Hardanger.

How to measure:

-          Run Hardanger against a HTTP site

-          Run Hardanger against a HTTPS site

Last edited Feb 2, 2012 at 12:32 AM by mercjr, version 1

Comments

No comments yet.