4.0

35
Web Application Penetration Testing
where. This may happen either by error (due to misconfigurations), or
intentionally (for example, unadvertised administrative interfaces).
To address these issues, it is necessary to perform web application
discovery.
Test Objectives
Enumerate the applications within scope that exist on a web server
How to Test
Black Box Testing
Web application discovery is a process aimed at identifying web applications
on a given infrastructure. The latter is usually specified as
a set of IP addresses (maybe a net block), but may consist of a set of
DNS symbolic names or a mix of the two. This information is handed
out prior to the execution of an assessment, be it a classic-style
penetration test or an application-focused assessment. In both
cases, unless the rules of engagement specify otherwise (e.g., “test
only the application located at the URL http: /www.example.com/”),
the assessment should strive to be the most comprehensive in
scope, i.e. it should identify all the applications accessible through
the given target. The following examples examine a few techniques
that can be employed to achieve this goal.
Note: Some of the following techniques apply to Internet-facing
web servers, namely DNS and reverse-IP web-based search services
and the use of search engines. Examples make use of private
IP addresses (such as 192.168.1.100), which, unless indicated otherwise,
represent generic IP addresses and are used only for anonymity
purposes.
There are three factors influencing how many applications are related
to a given DNS name (or an IP address):
1. Different base URL
The obvious entry point for a web application is www.example.
com, i.e., with this shorthand notation we think of the web application
originating at http: /www.example.com/ (the same applies for
https). However, even though this is the most common situation,
there is nothing forcing the application to start at “/”.
For example, the same symbolic name may be associated to three
web applications such as: http: /www.example.com/url1 http: /
www.example.com/url2 http: /www.example.com/url3
In this case, the URL http: /www.example.com/ would not be associated
with a meaningful page, and the three applications would
be “hidden”, unless the tester explicitly knows how to reach them,
i.e., the tester knows url1, url2 or url3. There is usually no need to
publish web applications in this way, unless the owner doesn’t want
them to be accessible in a standard way, and is prepared to inform
the users about their exact location. This doesn’t mean that these
applications are secret, just that their existence and location is not
explicitly advertised.
2. Non-standard ports
While web applications usually live on port 80 (http) and 443 (https),
there is nothing magic about these port numbers. In fact, web applications
may be associated with arbitrary TCP ports, and can be
referenced by specifying the port number as follows: http[s]: /www.
example.com:port/. For example, http: /www.example.com:20000/.
3. Virtual hosts
DNS allows a single IP address to be associated with one or more
symbolic names. For example, the IP address 192.168.1.100 might
be associated to DNS names www.example.com, helpdesk.example.
com, webmail.example.com. It is not necessary that all the names
belong to the same DNS domain. This 1-to-N relationship may be reflected
to serve different content by using so called virtual hosts. The
information specifying the virtual host we are referring to is embedded
in the HTTP 1.1 Host: header [1].
One would not suspect the existence of other web applications in addition
to the obvious www.example.com, unless they know of helpdesk.example.com
and webmail.example.com.
Approaches to address issue 1 - non-standard URLs
There is no way to fully ascertain the existence of non-standardnamed
web applications. Being non-standard, there is no fixed criteria
governing the naming convention, however there are a number of
techniques that the tester can use to gain some additional insight.
First, if the web server is mis-configured and allows directory browsing,
it may be possible to spot these applications. Vulnerability scanners
may help in this respect.
Second, these applications may be referenced by other web pages
and there is a chance that they have been spidered and indexed by
web search engines. If testers suspect the existence of such “hidden”
applications on www.example.com they could search using the site
operator and examining the result of a query for “site: www.example.
com”. Among the returned URLs there could be one pointing to such a
non-obvious application.
Another option is to probe for URLs which might be likely candidates for
non-published applications. For example, a web mail front end might
be accessible from URLs such as https:/www.example.com/webmail,
https:/webmail.example.com/, or https:/mail.example.com/. The
same holds for administrative interfaces, which may be published at
hidden URLs (for example, a Tomcat administrative interface), and yet
not referenced anywhere. So doing a bit of dictionary-style searching
(or “intelligent guessing”) could yield some results. Vulnerability scanners
may help in this respect.
Approaches to address issue 2 - non-standard ports
It is easy to check for the existence of web applications on non-standard
ports. A port scanner such as nmap [2] is capable of performing
service recognition by means of the -sV option, and will identify http[s]
services on arbitrary ports. What is required is a full scan of the whole
64k TCP port address space.
For example, the following command will look up, with a TCP connect
scan, all open ports on IP 192.168.1.100 and will try to determine what
services are bound to them (only essential switches are shown – nmap
features a broad set of options, whose discussion is out of scope):
nmap –PN –sT –sV –p0-65535 192.168.1.100
It is sufficient to examine the output and look for http or the indication
of SSL-wrapped services (which should be probed to confirm
that they are https). For example, the output of the previous command
coullook like: