3

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.

1
  • 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
    Commented Aug 24, 2011 at 19:46

5 Answers 5

7

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.
2
  • 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
    Commented Aug 31, 2011 at 23:27
  • Also it lets the attacker access a Web server on private IP address or on a public IP by behind a firewall!
    – curiousguy
    Commented Jun 20, 2018 at 17:05
2

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.

1

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.

1

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.

-1

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.

2
  • Do you know if this is possible with firebug? I don't how to attack a breakpoint to an element.
    – fiftyeight
    Commented Aug 24, 2011 at 21:31
  • 1
    Why was this -1'ed?
    – Steve
    Commented Aug 28, 2011 at 22:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .