ModSecurity Advanced Topic of the Week: Detecting Browser Fingerprint Changes During Sessions

This blog post will discuss a section from Recipe 8-5: Detecting Browser Fingerprint Changes During Sessions in my book "Web Application Defender's Cookbook: Battling Hackers and Protecting Users".

Web Client Device Fingerprinting

Web client fingerprinting is a centerpiece of modern web fraud detection systems and goes way beyond simply capturing the User-Agent field submitted by clients within web transactions. For instance, common web client fingerprinting usually includes sending client executable code that queries the browser for various settings such as:

• Current screen size
• Time zones
• Browser plug-ins
• Language Settings

Once the client-side fingerprinting code is completed, it then needs to create a new cookie value to pass the data back to the web application for evaluation. The advantage of utilizing client fingerprinting is that it allows you to do two important tasks:

1. Identify clients using real web browsers. If the web client is some type of automated program or script, it most likely will not properly process client-side code such as JavaScript. Without this processing, if a client does not submit the proper fingerprinting cookie, they will be easily blocked.
2. Uniquely identify clients even when their source address locations change. Even if the client IP address changes, the actual browser fingerprint data will not change. This makes this detection superior to relying upon tracking source location changes.

Application Session Tracking with ModSecurity

Before we can set and track client device fingerprints, we first must configure ModSecurity to create Application SessionID-based persistent storage. Basically, we will monitor for any outbound "Set-Cookie" response headers leaving the application that are setting a SessionID. We will then use that data as a "key" to create local collection data. We can then track data about this SessionID. Here is an example rule from the OWASP ModSecurity CRS Session Hijacking conf file that will initiate a local session collection using the ModSecurity setsid action:

## This rule will identify the outbound Set-Cookie SessionID data and capture it in a setsid#SecRule RESPONSE_HEADERS:/Set-Cookie2?/ "(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid).*?=([^\s].*?)\;\s?)" "chain,phase:3,id:'981062',t:none,pass,nolog,capture,setsid:%{TX.6},setvar:session.sessionid=%{TX.6},setvar:tx.ip=%{remote_addr},setvar:tx.ua=%{request_headers.user-agent}"	SecRule UNIQUE_ID "(.*)" "t:none,t:sha1,t:hexEncode,capture,setvar:session.csrf_token=%{TX.1}"

As an example of how this might look, let's use the IBM AppScan demo.testfire.net web application as our demo. When you go to the login page, it will issue a Set-Cookie response header:

The ModSecurity CRS rules shown above would then create the following local persistent storage using the ASP.NET_SessionId value as the key:

collection_store: Retrieving collection (name "default_SESSION", filename "/tmp/default_SESSION")collection_store: Wrote variable: name "__expire_KEY", value "1392833832".collection_store: Wrote variable: name "KEY", value "xhxwbh45kgemppyzubgbevjt".collection_store: Wrote variable: name "TIMEOUT", value "600".collection_store: Wrote variable: name "__key", value "xhxwbh45kgemppyzubgbevjt".collection_store: Wrote variable: name "__name", value "default_SESSION".collection_store: Wrote variable: name "CREATE_TIME", value "1392833232".collection_store: Wrote variable: name "UPDATE_COUNTER", value "1".collection_store: Wrote variable: name "sessionid", value "142746277840".collection_store: Wrote variable: name "csrf_token", value "1dc112da33eaa98e5613787b39f3bc9b10c877d8".collection_store: Wrote variable: name "ip_hash", value "a90c80bf0f0fc7f79224cd129783eaa26c358d5b".collection_store: Wrote variable: name "ua_hash", value "02ef1221431736846709d15d966da967d704d3b8".collection_store: Wrote variable: name "LAST_UPDATE_TIME", value "1392833232".collection_store: Persisted collection (name "default_SESSION", key "xhxwbh45kgemppyzubgbevjt").

Now that we have Session-based storage, we can activate our rules to conduct client device fingerprinting for the duration fo the session.

Client Device Fingerprinting with ModSecurity

The first step in this process is to use ModSecurity to inject JavaScript code links within outbound html response bodies. Here is some example code that achieves this goal:

SecContentInjection OnSecStreamOutBodyInspection On## -=[ Send Browser Fingerprint Code ]=-#SecRule RESPONSE_STATUS "@streq 200" "chain,id:'981802',phase:4,t:none,nolog,pass"        SecRule RESPONSE_HEADERS:Content-Type "@beginsWith text/html" "chain"                SecRule &SESSION:KEY "@eq 1" "chain"                        SecRule STREAM_OUTPUT_BODY "@rsub s/<\/head>/