4.0
1NSchAb
1NSchAb
- No tags were found...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
40<br />
Web Application Penetration Testing<br />
Gray Box Testing<br />
Testing for application entry points via a Gray Box methodology<br />
would consist of everything already identified above with one addition.<br />
In cases where there are external sources from which the application<br />
receives data and processes it (such as SNMP traps, syslog<br />
messages, SMTP, or SOAP messages from other servers) a meeting<br />
with the application developers could identify any functions that<br />
would accept or expect user input and how they are formatted. For<br />
example, the developer could help in understanding how to formulate<br />
a correct SOAP request that the application would accept and<br />
where the web service resides (if the web service or any other function<br />
hasn’t already been identified during the black box testing).<br />
Tools<br />
Intercepting Proxy:<br />
• OWASP: Zed Attack Proxy (ZAP)<br />
• OWASP: WebScarab<br />
• Burp Suite<br />
• CAT<br />
Browser Plug-in:<br />
• TamperIE for Internet Explorer<br />
• Tamper Data for Firefox<br />
References<br />
Whitepapers<br />
• RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 -<br />
http: /tools.ietf.org/html/rfc2616<br />
flow, transformation and use of data throughout an application.<br />
• Race - tests multiple concurrent instances of the application<br />
manipulating the same data.<br />
The trade off as to what method is used and to what degree each<br />
method is used should be negotiated with the application owner.<br />
Simpler approaches could also be adopted, including asking the application<br />
owner what functions or code sections they are particularly<br />
concerned about and how those code segments can be reached.<br />
Black Box Testing<br />
To demonstrate code coverage to the application owner, the tester<br />
can start with a spreadsheet and document all the links discovered<br />
by spidering the application (either manually or automatically). Then<br />
the tester can look more closely at decision points in the application<br />
and investigate how many significant code paths are discovered.<br />
These should then be documented in the spreadsheet with URLs,<br />
prose and screenshot descriptions of the paths discovered.<br />
Gray/White Box testing<br />
Ensuring sufficient code coverage for the application owner is far<br />
easier with the gray and white box approach to testing. Information<br />
solicited by and provided to the tester will ensure the minimum requirements<br />
for code coverage are met.<br />
Example<br />
Automatic Spidering<br />
The automatic spider is a tool used to automatically discover new<br />
resources (URLs) on a particular website. It begins with a list of<br />
URLs to visit, called the seeds, which depends on how the Spider is<br />
started. While there are a lot of Spidering tools, the following example<br />
uses the Zed Attack Proxy (ZAP):<br />
Map execution paths through application<br />
(OTG-INFO-007)<br />
Summary<br />
Before commencing security testing, understanding the structure<br />
of the application is paramount. Without a thorough understanding<br />
of the layout of the application, it is unlkely that it will be tested<br />
thoroughly.<br />
Test Objectives<br />
Map the target application and understand the principal workflows.<br />
How to Test<br />
In black box testing it is extremely difficult to test the entire code<br />
base. Not just because the tester has no view of the code paths<br />
through the application, but even if they did, to test all code paths<br />
would be very time consuming. One way to reconcile this is to document<br />
what code paths were discovered and tested.<br />
There are several ways to approach the testing and measurement<br />
of code coverage:<br />
• Path - test each of the paths through an application that includes<br />
combinatorial and boundary value analysis testing for each<br />
decision path. While this approach offers thoroughness, the<br />
number of testable paths grows exponentially with each decision<br />
branch.<br />
• Data flow (or taint analysis) - tests the assignment of variables via<br />
external interaction (normally users). Focuses on mapping the<br />
ZAP offers the following automatic spidering features, which can be<br />
selected based on the tester’s needs:<br />
• Spider Site - The seed list contains all the existing URIs already<br />
found for the selected site.<br />
• Spider Subtree - The seed list contains all the existing URIs already<br />
found and present in the subtree of the selected node.<br />
• Spider URL - The seed list contains only the URI corresponding to<br />
the selected node (in the Site Tree).<br />
• Spider all in Scope - The seed list contains all the URIs the user has<br />
selected as being ‘In Scope’.<br />
Tools<br />
• Zed Attack Proxy (ZAP)