Summary
Before commencing security testing, understanding the structure of the application is paramount. Without a thorough understanding of the layout of the application, it is unlkely that it will be tested thoroughly.
Test Objectives
Map the target application and understand the principal workflows.
How to Test
In black box testing it is extremely difficult to test the entire code base. Not just because the tester has no view of the code paths through the application, but even if they did, to test all code paths would be very time consuming. One way to reconcile this is to doc- ument what code paths were discovered and tested.
There are several ways to approach the testing and measurement of code coverage:
• Path - test each of the paths through an application that includes combinatorial and boundary value analysis testing for each decision path. While this approach offers thoroughness, the number of testable paths grows exponentially with each decision branch.
• Data flow (or taint analysis) - tests the assignment of variables via external interaction (normally users). Focuses on mapping the
flow, transformation and use of data throughout an application. • Race - tests multiple concurrent instances of the application
manipulating the same data.
The trade off as to what method is used and to what degree each method is used should be negotiated with the application owner. Simpler approaches could also be adopted, including asking the ap- plication owner what functions or code sections they are particular- ly concerned about and how those code segments can be reached.
Black Box Testing
To demonstrate code coverage to the application owner, the tester can start with a spreadsheet and document all the links discovered by spidering the application (either manually or automatically). Then the tester can look more closely at decision points in the application and investigate how many significant code paths are discovered. These should then be documented in the spreadsheet with URLs, prose and screenshot descriptions of the paths discovered.
Gray/White Box testing
Ensuring sufficient code coverage for the application owner is far easier with the gray and white box approach to testing. Information solicited by and provided to the tester will ensure the minimum re- quirements for code coverage are met.
Example
Automatic Spidering
The automatic spider is a tool used to automatically discover new resources (URLs) on a particular website. It begins with a list of URLs to visit, called the seeds, which depends on how the Spider is started. While there are a lot of Spidering tools, the following exam- ple uses the Zed Attack Proxy (ZAP):
ZAP offers the following automatic spidering features, which can be selected based on the tester’s needs:
• Spider Site - The seed list contains all the existing URIs already found for the selected site.
• Spider Subtree - The seed list contains all the existing URIs already found and present in the subtree of the selected node.
• Spider URL - The seed list contains only the URI corresponding to the selected node (in the Site Tree).
• Spider all in Scope - The seed list contains all the URIs the user has selected as being ‘In Scope’.
Tools
From the X-Powered-By field, we understand that the web ap- plication framework is likely to be Mono. However, although this approach is simple and quick, this methodology doesn’t work in 100% of cases. It is possible to easily disable X-Powered-By head- er by a proper configuration. There are also several techniques that allow a web site to obfuscate HTTP headers (see an example in #Remediation chapter).
So in the same example the tester could either miss the X-Pow- ered-By header or obtain an answer like the following:
Sometimes there are more HTTP-headers that point at a certain web framework. In the following example, according to the in- formation from HTTP-request, one can see that X-Powered-By header contains PHP version. However, the X-Generator header points out the used framework is actually Swiftlet, which helps a penetration tester to expand his attack vectors. When perform- ing fingerprinting, always carefully inspect every HTTP-header for such leaks.
$ nc 127.0.0.1 80 HEAD / HTTP/1.0
HTTP/1.1 200 OK Server: nginx/1.0.14
Date: Sat, 07 Sep 2013 08:19:15 GMT Content-Type: text/html;charset=ISO-8859-1 Connection: close Vary: Accept-Encoding X-Powered-By: Mono HTTP/1.1 200 OK Server: nginx/1.0.14
Date: Sat, 07 Sep 2013 08:19:15 GMT Content-Type: text/html;charset=ISO-8859-1 Connection: close
Vary: Accept-Encoding
X-Powered-By: Blood, sweat and tears
HTTP/1.1 200 OK Server: nginx/1.4.1
Date: Sat, 07 Sep 2013 09:22:52 GMT Content-Type: text/html
Connection: keep-alive Vary: Accept-Encoding
X-Powered-By: PHP/5.4.16-1~dotdeb.1 Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post- check=0, pre-check=0
Pragma: no-cache X-Generator: Swiftlet • List of spreadsheet software
• Diagramming software
References Whitepapers
[1] http://en.wikipedia.org/wiki/Code_coverage
Fingerprint Web Application Framework
(OTG-INFO-008)
Summary
Web framework[*] fingerprinting is an important subtask of the infor- mation gathering process. Knowing the type of framework can auto- matically give a great advantage if such a framework has already been tested by the penetration tester. It is not only the known vulnerabili- ties in unpatched versions but specific misconfigurations in the frame- work and known file structure that makes the fingerprinting process so important.
Several different vendors and versions of web frameworks are widely used. Information about it significantly helps in the testing process, and can also help in changing the course of the test. Such information can be derived by careful analysis of certain common locations. Most of the web frameworks have several markers in those locations which help an attacker to spot them. This is basically what all automatic tools do, they look for a marker from a predefined location and then com- pare it to the database of known signatures. For better accuracy sev- eral markers are usually used.
[*] Please note that this article makes no differentiation between Web Application Frameworks (WAF) and Content Management Systems (CMS). This has been done to make it convenient to fingerprint both of them in one chapter. Furthermore, both categories are referenced as web frameworks.
Test Objectives
To define type of used web framework so as to have a better under- standing of the security testing methodology.
How to Test Black Box testing
There are several most common locations to look in in order to define the current framework:
• HTTP headers • Cookies
• HTML source code • Specific files and folders
HTTP headers
The most basic form of identifying a web framework is to look at the X-Powered-By field in the HTTP response header. Many tools can be used to fingerprint a target. The simplest one is netcat utility.
More frequently such information is placed between <head></ head> tags, in <meta> tags or at the end of the page.
Nevertheless, it is recommended to check the whole document since it can be useful for other purposes such as inspection of oth- er useful comments and hidden fields. Sometimes, web develop- ers do not care much about hiding information about the frame- work used. It is still possible to stumble upon something like this at the bottom of the page: