views:

59

answers:

2

I am working on implementing a JavaScript web bug that will be inserted into our client's web pages. One of the features our clients would like, is a way to pass pieces of the HTML on their web pages to our server through the web bug. We are using JSONP and the server that is hosting the JavaScript web bug is different than the server hosting the we page. The basic idea is this:

var element = document.getElementById(id);
var html = element.innerHTML;
//Encodes HTML into GET request www.example.com/script?html=encodedhtml
var url = getSrcUrl(html); 
document.write(unescape("%3Cscript src='" + url + "' type='text/javascript'%3E%3C/script%3E"));

The security problem is that anyone could make a get request to our server with arbitrary HTML that isn't from the web page that is hosting the web bug. Is there anyway to make this secure?

I know we could check HTTP headers for the referrer, but this can easily be forged. I saw some ideas where the server passed a unique token that had to be returned in the GET request, but it seems like this could be forged too.

My hunch is that what we're trying to do can't be done securely, but I wanted to throw this out to the community to see if there's something clever that can be done. Otherwise, I'm going to have to build a screen scrapper that downloads the pages directly from our clients and extracts the relevant HTML for their page.

Thanks for any and all help!

EDIT

To be clear, our client's web pages are public-facing without security. In other words, any Internet user could visit the page and execute the JavaScript bug that submits the HTML fragment.

EDIT 2

An acceptable answer is "this is impossible"! If that is the case, and you give a good explanation of why, I will choose it as the accepted answer.

EDIT 3

What we are building is a kind of Google Analytics system for our clients. We are trying to track visits to unique "items" by each visitor and then automatically collecting information about that item via the HTML fragment. We will then insert information about the item on other pages by injecting the HTML fragment that we collected from the original item. We are trying to do all this without requiring our clients to install anything on their severs and by just including out JavaScript web bug in their HTML.

+1  A: 

If you want to ensure something wasn't tampered with, it cannot go through the client unencrypted.

The only ways to do this securely are to:

  • As you suggest, retrieve the appropriate page server-side

or

  • Encrypt/sign the HTML before is goes to the client using a key unknown to them, so that the client cannot modify it
Borealid
Your second idea is clever. I'll have to think about how that could work in our system...
+1  A: 

Assuming you can get your client's web server to md5 something for you, this seems like a good place to use an md5-hashed signature. Essentially, the client server determines which information it would like to send you, concatenates it all into a string, concatenates that with a secret key, and then md5's the whole thing, and passes the result along with all the rest of its input.

On your server, you take all of the input except that signature, concatenate it together, concatenate the secret key onto that, and md5 it. If it matches the signature, you know it's valid input.

Unfortunately, it looks like you're determining the HTML to send on the client (browser) side. Due to the fact that JavaScript is plainly visible for all to see, you can't really use a secret string.

So, unless it's possible to move that kind of processing to the server side, I think you're out of luck.

Ryan Kinal
Why are people still suggesting md5 for secure hashes?
Borealid
Because it's what we've all gotten used to. If it's not secure enough for you, then use something else.
Ryan Kinal
This is really widely misunderstood. MD5 in this case is fine. Because it has been demonstrated that you can deliberately create two documents with the same MD5 hash, you shouldn't trust MD5 hashes to verify documents you didn't yourself create (the authors might have produced two versions of the file, one good and the other evil). But if you yourself created both the string and the hash, this risk is basically nil. If you use a long enough salt, you can defend against rainbow attacks. And if you include a timestamp and change your salt regularly, you can resist against brute-force attacks.
Andrew