How can ASP.NET or ASP.NET MVC be protected from related domain cookie attacks?

Channel Bound Cookies

The following Proposed RFC comes from a Google employee and describes a way for Clients use a self-signed Browser Certificate (thus requiring no confusing "pop-up" for the end user) which can also address the cookie security issue known as "Related Domain Cookies"

What follows below is an extract of http://www.browserauth.net/ , a section of the RFC, some interesting commentary, and some criticism on this extension.

Overview of Channel Bound Cookies

Once the underlying TLS channel uses TLS client authentication (with the TLS-OBC extension), the server can bind its cookies to the TLS channel by associating them with the client's public key, and ensuring that the cookies are only ever used over TLS channels authenticated with that public (client) key.

This means that if such a channel-bound cookie is ever stolen off a client's machine, that cookie won't be able to authenticate an HTTP session to the server from other machines. This includes man-in-the-middle attackers that inject themselves into the connection between client and server, perhaps by tricking users into clicking through certificate-mismatch warnings: such a man-in-the-middle will have to generate its own TLS session with the server, which won't match the channel that the cookie is bound it.

Channel Binding

It's up to the server to decide whether to bind cookies to TLS channels. If the client doesn't support TLS-OBC, or if the cookie it's about to set will be used across different origins, then the server will not channel-bind the cookie. If it does decide to channel-bind the cookie, it should associate the cookie with the client's public key. This is similar to RFC 5929, but instead of the client binding data to the server's public key, in this case the server would be binding data (the cookie) to the client's public key. The server can do this either by simply storing, in a backend database, the fact that a certain HTTP session is expected to be authenticated with a certain client public key, or it can use suitable cryptography to encode in the cookie itself which TLS client public key that cookie is bound to.

In the figure above, the server includes the client's public key into a cryptographically signed datastructure that also includes the authenticated user's id. When the server receives the cookie back from the client, it can verify that it indeed issued the cookie (by checking the signature on the cookie), and verify that the cookie was sent over the correct channel (by matching the TLS client key with the key mentioned in the cookie).

To be continued here.... http://www.browserauth.net/channel-bound-cookies

RFC Snip

TLS Origin-Bound Certificates RFC Draft

(Excerpt)

4.3. Cookie Hardening

One way TLS-OBC can be used to strengthen cookie-basedauthentication is by "binding" cookies to an origin-boundcertificate. The server, when issuing a cookie for an HTTPsession, would associate the client's origin-bound certificate withthe session (either by encoding information about the certificateunforgeably in the cookie, or by associating the certificate withthe cookie's session through some other means). That way, if andwhen a cookie gets stolen from a client, it cannot be used over aTLS connection initiated by a different client - the cookie thiefwould also have to steal the private key associated with theclient's origin-bound certificate, a task considerably harderespecially when we assume the existence of a Trusted PlatformModule or other Secure Element that can store the
origin-bound-certificate's private key.

Additional Commentary from public-web-security@w3.org

Also, note that somewhat counter-intuitively, channel-bound cookies protect against many related-domain attacks even if the client cert that they are bound to has broader scope than a web origin.

Imagine, for a moment, that a user-agent creates a single self-signed certificate that it uses as a TLS client cert for all connections to all servers (not a good idea in terms of privacy, but follow me along for this thought experiment). The servers then set cookies on their respective top-level domains, but channel-bind them to the user-agent's one-and-only client cert.

So, let's say that an app app.heroku.com sets a (channel-bound) cookie on my browser for domain .heroku.com, and that there is an attacker on attacker.heroku.com. One attack we might be concerned about is that the attacker simply harvests the .heroku.com cookie from my browser by luring me to attacker.heroku.com. They won't be able to actually use the cookie, however, because the cookie is channel-bound to my browser's client cert, not to the attacker's client cert.

Another attack we might be concerned about is that attacker.heroku.com sets an .heroku.com cookie on my user agent in order to make me log into app.heroku.com as himself. Again, assuming that the only way the attacker can obtain the cookies is by getting them from app.heroku.com, this means that the cookies he has at his disposal will be channel-bound to his client cert, not to my client cert - thus when my browser sends them to app.heroku.com they won't be valid.

The TLS-OBC proposal, of course, assumes more fine-grained "scopes" for the client certificates. The reason for that, however, is purely to prevent tracking across unrelated domains. Related-domain attacks are already mitigated even if we used coarse-grained client certificates and coarse-grained (i.e., domain) cookies. I, at least, found this a little counter-intuitive at first, since the other proposed defense it to forbid coarse-grained cookies altogether and use origin cookies instead.

Criticism from public-web-security@w3.org

There are a number of issues that need to be considered for TLS-OBC; I'll highlight a couple here that I'm aware of.

1. Some SSL handshake logic may need to be modified slightly; see https://bugzilla.mozilla.org/show_bug.cgi?id=681839 for technical discussion.

