How can I control whether a cookie is sent to a domain other than the one from which it was created?

Question

I am trying to write a program that will verify that all cookies sent from a computer are actually sent to the domain from which they came. This is part of a larger security project to detect malicious cookie attacks (such as XSS). The main obstacle for this project is the actual detection of cookies. Can someone point me in the right direction to track outgoing HTTP traffic for cookie information? Other project information: This is a Windows application written in C and many scripting languages. Many thanks for the help.

Answer 1

You can use the Firefox add-on to read all the cookies used by the browser, the browser knows which cookies it has, and the domain it belongs to. You can then modify Tamper-Data to sniff all outgoing HTTP requests and look for the cookie value, even more you can refuse the request or change it before it is transmitted.

This will never stop the attacker. For an attacker, the cookie value is trivial for Obfuscate / Encode / Encrypt before passing.

HttpOnlyCookies is the best (but not complete) solution to this problem. If this header element is set and the browser supports it, then javascript will not be able to access document.cookie. But an attacker can use XmlHttpRequest to pick up requests to the system, thus “riding” in an authenticated session.

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

Answer 2

You cannot smell cookies in an outgoing request. Assuming you get regular expressions for regular session identifier formats, it still doesn't solve anything. An attacker simply breaks into a few requests and dodges the filter. Or maybe he will somehow encrypt it.

If an e-mail or forum website has an XSS vulnerability, an attacker could simply publish a cookie on the same public website, and then read the session ID. Your filter is not wiser, because even if it finds a cookie in the request, it is sent to the same site .. therefore, you cannot throw an exception.

There are many ways to avoid the filter. I do not think this is a workable project.

Answer 3

You can smell the non-SSL content that your browser sends over everything you need by running its traffic through a proxy server and having it all. You can also use SSL proxy interception if you are prepared to put up with "insecure certificate" warnings.

On the other hand, if, say, a domain name service is compromised in your area, who knows where your browser really sends things.

I agree with everyone who suggests that eavesdropping like this will not necessarily prove anything. Also, that the reverse application may convey something, but that you will miss it because of obfuscation.