This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Enumerate Applications on Webserver (OTG-INFO-004)

Revision as of 15:43, 2 January 2007 by Katie.mcdowell (talk | contribs)

Jump to: navigation, search


OWASP Testing Guide v2 Table of Contents

Brief Summary

A paramount step for testing for web application vulnerabilities is to find out which particular applications are hosted on a web server.
Many different applications have known vulnerabilities and known attack strategies than can be exploited in order to gain remote control and/or data exploitation.
In addition to this, many applications are often hosted on a particular web server without direct reference from the main website/application: this is true for internal and/or extranet websites which could be misconfigured or not updated due to the perception that they are used only "internally".
Furthermore, many applications use a common path for administrative interfaces which can be used to guess or brute force administrative passwords.

Description of the Issue

With the proliferation of virtual web servers, the traditional 1:1-type relationship between an IP address and a web server is losing much of its original significance. It is not uncommon to have multiple web sites / applications whose symbolic names resolve to the same IP address (this scenario is not limited to hosting environments, but also applies to ordinary corporate environments as well).

As a security professional, you are sometimes given a set of IP addresses (or possibly just one) as a target to test. No other knowledge. It is arguable that this scenario is more akin to a pentest-type engagement, but, in any case, it is expected that such an assignment would test all web applications accessible through this target (and possibly other things). The problem is that the given IP address hosts an http service on port 80, but if you access it by specifying the IP address (which is all you know) it reports "No web server configured at this address" or a similar message. But that system could "hide" a bunch of web applications, associated to unrelated symbolic (DNS) names. Obviously, the extent of your analysis is deeply affected by the fact that you test the applications, or you do not - because you don't notice them, or you notice only SOME of them. Sometimes the target specification is richer – maybe you are handed out a list of IP addresses and their corresponding symbolic names. Nevertheless, this list might convey partial information, i.e. it could omit some symbolic names – and the client may not even being aware of that! (this is more likely to happen in large organizations).

Other issues affecting the scope of the assessment are represented by web applications published at non-obvious URLs (e.g.,, which are not referenced elsewhere. 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 a web application discovery.

Black Box testing and example

Web application discovery

Web application discovery is a process aimed at identifying web applications on 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”), the assessment should strive to be the most comprehensive in scope, i.e. it should identify all the applications accessible through the given target. In the following examples, we will examine a few techniques that can be employed to achieve this goal.

Notes 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 which, unless indicated otherwise, represent generic IP addresses and are used only for anonymity purposes.

There are two 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, i.e. with this shorthand notation we think of the web application originating at (the same applies for https). However, 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: In this case, the URL would not be associated to a meaningful page, and the three applications would be “hidden” unless we explicitly know how to reach them, i.e. we know url1, url2 or url3. There is usually no need to publish web applications in this way, unless you don’t want them to be accessible in a standard way, and you are prepared to inform your 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]:// For example,

There is another factor affecting how many web applications are related to a given IP address.

3. Virtual hosts DNS allows us to associate a single IP address to one or more symbolic names. For example, the IP address might be associated to DNS names,, (actually, 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].

We would not suspect the existence of other web applications in addition to the obvious, unless we know of and

Approaches to address issue 1 - non-standard URLs There is no way to absolutely ascertain the existence of non-standard-named web applications. Being non-standard, there is no magic recipe handing them out. However, we may employ a few criteria that will aid in their quest. First, if the web server is misconfigured and allows directory browsing, it may be possible to spot these applications. Vulnerability scanners may help with this respect. Second, these applications might be referenced by other web pages; as such, there is a chance that they have been spidered and indexed by web search engines. If we suspect the existence of such “hidden” applications on we could do a bit of googling using the site operator and examining the result of a query for “site:”. 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, while this URL could not be referenced anywhere (after all, employees would know where the webmail application is located, while there is no reason to tell this information to outsiders by publishing it onto the corporate web site). The same holds for administrative interfaces, which may be published at standard 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 with 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 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 –P0 –sT –sV –p1-65535

It is sufficient to examine the output and looking for http or the indication of SSL-wrapped services (which should be probed to confirm they are https). For example, the output of the previous command could look like

Interesting ports on
(The 65527 ports scanned but not shown below are in state: closed)
22/tcp    open  ssh         OpenSSH 3.5p1 (protocol 1.99)
80/tcp    open  http        Apache httpd 2.0.40 ((Red Hat Linux))
443/tcp   open  ssl         OpenSSL
901/tcp   open  http        Samba SWAT administration server
1241/tcp  open  ssl         Nessus security scanner
3690/tcp  open  unknown
8000/tcp  open  http-alt?
8080/tcp  open  http        Apache Tomcat/Coyote JSP engine 1.1

From this example, we see that

  • There is an Apache http server running on port 80
  • It looks like there is an https server on port 443 (but this needs to be confirmed; for example, by visiting with a browser)
  • On port 901 there is a Samba SWAT web interface
  • The service on port 1241 is not https, but is the SSL-wrapped Nessus daemon
  • Port 3690 features an unspecified service (nmap gives back its fingerprint - here omitted for clarity - together with instructions to submit it for incorporation in the nmap fingerprint database, provided you know which service it represents)
  • Another unspecified service on port 8000; this might possibly be http, since it is not uncommon to find http servers on this port. Let's give it a look:
$ telnet 8000
Connected to
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 200 OK
pragma: no-cache
Content-Type: text/html
Server: MX4J-HTTPD/1.0
expires: now
Cache-Control: no-cache


This confirms that in fact it is an HTTP server. Alternatively, we could have visited the URL with a web browser; or used the GET or HEAD Perl commands, which mimic HTTP interactions such as the one given above (however HEAD requests may not be honored by all servers)

  • Apache Tomcat running on port 8080

The same task may be performed by vulnerability scanners – but first check that your scanner of choice is able to identify http[s] services running on non-standard ports. For example, Nessus [3] is capable of identifying them on arbitrary ports (provided you instruct it to scan all the ports), and will provide – with respect to nmap – a number of tests on known web server vulnerabilities, as well as on the SSL configuration of https services. As hinted before, Nessus is also able to spot popular applications / web interfaces which could otherwise go unnoticed (for example, a Tomcat administrative interface).

Approaches to address issue 3 - virtual hosts There are a number of techniques which may be used to identify DNS names associated to a given IP address x.y.z.t.

DNS zone transfers This technique has limited use nowadays, given the fact that zone transfers are largely not honored by DNS servers. However, it may be worth a try. First of all, we must determine the name servers serving x.y.z.t. If a symbolic name is known for x.y.z.t (let it be, its name servers can be determined by means of tools such as nslookup, host or dig by requesting DNS NS records. If no symbolic names are known for x.y.z.t, but your target definition contains at least a symbolic name, you may try to apply the same process and query the name server of that name (hoping that x.y.z.t will be served as well by that name server). For example, if your target consists of the IP address x.y.z.t and of, determine the name servers for domain

Example: identifying name servers by using host

$ host -t ns is an alias for name server name server

A zone transfer may now be requested to the name servers for domain; if you are lucky, you will get back a list of the DNS entries for this domain. This will include the obvious and the not-so-obvious and (and possibly others). Check all names returned by the zone transfer and consider all of those which are related to the target being evaluated.

Trying to request a zone transfer for from one of its name servers

$ host -l
Using domain server:

Host not found: 5(REFUSED)
; Transfer failed.

DNS inverse queries This process is similar to the previous one, but relies on inverse (PTR) DNS records. Rather than requesting a zone transfer, try setting the record type to PTR and issue a query on the given IP address. If you are lucky, you may get back a DNS name entry. This technique relies on the existence of IP-to-symbolic name maps, which is not granted.

Web-based DNS searches This kind of search is akin to DNS zone transfer, but relies on web-based services which allow it to perform name-based searched on DNS. One such a service is the Netcraft Search DNS service, available at You may query for a list of names belonging to your domain of choice, such as Then you will check whether the names you obtained are pertinent to the target you are examining.

Reverse-IP services Reverse-IP services are similar to DNS inverse queries, with the difference that you query a web-based application instead of a name server. There is a number of such services available. Since they tend to return partial (and often different) results, it is better to use multiple services to obtain a more comprehensive analysis.

Domain tools reverse IP: (requires free membership)

MSN search: syntax: "ip:x.x.x.x" (without the quotes)

Webhosting info: syntax:

DNSstuff: (multiple services available) (multiple queries on domains and IP addresses, requires installation)

tomDNS: (some services are still private at the time of writing) (reverse ip/domain lookup)

The following example shows the result of a query to one of the above reverse IP services to, the IP address of Three additional non-obvious symbolic names mapping to the same address have been revealed.


Googling After you have gathered the most information you can with the previous techniques, you can rely on search engines to possibly refine and increment your analysis. This may yield evidence of additional symbolic names belonging to your target, or applications accessible via non-obvious URLs. For instance, considering the previous example regarding, you could query Google and other search engines looking for information (hence, DNS names) related to the newly discovered domains of,, Googling techniques are explained in Spidering and googling AoC.

Gray Box testing and example

Not applicable. The methodology remains the same listed in Black Box testing no matter how much information you start with.


Whitepapers [1] RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1


OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents