Creates a HSTS Supercookie to fingerprint a browser
JavaScript Python
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
.gitignore Initial commit Dec 19, 2015
LICENSE Initial commit Dec 19, 2015 Update Jan 11, 2016
hsts.js JSLint Jan 12, 2016 Fix off-by-one binary string parsing Dec 30, 2015

HSTS Super Cookie

Proof of Concept - Created by Ben Friedland

Creates a HSTS Supercookie to fingerprint a browser

This is a proof of concept self-hosted application which will lay a "super cookie" using the HSTS web standard.

How it works

HTTP Strict Transport Security (HSTS) is a web security standard implemented by browsers via a Response header which instructs the browser to send subsequent requests to this particular URL over HTTPS, even if the original request was made using HTTP. When a browser receives a HSTS instruction, that instruction is retained no matter what. Even if you go incognito or private.

Why I made this

This HSTS vulnerability has been known about for a while, and - while others have implemented it - I've yet to see someone make the code available. I've always thought that the more transparent a vulnerability is, the more likely it is to be addressed. How this one is addressed is another question.

How I implemented it

It's actually kind of simple. I've created a very basic web server which is hosted behind 24 subdomains (w[0-23], in this example). All of these endpoints send the Strict-Transport-Security header to instruct the client that future visits should be redirected to the https version of the page.

On the first visit

Upon the first request to the index page, a random 24 bit integer is generated by the client.

Let's say the number is 8396804. This will be your fingerprint.

I then convert this integer into binary:


And then map these bits as flags, to request several URLs which are served with the HSTS header. Since this example has 1's in the positions of 0, 10 and 22, I'd request three URLs over https:

I can now guarantee that subsequent visits to the http version of this URL will be redirected to https.

On the next visit

To read the super cookie, I instruct the client to visit all 24 URLs. In this example, since only three of those URLs were visited during the previous visit, I can safely assume only three of these requests will be redirected.

// simplified for clarity
for (var i = 0; i < 24; i++) {
    var url = 'http://w' + i + '';     
    bitArray[i] = hsts.httpGet(url)   // returns true if the request was a redirect

I determine whether the requests were redirected by the browser, and create a bit array with that information.

Requested URL Was Redirected Bit True 1 False 0 False 0 False 0 False 0 False 0 False 0 False 0 False 0 False 0 True 1 False 0 False 0 False 0 False 0 False 0 False 0 False 0 False 0 False 0 False 0 False 0 True 1 False 0

Starting to look familiar?


I then reconstruct that bit array into a integer again, and bam - I've retrieved your fingerprint.

100000000010000000000100 == 8396804

Why it won't be fixed

Because security.

Security seems to be favored over privacy in this case. HSTS is very important because it can prevent MITM attacks when people simply enter into their browser at a new location. If the client didn't store the fact that you always expect facebook to be secure, then a man-in-the-middle could easily intercept the request and serve back a non secure spoofed version of the site.

Where it works

Chrome - very reliable. Works when switching to incognito or even across profiles.

Firefox - Not super reliable, doesn't transfer to incognito.

Safari - Especially scary - since the HSTS information is actually persisted to your iCloud account and is therefore retained across devices.

IE/Edge - Dunno, please contact me or create an issue if you know.


TODO: I need a wildcard SSL cert ($$$) to host a live demo. Care to donate to the cause? BTC: 17FJJYY2B11Bx7xx5HepjJ3xAdaB14UMiw