Browserrecon is an open-source application which is able to do an application fingerprinting of web browsers and clients. This is done to determine the used product which might be a requirement in vulnerability analysis (e.g. preparation for an exploitation of a product-related vulnerability).

An advanced fingerprinting software as like browserrecon does not rely on simple announcements by the analyzed software. Administrators or users might be able to alter the User-Agent string so the enumeration will generate a wrong result. Instead browserrecon is doing an analysis of the characteristics of the software behavior which is able to identify altered software as well.

No, as far as I know there are no similar solutions, approaches or methodologies to do a client-side web browser fingerprinting. Because attacks towards clients became more and more popular in criminal attacks (e.g. phishing and pharming), there might be a slight chance that something similar was already known in the underground. [This statement has not been verified yet.]

In most countries it is not illegal to use software for enumeration as long as you do not misuse the gathered data to do a real attack (e.g. stealing data or breaking into a network). However, please consult the laws of your country or ask a lawyer if you are not sure.

Computers and software are just a tool to fullfil a task. I work as a penetration tester and it is very important for me to realize enhanced fingerprinting. Because I believe in sharing knowledge other security consultants

Yes, some similar approaches shall be published in the future. The possibilities range from SMTP headers and FTP clients to Oracle TNS-Listeners and NetBIOS/SMB implementations.

No. Although I do have contact with Sid and think they do a great job, my web browser fingerprinting suite has nothing to do with their proof of concept for visited link enumeration via Cascading Style Sheets. The similarity of the names is just a coincidence.

The browserrecon project and the according software are written and maintained by Marc Ruef. The work began at the beginning of 2008. It was a result of similar projects named httprecon (HTTP-Webserver Fingerprinting) and telnetrecon (Telnet-Server Fingerprinting).

The initial official release of browserrecon was written for PHP and therefore named browserrecon-php. Some months later a port to classic Microsoft ASP (Active Server Pages) was made available under the name browserrecon-asp. This port contains the basic features for browser identification. Updates of the fingerprint data base and further enumeration of proxies is not supported yet. Further releases might be developed under other programming languages (e.g. ASP.NET or JSP).

Yes, a portation to ASP.NET, JSP and CGI is planned. However, there is no official roadmap and date for a release announced.

The browserrecon application and the involved parts (e.g. the data base) underlies the General Public License (GPL) if not other mentioned.

There are several ways how you could support the browserrecon project. FIrst of all you can send me some feature requests and bug reports. Of course you shall use and re-distribute the software. Write articles about the project or mention it in your other work. If you want to help to improve the accuracy of the fingerprinting, upload new fingerprints via the web front end on the project web site. Furthermore, you might be able to change and improve the source-code due to the General Public License (GPL).

The initial release of browserrecon is written in PHP. Therefore, you might be able to use browserrecon on a web server supporting PHP. If you want to include browserrecon in a given web application, the software has to support PHP itself or a fork of the PHP scripts. Because browserrecon requires direct access to the http headers sent to the web server, the framework is not able to run in PHP CGI mode.You have to copy the scripts of browserrecon to your web server. For example you might extract the downloaded archive into the directory /browserrecon. Afterwards you have to include the scripts. In PHP you can use "include('/browserrecon/inc_browserrecon.php');" to include the functionality of browserrecon. Similar is the requirement for the ASP release. This might be included in your applications with the definition of "". See the remarks in the source file of your release.

browserrecon-php was written for PHP 5.x and tested within an Apache environment under Linux. But the application might also be able to run under PHP 4.x and other platforms. browserrecon-asp was written for classic Microsoft ASP (Active Server Pages) and tested under Microsoft IIS 6.0. Other versions might be supported too.

Regarding browserrecon-php there might be several reasons. 1) You are running PHP in CGI mode where the function apache_request_headers() or getallheaders() is not available: It is not possible to get all http headers in PHP with this mode. You might have to switch to the module mode. 2) Or You are using PHP prior 4.3.0 where the function apache_request_headers() does not exist (used within browserrecon 1.0). You would have to replace the according function call with getallheaders() if I am informed correctly. This has already been implemented in browserrecon 1.1. Other problems might arise with browserrecon-asp: 1) Your web service does not have the access permissions for the required files: 1) You have to add further permissions to the according account. 2) Or your web service is not able to initiate the objects Scripting.FileSystemObject (local file access) and Scripting.Dictionary (dictionaries): You have to add further access permissions to the registry at HKLM\SOFTWARE\Classes\.

The current release of browserrecon 1.x is not able to support PHP in CGI mode. The reason is because it is not possible to gather the raw headers sent by the client with apache_request_headers() or getallheaders(). Future releases might also support CGI mode while implementing a workaround for this limitation.

You are able to use the functions of browserrecon within your application. To run an analysis of the client while he was accessing the site you can use "echo browserrecon(getfullheaders());". This will initiate the fingerprinting of the client regarding the headers sent for requesting the given web document. Afterwards the result of the analysis is echoed. In this case you are able to show your visitors that you are able to determine their client software accurately.

The current release of browserrecon contains a data base for header data sent within a common HTTP GET request only. It might be possible to support other request methods as like POST (web forms) or WebDAV-based interaction. Those might be added in a future release of the application.

Usually the analysis with browserrecon is concentrating on live http headers sent by some web clients. In some cases you might want to analyze offline fingerprints collected before. The first parameter of the function browserrecon() expects the headers for analysis. You might use a file content preserved with file($filename) of some web form request via browserrecon($_POST['fingerprint']). It is important that the raw headers do not contain the HTTP request (e.g. GET / HTTP/1.0) on the first line.

The function browserrecon() is able to return different views of the result. This can be defined as 3rd parameter in browserrecon 1.0-php and as 2nd parameter since browserrecon 1.1-php and browserrecon 1.0-asp. To show the best hit alone you might use "echo browserrecon($header, 'besthit');". Other possibilities are "list" for an unordered list of all matches, "besthitlist" for the top ten best matches and "besthitdetail" for the best hit with additional details (e.g. how many hits).

As every fingerprinting application browserrecon tries to identify software by analyzing different fingerprint elements. If it is not possible to dissect and analyze them in detail, the accuracy of the analysis remains on a low level. Fingerprinting is an approximative technique only and is in the case of browserrecon not able to guarantee full accuracy under all circumstances. If you think the results are incorrect or might be able to perfect, upload the fingerprint on the project web site.

A web broxy between a client and the server often has a severe impact in the submitted http request headers. Their order is usually changed, some headers and header values replaced, deleted or added. In such cases the fingerprinting of browserrecon is not as accurate as it could be if a direct connection between client and server would be given. Typical indicators for a proxy are the newly added header lines Via, X-Forwarded-For, Proxy-Connection and X-BlueCoat-Via. browserrecon is able to detect inline proxies since version 1.1 with the function usedproxy().

browserrecon uses a simple data base which contains all the fingerprint elements to determine the given implementation. The data base files are saved as *.fdb for every single test case. They include a two row table: In the first row the name of the implementation and in the second row the known value for this implementation is saved. This CSV file format makes it very easy to edit the files yourself (e.g. with an editor or an external tool).

You are able to add new fingerprints to your data base with the function saveallfingerprintstodatabase(). The first argument defines the raw-headers as they might be collected with getfullheaders() and the second argument is the name of the implementation. If a fingerprint value is already in the data base, no further addition is made as long as you defined the same name for the implementation. It is a requirement that the web server has permissions to write the data base files (*.fdb). However, you might upload your fingerprints to the official fingerprint repository on the project web site so everyone could benefit of your work.

Since the official launch of the project I am collecting new fingerprints of visitors on different sites. New fingerprints are usually added on a daily base. Check the downloads on the project web site to get the latest repository.

No, the current release of browserrecon is not able to provide an auto-update feature for the fingerprint data base. You have to download the latest repository from the project web site yourself. However, such a feature might be implemented in a future release of browserrecon.

There was some major change within the data base structure of header-order.fdb. The version prior browserrecon 1.3 was always printing the characters ", " after an header name. Since browserrecon 1.3 such a trailing character is not used anymore. This means that the data base prior 06/02/2008 is not compatible with browserrecon 1.3 and the data base since the same day is not compatible with older versions of the software. If you use the latest release of browserrecon and the latest data base package, such an imcompatibility should not be given.