Identifying Server-Side Technologies

It is normally possible to fingerprint the technologies employed on the server via various clues and indicators.

Banner Grabbing

Many web servers disclose fine-grained version information, both about the web server software itself and about other components that have been installed. For example, the HTTP Server header discloses a huge amount of detail about some installations:

Server: Apache/1.3.31 (Unix) mod_gzip/ mod_auth_passthrough/1.8
mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.9 FrontPage/
mod_ssl/2.8.20 OpenSSL/0.9.7a

In addition to the Server header, other locations where the type and version of software may be disclosed are:

■ Templates used to build HTML pages
■ Custom HTTP headers
■ URL query string parameters

HTTP Fingerprinting

In principle, any item of information returned by the server may be customized or even deliberately falsified, and banners like the Server header are no exception. Some web server software includes a facility for administrators to set an arbitrary value for the Server header. Further, there are security products that use various methods to try to prevent a web server’s software from being detected, such as ServerMask by Port80 Software. Attempting to grab the server banner from Port80’s own web server does not appear to disclose much useful information:

HTTP/1.1 200 OK
Date: Sun, 04 Mar 2007 16:14:26 GMT
Server: Yes we are using ServerMask!
Set-Cookie: countrycode=UK; path=/
Set-Cookie: ALT.COOKIE.NAME.2=89QMSN102,S62OS21C51N2NP,,0105,N7; path=/
Cache-control: private
Content-Length: 27399

Connection: Keep-Alive
Content-Type: text/html
Set-Cookie: Coyote-2-d1f579d9=ac1000d9:0; path=/

Despite measures such as this, it is usually possible for a determined attacker to use other aspects of the web server’s behavior to determine the software in use, or at least narrow down the range of possibilities. The HTTP specification contains a lot of detail that is optional or left to an implementer’s discretion. Further, many web servers deviate from or extend the specification in various different ways. As a result, there are numerous subtle ways in which a web server can be fingerprinted, other than via its Server banner. Httprint is a handy tool that performs a number of tests in an attempt to fingerprint a web server’s software. In the case of Port80 Software’s server, it reports with a 58% degree of confidence that the server software in use is in fact Microsoft IIS version 5.1, as shown in Figure 1.

Screenshot from 2020-04-23 01:12:42

Figure – 1: Httprint fingerprinting various different web servers

The screenshot also illustrates how Httprint can defeat other kinds of attempts to mislead about the web server software being used. The Found stone web site uses a misleading banner, but Httprint can still discover the actual software. And the RedHat server is configured to present the nonverbose banner “Apache,” but Httprint is able to deduce the specific version of Apache being used with a high degree of confidence.

File Extensions
File extensions used within URLs often disclose the platform or programming language used to implement the relevant functionality. For example:

■ asp — Microsoft Active Server Pages
■ aspx — Microsoft ASP.NET
■ jsp — Java Server Pages
■ cfm — Cold Fusion
■ php — the PHP language
■ d2w — WebSphere
■ pl — the Perl language
■ py — the Python language
■ dll — usually compiled native code (C or C++)
■ nsf or ntf — Lotus Domino

Even if an application does not employ a particular file extension in its published content, it is usually possible to verify whether the technology supporting that extension is implemented on the server. For example, if ASP.NET is installed, requesting a nonexistent .aspx file will return a customized error page generated by the ASP.NET framework, as shown in Figure -2, whereas requesting a nonexistent file with a different extension returns a generic error message generated by the web server, as shown in Figure -3.

Screenshot from 2020-04-23 01:15:35

Figure -2: A customized error page indicating that the ASP.NET platform is present
on the server

Screenshot from 2020-04-23 01:16:23

Figure -3: A generic error message created when an unrecognized file extension is

Using the automated content discovery techniques already described, it is possible to request a large number of common file extensions and quickly confirm whether any of the associated technologies are implemented on the server.

The divergent behavior described arises because many web servers map specific file extensions to particular server-side components. Each different component may handle errors (including requests for nonexistent content) in a different way. Figure -4 shows the various extensions that are mapped to different handler DLLs in a default installation of IIS 5.0.

Screenshot from 2020-04-23 01:18:12

Figure -4: File extension mappings in IIS 5.0

different error messages generated when that file extension is requested. In some cases, discovering a particular mapping may indicate the presence of a web server vulnerability — for example, the .printer and .ida / .idq handlers in IIS have in the past been found vulnerable to buffer overflow vulnerabilities.

Another common fingerprint to be aware of are URLs that look like the following:


The comma-separated numbers towards the end of the URL are usually generated by the Vignette content management platform.

Directory Names

It is common to encounter subdirectory names that indicate the presence of an associated technology. For example:

■ servlet — Java servlets
■ pls — Oracle Application Server PL/SQL gateway
■ cfdocs or cfide — Cold Fusion
■ SilverStream — The SilverStream web server
■ WebObjects or {function}.woa — Apple WebObjects
■ rails — Ruby on Rails

Session Tokens

Many web servers and web application platforms generate session tokens by default with names that provide information about the technology in use. For example:

■ JSESSIONID — The Java Platform
■ ASPSESSIONID — Microsoft IIS server
■ ASP.NET_SessionId — Microsoft ASP.NET
■ CFID / CFTOKEN — Cold Fusion

Third-Party Code Components

Many web applications incorporate third-party code components to implement common functionality such as shopping carts, login mechanisms, and message boards. These may be open source or may have been purchased from an external software developer. When this is the case, the same components often appear within numerous other web applications on the Internet, which you can inspect to understand how the component functions. Often, different features of the same component will be made use of by other applications, enabling you to identify additional behavior and functionality beyond what is directly visible in the target application. Also, the software may contain known vulnerabilities that have been discussed elsewhere, or you may be able to download and install the component yourself and perform a source code review or probe it for defects in a controlled way.

NEXT is..Identifying Server-Side Functionality……,