0

We have a Javascript file that we have developed for our clients to use. The Javascript snippet takes a screenshot of the website it is run on and then sends it back to our server via jQuery.post()

The nature of our industry means that we have to ensure there is no way that the file can be tampered with by the client.

So the challenge is that we need to make sure that the screenshot was generated by the javascript file hosted on our server, and not one that's been copied or potentially tampered with in any way.

I know that I can get the script location using:

var scripts = document.getElementsByTagName("script"),
src = scripts[scripts.length-1].src;

But this won't help if a client tampers with that part of the SRC.

What methods can I employ to make sure that:

1) The post was made from the javascript file hosted on our server

2) The javascript was not tampered with in any way.

aaroncatlin
  • 3,203
  • 1
  • 16
  • 27
  • 3
    *1)* You can only verify the request headers to ensure where it came from *2)* You simple can't ever verify 100% client side Javascript.. It's all part of the process. *3)* This is more for SecurityExchange IMO. – Pogrindis Apr 07 '16 at 15:07
  • 1
    You basically have to accept that the client side is under the client control and not the server. – apokryfos Apr 07 '16 at 15:13
  • Can you obfuscate the code, and, with the post, send a copy of the script content as text, then compare that with a version on your server to determine if it was tampered with? [obfuscate js](http://stackoverflow.com/questions/194397/how-can-i-obfuscateprotect-javascript) – Jeramiah Harland Apr 07 '16 at 15:26
  • @JeramiahHarland - I don't think that works as technically somebody could replace the portion of the code that sends a copy of the script with the expected script. We have already obfuscated the script anyway. – aaroncatlin Apr 07 '16 at 15:41

1 Answers1

4

Short answer:

  1. You can't.

  2. You can't.

Both stem from the fact that once you hand over something to the client side, it's out of your hands. Nothing will prevent the user from putting a proxy between you and their machine, a process that intercepts content or an extension that tampers content, headers, cookies, requests, responses etc.

You could, however, harden your app by preventing XSS (prevent injection of scripts via user input), using SSL (prevent tampering of the connection), applying CSP (only allow certain content on the page), add CSRF tokens (ensure the form is authorized by the server) and other practices to make it harder for tampered content to get through.

But again, this won't prevent a determined hacker to find an opening.

Joseph
  • 117,725
  • 30
  • 181
  • 234
  • In relation to #1 — Not my specialty, but aren't you able to sign POST requests.. – Pogrindis Apr 07 '16 at 15:44
  • What I'm wondering is if it's possible by some kind of unique token (valid for a short time) embedded into the JS on each load which is authorised by our server and then confirmed again on the server side when the screenshot is sent in. Do you think this could ensure that the request was from our javascript? – aaroncatlin Apr 07 '16 at 15:44
  • 2
    @aaroncatlin: Short answer: Still no. Anything your JavaScript can do, some other code pretending to be your JavaScript can do. – bobince Apr 07 '16 at 20:53