How can I monitor if a cookie is being sent to a domain other than the one it originated from?

Question

I am trying to write a program that will verify that all cookies sent out from the machine are in fact going to the domain they came from. This is part of a larger security project to detect cookie based malicious attacks (such as XSS). The main snag for this project is actually detecting the out-going cookies. Can someone point me in the right direction for monitoring out-going HTTP traffic for cookie information? Other information about the project: This is a windows application written in C and numerous scripting languages. Thanks so much for the help.

Answer 1

You can't sniff for cookies in an outgoing request. Assuming you get the regexes right for the usual session id formats, it still doesn't solve anything. An attacker will just break into several requests and evade your filter. Or perhaps he will encrypt it in some way.

If its an email/forum website that has an XSS vulnerability, the attacker could just post the cookie to the same public website and then read the session identifier. Your filter is none-the-wiser, because even if it detected a cookie in the request, its is being sent to the same website.. so you can't trigger an exception.

There are countless ways to evade your filter. I don't think its a feasible project.

Answer 2

You can use a Firefox Add-on to read all cookies that the browser is using, the browser knows what cookies it has and the domain that owns them. Then you can modify Tamper-Data to sniff all outgoing http requests and look for the cookie value, further more you could drop a request or modify it before it is transmitted.

This will never stop an attacker. It is trivial for an attacker to Obfuscate/Encode/Encrypt the cookie value before transmission.

HttpOnlyCookies is a better (but not complete) solution to this problem. If this header element is set, and the browser supports it, then javascript will be unable to access document.cookie. But the attacker can use XmlHttpRequest to forge requests against the system, thus "riding" on the authenticated session.

You should PATCH YOUR XSS, protect against XSRF, use https for the entire session and enable HttpOnlyCookies. I recommended that you read A3: "Broken Authentication and Session Management" in The Owasp Top 10 for 2010.

Answer 3

You can sniff the non-SSL stuff your browser sends around all you want by having it run its traffic through a proxy server and having that log everything. You can have the proxy intercept SSL too if you're willing to put up with "insecure certificate" warnings.

On the other hand, if, say the domain name servive is compromised in your vicinity, who knows where your browser is really sending things.

I agree with everyone else who is suggesting that eavesdropping like this is not necessarily going to prove anything. Also that a wayward app may transmit something but that you'll miss it due to obfuscation.