Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm looking as some web analytics solutions, I know it sounds paranoid.
but cookie-based web analytics need for you to paste their JavaScript code on your web-site.

I don't like the idea too much of just pasting scripts on my web-site that I don't know.
So I want to check if these scripts send to another server the session cookies of my website's users.

Some ways I though of are:

  1. Use firebug to see all the requests made - the problem is that the script might encrypt the cookies in some way so I won't see the cookies as plaintext.

  2. Search the JavaScript code for terms like "document.cookie"

What do you think?
And will setting the session cookie to HttpOnly completely disable this?

Thanx in advance.

share|improve this question
    
Seems to me that analytics is overused. I find it annoying, it doesn't make my NoScript whitelist, and I also tend to avoid sites that use it. Maybe you have some need for it, I don't know, but I wouldn't use it without a really good reason to. –  Michael Aug 24 '11 at 19:46

5 Answers 5

up vote 5 down vote accepted

I think your premises does not get the whole issue:

  • The script you embed from external sources can be changed at a later time.
  • Stealing the session cookie is just an easy way to leverage and XSS vulnerability. Instead of stealing the cookie and using it from another computer to do malicious things, the malicious script can do those things directly without steeling the cookie. This has a number of advantages from the attackers point of view:

    1. It works with the HttpOnly flag since the script just sends the request using the normal browser means such as submitting a form. This can be done in an hidden iframe
    2. It does not reveal the ip-address of the attacker to the server. This is especially true in the context of reflective XSS attacks.
    3. It does work with additional authentication mechanisms such as http basic auth or binding the session to the client ip-address.
share|improve this answer
    
yes you're right about what you say, overall would you say that the only way to detect XSS scripts is to read the whole script? –  fiftyeight Aug 31 '11 at 23:27

You could actually detect it by overriding the cookie getter using __definegetter__ :

document.__defineGetter__("cookie", function() { /*report stolen */ });

However this can be undone by the javascript in question using:

delete document.cookie;

before trying to access it.

In ECMASCRIPT 5, the new javascript standard, you can actually override it in a way that it can't be undone.

Object.defineProperty(document, "cookie", { get: function() { /* report stolen */ }, set: function() { }, configurable: false })

The configurable flag makes it impossible for script loaded later in the page to override or delete.

Though as mentioned in other answers, the script can do anything on behalf of the user (CSRF), so I'm not sure this will get you anywhere.

share|improve this answer

First of all - yes, settings cookies as HttpOnly will prevent any JavaScript code to access your cookies in commonly used browsers.

You can search the script for document.cookie, but it can be obfuscated and you cannot be sure if you think about all ways the attacker can access cookies. One example could be:

var a="cookie", b;
for(c in document) {
    if(c == a) b = document[c];
}
alert(b);

I'm sure there are other ways how to hide your intention, when trying to attack the web page. About the requests inspection - could be interesting to see what's going on, but as you stated, the request parameters can be encrypted and you would have to reverse engineer the encryption algorithm from the 3rd party JavaScript code, which could be very time consuming.

share|improve this answer

Unless they're being very careful, you can learn by traffic analysis.

Create a version of the page with x kB of cookies and then observe that they send messages totaling y kB.

Create a version of the page that is the same in all respect but that has x' kB of cookies where x' is significantly larger than x but still within the range of cookies that a normal page might have. Observe that they send messages totaling y' kB.

If y is quite different from y' then you should be very suspicious.

And will setting the session cookie to HttpOnly completely disable this?

Yes, on the browsers that support it.

share|improve this answer

If you attach a debugger to document.cookie and watch for any calls to it then you can see everything the script does with said cookies.

Setting the session cookie to HttpOnly would stop newer browsers from passing the cookie to javascript, but older browsers don't understand HttpOnly.

share|improve this answer
    
Do you know if this is possible with firebug? I don't how to attack a breakpoint to an element. –  fiftyeight Aug 24 '11 at 21:31
    
Why was this -1'ed? –  Steve Aug 28 '11 at 22:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.