2. There are potential privacy considerations; in particular if the unique client certificate is sent in cleartext before the negotiation of the master secret, a passive network observer may be able to uniquely identify a client machine. The attacker would already have the client's IP address, so this isn't a huge problem if the certificate is regenerated on an IP address change, but that would nullify much of the authentication benefit. A proposal to allow a client certificate to be sent after the master secret negotiation has been made. (can't find the bug right now, sorry)

3. One proposal how #2 could be addressed is here: https://datatracker.ietf.org/doc/html/draft-agl-tls-encryptedclientcerts

4. There are tricky interactions with SPDY. There will be updates on browserauth.net for this.

Fix the RFCs

The core issue here seems to be that any host can write a cookie that can be overwritten by any other host in the same domain. What if there is a way to write a value to the client that absolutely can not be overwritten by any other host? I haven't found anything like that is also automatically included in the HTTP header (like a cookie)

Here are three solutions that might work, though I like Solution 2 or #3 if browsers implement it correctly

Solution 1: Add more information when uploading cookies to the server

When the client sends cookies to the server, also include the domain of the cookie that was sent. The server then knows what domain and path to look for. This means the client adds a new HTTP header Cookie-Details on every request:

GET /spec.html HTTP/1.1Host: www.example.orgCookie: name=value; name2=value2Cookie-Details: name="value":"domain":"path":"IsSecure":"IsHTTPOnly"; name2="value2":"domain2":"path2":"IsSecure":"IsHTTPOnly"Accept: */*

The server can then ignore the details field, or prefer it over the one that doesn't provide the details. The reason I included the "value" field in the details section is because the server would not be able to tell the difference between two cookies that have the domain set to example.com and secure.example.com if they both cookies have the same name. Most browsers will send the values in a random order.

Perhaps this can be optimized so that the server can tell the client if this new cookie format is supported or not, and the client can respond accordingly.

Solution 2: Extend HTML5 LocalStorage so that data is (optionally) automatically inserted into the HTTP header

If we could extend HTML5's LocalStorage to allow a Secure/HTTPOnly data, we can imitate what is done in Solution #1 above, but have the change driven by the HTML5 LocalStorage W3C Working Group

The benefit of this is that there is less overhead than solution #1, since the more verbose cookie details are only sent to the server when its needed. In other words if a sensitive value is saved using the "new cookie details" format into LocalStorage, then there is a clear separation of what data needs to be sent, and in what format.

Solution 3 "Cookie validation"

1. A user visits a web app that has this "special" validation mode enabled.
2. On the HTTP response some cookies are sent to the browser. The cookies can be HTTP Only, Secure, ...anything)
3. A alongside the cookies, another header is sent to the cookies: Set-CookieValidationHash. It contains A JSON array of SHA-256 hashed cookie keys and values, and specifies the expiration of the value
4. The browser then logically ties this header to the cookies with the following behavior
   • This header is placed into a "Cookie Validation Jar" that can only be written to by the same DNS Domain, and DNS Scope
5. This header is opaque to the client and is returned to the server on every HTTP request (like a cookie)
6. The server will use this field to validate the cookies that are sent, and issue an error (or whatever) if the checksum fails.

Sourced from: http://www.w2spconf.com/2011/papers/session-integrity.pdf

5.2. Integrity through Custom Headers

Instead of securing cookies, we can achieve session integrityby choosing a new method of storing and transmitting sessionstate. While this could be done using special browser pluginslike Flash, we would rather choose a design with the fewestdependencies, so we will focus only on basic HTTP tools.The basic form of an HTTP request has very few places thatare suitable for sending data with integrity. Data in the URLor entity body of HTTP requests has no integrity, becausethose parts of the HTTP request are writable across originsand thus spoofable by an attacker. Cookies are also weak inthis regard, as they can be overwritten by the attacker in ourthreat model. However, through the use of a JavaScript APIcalled XMLHttpRequest (XHR), we can send data in a customheader.

Background. XMLHttpRequest (XHR) allows HTTPrequests containing custom headers to be made, and theresponses read, but only to the origin of the executingJavaScript.(See Note5) As a result, requests made via XHR can bedistinguished by a server as necessarily originating from thesite itself.

Design. We will not use cookies at all, and instead passa session identifying token in a custom HTTP header which isonly written via XMLHttpRequest. The server should treat allrequests lacking this custom header, or containing an invalidtoken, as belonging to a new, anonymous session. In order topersist this session identifying token across browser restartsand between different pages of the same application, the tokencan be stored in HTML5 localStorage by JavaScript uponsuccessful authentication.

Security. Observe that in this model, the session identifying token will only be sent to the origin server, and willnot be included in the URL or entity body. These propertiesprovide confidentiality and integrity, respectively. Unlike withcookies, the token cannot be overwritten by the attacker, sincelocalStorage completely partitions data between origins inmost browsers (See Note 6). A site using HTTPS can ensure that the tokenis only sent over HTTPS, thus ensuring the secrecy of thetoken even in the presence of an active network attacker. Inaddition, because this token is not sent automatically by thebrowser, it also serves to protect against CSRF attacks.

Disadvantages. This approach, however, has several disadvantages. First, it requires all requests requiring access toa user’s session to be made using XMLHttpRequest. Merelyadding a session identifying token explicitly to all requests,much less doing them over XHR, would require major changesto most existing websites, and would be cumbersome anddifficult to implement correctly without a framework. Thisis even further complicated if requests for sub-resources likeimages require access to session state, since it is not trivialto load images via XHR. Third, since this design depends onthe presence and security of HTML5 localStorage, it will beimpossible to implement on some legacy browsers

(Note 5) Sites may make cross-site requests using XHR if supported by thebrowser and authorized by the target server

(Note 6) True in Chrome, Firefox, Safari, and Opera on OS X, several Linuxdistributions, and Windows 7. Internet Explorer 8 does not partition HTTPand HTTPS, but Internet Explorer 9 does.