How guarantee the fingerprint value was not faked in the request from client side

Question

A JS fingerprint is calculated in client side using a library like fingerprint2.

My question is, If i send this value through ajax, the user can fake this value with a minor effort, and just make a fake post request that will be interpreted by server code like legit.

My question is, if this can happen, this library can be easily bypassed without even change any property in browser (that will change the browser fingerprint).

My interpretation is right? How can i ensure the integrity of that value?

Cufic

Answer 1

You can't, and I wouldn't really worry about it.

Rule number 1: All input coming from the users computer can be faked and can't be relied on 100%.

If you want you can double with with serverside fingerprinting with libraries as piwik device detector to match up data, but you're giving yourself a headache without cause.

90% of the users visiting you, will not have a clue what you are doing and provide you with reliable data. They won't even have an adblock. They will give you reliable data.

9% of the visitors might have an adblocker, which may or may not block those ajax requests. They wish you to respect their privacy, do that so you keep them as customers. 1% might know what those ajax requests do, but they'll never find out because they can't be bothered to inspect the console of every website their visit. 1% of that 1% might take a peek at the browser console and figure out the browser finger printing.

1% of that 1% of that 1% will steal your fingerprinting code. another 1% of the 1% of the 1% will try to fake it just for the lulz and then forget about it.

So in short, don't bother. people won't bother either.

But if you really must bother, and give yourself a headache:

• store a userid in your database on the clients computer in the form of a tracking cookie. Also store it in the session storage, local storage, any database engines the browser may provide. (note that you need to put it in your cookie usage disclaimer why you are storing data on the users computer when european users visit your site)
• use that userid to match finger print to user. Note that this id may be deleted at any time by any cache clearing mechanic(cccleaner, virus scanner, user clicking on empty history, etc..)
• put the user id in the window.name object. as long as the tab is open, used it will be persisted, and try to reset/save it on the users computer.
• Add an E-TAG to your images, the users computer will try to request that image with that etag number the next time he comes. Intercept that request(don't let the webserver handle it, but handle it in php/jsp/asp/whatever) so you can identify the user. Set a session variable with the correct userid and 'respond' that the image is still valid under that etag value and return with cookies the correct user id
• put "timestamp" values behind a javascript request based on the user id and set the requested page including that javascript file to expire in what, 180 days or so. Each time the user comes back and the user has not cleared his history, it'll make the javascript request with the given "timestamp" get parameter gotcha.js?time=1283737273873 use serverside scripting again to intercept. You can then use ajax to update the contents of the page.
• include something like google maps on your page. If they use gmail or any google service and they gave consent to google for setting cookies google will dump their browser full of cookies, which might persist for a while. google maps cookies stay the same for at least the browser session and are readable by javascript/serverside script.
• use piwik device detector to build a server side browser fingerprint, use it to narrow down guesses as to which user it is.
• encode your request as a bytebuffer/stream and base64 encode it to make guessing of what its harder, even if they base64 decode it and send the request in two parts, one with verification hash, and one with the fingerprint. then match the hash and contents and if it matches you can be sure that if it's spoofed someone went through a lot of effort.
• minify and obfuscate your code, also at a lot of useless sidestreets in your javascript code. Put each line in its own function and chain them together to make a cohesive thing. make it too much effort to deduct what's going on there.

Other than that, I really can recommend you: don't bother. it's not worth the effort. people who want to circumvent will circumvent. they'll disable javascript, exclude that script, erase all cookies before continuing or leaving the site, change registered fonts plugins, etc... Don't chase those that don't wish to be chased. Focus on the group who doesn't care.

Repressive

great answer, but can you help me understand how does server-side fingerprinting works ? What is sense is they would have same data as client side, only additionally might run some complex algorithms to spot if the dataset is fishy ? – Kelcie

Answer 2

How can i ensure the integrity of that value?

To answer you very briefly, whenever you want to protect your integrity, you must provide the digest of the sent message too.

Here I explain the defense of integrity using Alice (FrontEnd), Bob (BackEnd), and Trudy (malicious user)

Assumption:

Alice wants to send a package contains PLAIN_TEXT (here your fingerprint) to Bob, and Trudy is the malicious person who wishes to intercept the package and change the PLAIN_TEXT.

---

Threats against integrity :

Trudy can capture the PLAIN_TEXT and change it to whatever she wants. (In reality there could be more threats against integrity, but I wish to keep the story short.)

---

Here are the steps which Alice must take to protect the integrity of package:

1. Alice obtains the digest of PLAIN_TEXT (called text_digest).
2. Alice attaches the digest to the PLAIN_TEXT, and obtain a new package (package=PLAIN_TEXT+text_digest)
3. Alice encrypts the package
4. Alice obtains the digest of the encrypted package (whole_package_digest)
5. Alice attaches the whole_package_digest to the encrypted package, and send it to Bob

---

What Trudy can do after inteception:

Option 1. Try to break the encryption of the package

Option 2. Try to omit the encrypted package and attach her own package.

---

On Bob's side:

1. He decrypts the package, and obtains the PLAIN_TEXT. (he makes sure Alice has send this package, because no one else has the key )

2. He obtains the the digest of the PLAIN_TEXT using the same method (let's call this obtained_digest), and he compares the obtained_digest with the text_digest, and if they are equal then it means the PLAIN_TEXT is not manipulated.

3. At the end, he obtains the digest of the received package, and compares it with whole_package_digest. If they are equal it means Trudy has failed with her second option.

Notice that in above scenario, the integrity is highly dependent on confidentiality. But, you can use both symmetric, and asymmetric method for encryption.

In the below image, I tried to explain what I wanted to say more clearly:

Bashan

You're going much further than the question asker asked. it's not so much about data interception, but more about getting accurate browser fingerprints, without those being manipulated by the user who might be faking them, switching them around, so he/she can't be followed for advertising purposes/tracking user data and such. – Repressive

and in addition to above answer you can add the time stamp in post request as well as in hash of the request so that even if some one tries to replay the same request you can verify that with the time stamp and you can add some random string as well while creating message digest and this salt would be known to only client and server – Gerhart

@Gerhart you are right. but i wanted to keep my answer simple and understandable. Adding the time-stamp makes the digest even stronger. – Bashan

@Repressive I think above solution would work because the fakr wont know the formula of creating hash i.e. whether hashed string was plaintext+salt or salt+plaintext or something salt+plaintext+salt – Gerhart

@Gerhart The data comes from the users browser. The user can fake his fingerprint by using a browser plugin that shifts the registered fonts, plugins, etc.. or by changing the browser version/agent id, which makes the browser fingerprint unreliable. That is the issue OP is asking. Not about a man in the middle attack. OP wants to guarantee that the fingerprint he/she gets is reliable to be used to track the user/identify the user, and that the user won't spoof the info his browser supplies so OP can reliably identify the user to serve ads, deals, or other customized services. – Repressive

@Repressive I think it is about man in middle attack because of statement If i send this value through ajax, the user can fake this value with a minor effort, and just make a fake post request still I leave it on discretion of the questioner to decide whether the above answer was helpful or not. – Gerhart

@Gerhart i also understand the question as u. For me, they are the same. Either, man in the middle, or the user changes some values using some tricks. What important is protecting the integrity of data. No matter, where, and who jeopardize it. – Bashan

@Salman You're running code on the users computer. The integrity is void. The user has full control over his computer, and he can replay all those requests with one snip of his finger. Just go in chrome to network, click on xhr, you see all headers and data that's sent, and he can simply replay the same info, even click multiple pages on to have some variation and send it as noise. Entering debugger mode he can trace al your javascript hashing points easy. There is no data integrity. don't focus on those that wish to meddle, focus on those that don't care. fingerprints and cookies = unreliable – Repressive

@Repressive i know, the user can change all the data which he has received. But, my solution tries to prevent sending or receiving fake data. Surely, malicious user fabricate data, but his requests with fabricated data would be invalid. – Bashan

you can never reliably trust user sent data that it isn't faked, or composed by a script by the user. It only takes me 5 minutes on any site to send some faked requests. with chrome it's really easy to neatly format code, step throught he debugger and doing live modifications of the code running on client side. If the code is 100% generated by fingerprint, then hashed, then sent all by the same user computer, it can be easily faked. Your server cannot distinguish fake data or real data because it doesn't collect it. focus your energies on conversion on non coder clients. That's more profitable – Repressive

Answer 3

Checking the integrity of client side fingerprint is not possible.... The best bet for you is to use PHP to detect the internal systems... I wrote a library to that but not published... If you need it I can send it to you...

What this library does is to detect the Mac address of the device... Since two system can't have same Mac address... It's a very good way of getting accurate fingerprint.

Evangelicalism