4.0

41
Web Application Penetration Testing
• 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 information
gathering process. Knowing the type of framework can automatically
give a great advantage if such a framework has already been
tested by the penetration tester. It is not only the known vulnerabilities
in unpatched versions but specific misconfigurations in the framework
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 compare
it to the database of known signatures. For better accuracy several
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 understanding
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.
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
From the X-Powered-By field, we understand that the web application
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 header
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-Powered-By
header or obtain an answer like the following:
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
Sometimes there are more HTTP-headers that point at a certain
web framework. In the following example, according to the information
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 performing
fingerprinting, always carefully inspect every HTTP-header for
such leaks.
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, postcheck=0,
pre-check=0
Pragma: no-cache
X-Generator: Swiftlet
Consider the following HTTP Request-Response:
$ nc 127.0.0.1 80
HEAD / HTTP/1.0