Take the 2-minute tour ×

The related domain cookie attack (more info) allows machines in the same DNS domain to add additional cookies that will also be sent to other computers in the same domain.

This can cause issues with authentication, or at worst be a component in a confused deputy attack.


How can I protect ASP.NET or ASP.NET MVC from this type of attack?

One possible attack scenario

  1. I log into a "secure" web app
  2. I get the credentials for my account
  3. I trick the user into visiting my site on the same DNS domain
  4. I insert the cookie (of my creds)
  5. the user goes back to your app.
  6. Both cookies (or an overwritten one) is sent to the server
  7. User is doing things under my account

That is a simplified example, but the idea can be ported other style of attacks, Im just picking the scenario that doesn't seem "too bad".

One idea how it can "get bad" is if this was step 1 of a two-step attack. Suppose the user uploaded a bad file that was accessible only in his account; the other user then unwittingly downloads that file, running any executable code that is there.

There are a ton of other scenarios that are possible... rather than list them all here I'm trying to figure out how I can protect my server from this type of attack.

share|improve this question
Good question. The answers so far make me wonder whether a good, general solution to this issue already exists. This might be due to the fact that the impact is rather limited in general (especially because this kind of untrusted co-domain setup is rare and most browsers seem to be rather "random" about which cookie is sent first), but the impact is surely not negligible. I also think that a solution to this wouldn't be bound to a specific technology/framework, so maybe this should be retitled and moved to security.SE? –  Niklas B. Mar 10 '12 at 20:52
BTW, I have this idea to drop sessions of users which send multiple Set-Cookie headers for the same cookie, but I don't use .NET and thus have no idea how to implement it. Maybe someone else can hack something together? –  Niklas B. Mar 10 '12 at 20:52
@NiklasB. That might solve 1/2 of the issue; Part 1: Do all browsers react the same way in all combinations (HTTPOnly, secure, etc)? Are values always appended, or are they overwritten? Part 2: What if the victim has not logged in yet and there is no duplicate for the server to see? –  makerofthings7 Mar 10 '12 at 21:11
I think part 1 is not so much an issue, it would be really buggy a browser if it would only only send the fake cookie. However, buggy browsers exist. One would have to do some research on how popular browsers handle that. Part 2 is completely correct, haven't thought of that. Makes me wonder whether the whole thing isn't actually a real design flaw in the RFC. –  Niklas B. Mar 10 '12 at 21:16
@makerofthings7 even if I read them all again and again, I have a little lost :). Because you have very interesting do you have any code sample of any of this implantation ? or something more practical that I can use or test ? –  Aristos Mar 13 '12 at 22:04
show 2 more comments

10 Answers

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.

Illustration of a secure session between a server and browser

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


4.3. Cookie Hardening

One way TLS-OBC can be used to strengthen cookie-based authentication is by "binding" cookies to an origin-bound certificate. The server, when issuing a cookie for an HTTP session, would associate the client's origin-bound certificate with the session (either by encoding information about the certificate unforgeably in the cookie, or by associating the certificate with the cookie's session through some other means). That way, if and when a cookie gets stolen from a client, it cannot be used over a TLS connection initiated by a different client - the cookie thief would also have to steal the private key associated with the client's origin-bound certificate, a task considerably harder especially when we assume the existence of a Trusted Platform Module 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: http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts

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

share|improve this answer
Please see meta.stackexchange.com/questions/125409/…. –  John Saunders Mar 12 '12 at 19:18
Wow, thanks for the very elaborate, illustrated and informative followup. –  Niklas B. Jun 10 '12 at 22:37
Very good in-depth information. However, as these technologies are drafts and not yet standardized, they don't help you to fix the issue with today's technology. –  Dyna Jun 11 '12 at 7:40
add comment

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.1
Host: www.example.org
Cookie: name=value; name2=value2
Cookie-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.
share|improve this answer
The real-world solution is just to get yourself your own domain for 10 bucks/yr and you are settled. This whole thread and question is of pure academic nature and not very relevant in the real world. If you have what you consider a "secure webapp" you would not run it anywhere within a subdomain, where you don't control the parent dns zone. –  Dyna Mar 12 '12 at 11:52
@Dyna - I wasn't originally going to respond to this, but since it has upvotes I'll mention that there are many Active Directory deployments that have the same domain as your application. That means every workstation has a name of computer.company.com (in most cases). That means every app off of *.company.com is vulnerable. There are even more scenarios but I don't want to list them all in a public forum. –  makerofthings7 Mar 13 '12 at 19:26
If the servers are bound via AD to server1.company.com first thing i notice is *.company.com is under your control, so no harm from that domain except other systems in it. But I admit, if another system in your company then gets hacked (like server2.company.com) the problem might arise. –  Dyna Mar 14 '12 at 7:11
@Dyna "The real-world solution is just to get yourself your own domain for 10 bucks/yr and you are settled." In the "real-world" some domains can only be registered as example.foo.bar (not example.bar), but the browser may not know that (as there is no official registry for registering policies) and treat example.foo.bar and evil.foo.bar as subdomains instead of full domains. –  curiousguy Jun 10 '12 at 23:51
add comment

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 integrity by choosing a new method of storing and transmitting session state. While this could be done using special browser plugins like Flash, we would rather choose a design with the fewest dependencies, so we will focus only on basic HTTP tools. The basic form of an HTTP request has very few places that are suitable for sending data with integrity. Data in the URL or entity body of HTTP requests has no integrity, because those parts of the HTTP request are writable across origins and thus spoofable by an attacker. Cookies are also weak in this regard, as they can be overwritten by the attacker in our threat model. However, through the use of a JavaScript API called XMLHttpRequest (XHR), we can send data in a custom header.

Background. XMLHttpRequest (XHR) allows HTTP requests containing custom headers to be made, and the responses read, but only to the origin of the executing JavaScript.(See Note5) As a result, requests made via XHR can be distinguished by a server as necessarily originating from the site itself.

Design. We will not use cookies at all, and instead pass a session identifying token in a custom HTTP header which is only written via XMLHttpRequest. The server should treat all requests lacking this custom header, or containing an invalid token, as belonging to a new, anonymous session. In order to persist this session identifying token across browser restarts and between different pages of the same application, the token can be stored in HTML5 localStorage by JavaScript upon successful authentication.

Security. Observe that in this model, the session identifying token will only be sent to the origin server, and will not be included in the URL or entity body. These properties provide conﬁdentiality and integrity, respectively. Unlike with cookies, the token cannot be overwritten by the attacker, since localStorage completely partitions data between origins in most browsers (See Note 6). A site using HTTPS can ensure that the token is only sent over HTTPS, thus ensuring the secrecy of the token even in the presence of an active network attacker. In addition, because this token is not sent automatically by the browser, it also serves to protect against CSRF attacks.

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

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

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

share|improve this answer
add comment

Source: Origin Cookies Proposal from Web 2.0 Security and Privacy Conference


6. Session Integrity in Future Browsers Neither of the previous solutions, nor others considered using existing browser technologies, provide sufﬁcient security while remaining deployable for existing sites. Therefore, we propose an extension to cookies called origin cookies. Origin cookies allow existing web applications to secure themselves against the described attacks, with very little complexity of implementation on the part of either the web application or the browser, with transparent backwards compatibility for browsers that do not yet implement origin cookies, including legacy browsers that may never support them, and imposing no burden on existing web sites that have not enabled origin cookies. This is not a trivial problem to solve, as evidenced by existing proposals that fail to meet one or more of the above desired properties. For example, sending the origin of every cookie on each request is one common idea. This is much more complicated than necessary, and imposes a much larger burden on web sites, including ones that don’t even know how to effectively use this information.

6.1. Origin Cookies The real problem with using cookies for session management is lack of integrity, speciﬁcally due to the ability of other origins to clear and overwrite cookies. While we cannot disable this functionality from cookies without breaking many existing sites, we can introduce new cookie-like functionality that does not allow such cross-site modiﬁcation.

Design. Origin cookies are cookies that are only sent and only modiﬁable by requests to and responses from an exact origin. They are set in HTTP responses in the same way as existing cookies (using the Set-Cookie header), but with a new attribute named ‘Origin’. In order to enable web applications to distinguish origin cookies from normal cookies, origin cookies will be sent in an HTTP request in a new header ‘OriginCookie’, while normal cookies will continue to be sent in the existing header ‘Cookie’.

HTTP/1.1 200 OK
Set-Cookie: foo=bar; Origin
Fig. 2. An HTTP response setting an origin cookie.
GET / HTTP/1.1
Host: www.example.com
Origin-Cookie: foo=bar

Fig. 3. An HTTP request to a URI for which an origin cookie has been set.

For example, if in response to a GET request for http://www.example.com/, a response as in Figure 2 is received, then an origin cookie would be set with the key ‘foo’ and the value ‘bar’ for the origin http://www.example.com, and would be sent on subsequent requests to that origin. A subsequent GET request for http://www.example.com/ would look like Figure 3. Requests made to any other origin, even https://www.example.com and http://example.com would be made exactly as if the origin cookie for http://www.example.com was never set. The Origin attribute extending the semantics of Set-Cookie itself is subtle and implies several semantic changes to other settable attributes of cookies. If the Origin attribute is set, the Domain attribute is no longer appropriate, and therefore should be ignored. Similarly, the Secure attribute is no longer appropriate, since it is implied by the scheme of the origin for the cookie: if the scheme is https, the the origin cookie effectively has the attribute – since it will only be sent over a secure channel – and if the scheme is anything else, the cookie does not have the attribute. Because the same-origin policy considers different paths to be part of the same origin, the Path attribute of cookies provides no security and should also be ignored. The semantics of other attributes, such as HttpOnly, Max-Age, Expires, etc. remain unchanged for origin cookies. Normal cookies are uniquely identiﬁed by their key, the value of the Domain attribute, and the value of the Path attribute: this means that setting a cookie with a key, Domain, and Path that is already set does not add a new cookie, but instead replaces that existing cookie. Origin cookies should occupy a separate namespace, and be uniquely identiﬁed by their key and the full origin that set it. This prevents sites from accidentally or maliciously deleting origin cookies, in addition to the other protections against reading and modifying, and makes server-side use of origin cookies signiﬁcantly easier.

Security. Because origin cookies are isolated between origins, the additional powers of the related-domain attacker and active network attacker in overwriting cookies are no longer effective, since they were speciﬁcally exploiting the lack of origin isolation with existing cookies, whether the ‘confusion’ was due to the scheme or domain of the origin. Absent these additional powers, the related-domain attacker and active network attacker are equivalent to the web attacker, who cannot break the security of existing session management based on the combination of cookies and secret tokens.

Implementation. Integrating origin cookies into existing browsers will not involve signiﬁcant modiﬁcations. As a proof of concept, we implemented origin cookies in Chrome. The patch totals only 573 lines

share|improve this answer
add comment

Source: W3C Mailing Lists

IETF TLS working group has a proposal to bind cookies to TLS client certificates, so as long as the private key corresponding to the cert is only on one machine, the cookie can only be used on one machine.

If you want to emulate the TLS client cert approach, you could use localStorage to store a private key, and use JS crypto 1 to replace document.cookie with a signed version. It's a little clunky, but it might be made to work. (Obviously, would be better with web crypto 2)

1 for example: http://www.ohdave.com/rsa/

2 http://www.w3.org/community/webcryptoapi/

share|improve this answer
add comment

Main Points

  1. Not give permission for run in the upload directories (an attacker can be from inside).
  2. Get all possible user information's that is connect to the server (cookie is only one).
  3. Monitor the server and alerts (found/see him, stop him, close the door).

Answer to


First of all you must not allow to run anything on your uploaded directories, because even your regular users can upload an aspx page and run it and browse your files. The first step for this is to add on your upload directories this web.config (but also set the permissions to not allow to run anything).

        <deny users="*" />

relative : I've been hacked. Evil aspx file uploaded called AspxSpy. They're still trying. Help me trap them‼

Stealing the cookies

Lets see how we can identify the user.

  1. Cookie
  2. Browser ID
  3. Ip including proxy and forward ips.
  4. Browser have javascript enable (or not).
  5. Direct ask for password.
  6. Other file stored on client.

Now, for every logged in session, we can connect the first four information's together, and if any of them change we can log him out and ask again to sign in.

Also is critical to connect some how (with a line on the database) the cookie with the logged in status of the user, so if the user log out, no matter if some steal his cookie, not to be able to see the pages - what I mean is the cookie that let him log in must not the only one that we rely on, but also our data to track the status of the user.

In this case even if some steal the cookie, if the user log out after some actions, the cookie is not useful any more.

So what we do is that we connect the cookie+ip+browser id+javascript information's per login, and if any of them change, we not trust him any more, until log in again.


One cookie is not enough. We need at least two cookies, one that work only on secure pages, and is required to be https secure and one that work on all pages. This two cookies must be connected together and this connection must also be hold on server.

So if one of this cookie not exist, or the connection is not match, then user again not have permission and need to log in again (with alert to us)

relative: Can some hacker steal the cookie from a user and login with that name on a web site?

An idea to connect cookies together. With this idea I connect the session cookie with the authentication cookie.

If all fails

There are some steps (or actions) that a hacker follow (do) when get to a site so be able to gain from this window opportunity and left a back door open.

  1. Create a new administrator account.
  2. Upload a file to run as browser and executable.

As I say we never allow to be able to upload a file that can be run, so this is easy. The other to create a new administrator account is the one that we need to add an extra password that is not saved to any cookie, or nether exist anyway on client.

So for rare actions like, New User from backoffice, change the privilege of the users, delete a user, etc, we need to request a second password every time that only the administrator knows.

So second password is the final messure.

One final idea

One idea that I have not made, is to store some how information's on the client other than the cookie, the can not be stolen like the cookies, or even if he can be stolen is hidden somewhere on all the data that is impossible to find it.

This infomation's can be an extra id of the user together with the cookie, browser data, IP.

I am thing some possible places but not have tested or try them yet in real life. So this is some placed.

  1. Custom extension, or plugin, unfortunately different for every browser that have the ability to save data and then we can use them to communicate with the server. This is required action from the user, to install this plugin - and for regular users this can make him afraid and go.
  2. Hidden code inside a good cached image, on the header of it, eg on etag. This also is easy to not work because we can not be sure that the image request to reload...
  3. Some other browser abilities, eg to read and use a client certificate, that can be used to exchange encrypted data with the server. This request action from the user to install this certificate, and from our part to create them different for every user. Good for bank accounts but not for simple users.

So this is my ideas... any critic, or a solution (for how to store small information's on client other than the cookie) is welcome.


To make it real secure we need to keep track of the user on the server, and on database. A table that connect the user, with the ip, with the browser id, and other status, like if now is log in or not, is a measure that we can use to take decisions.

If not be able to use a database, or not like to make it difficult, then the connection can be bu hashing some data together and check if this hash is the same.

For example we can set a cookie with the hash of (Ip+BrowserID) and check if this much or not.

Alerts - Log

All the above they try to be automate. How ever I suggest also to show to the user and to the administrator some information's to diagnose and prevent an attack. This information's can be.

To the user

  • Last 10 sign in information's (IP, DateTime, Success or not)
  • Send email on user about some actions (for high security sites), like log in, log out, critical actions.

To the administrator.

  • Log and show any fail of the connection on the four parametres Cookie+IP+BroserID+Javascript Enable). The more the fail in short time, the more attention required.
  • Check for fail login.
  • Check for page read from user with out cookie enable (or save) and javascript is disabled, because this is how scanner identified from my experience.
share|improve this answer
I think you got the "upload executable" part wrong. The point was that one user could trick another into using a session different from his own. So this scenario is a client-side attack, rather than an attack on the server. Also, "secure" cookies aren't any more secure than regular cookies when it comes to these cross-domain issues. –  Niklas B. Mar 10 '12 at 20:40
@NiklasB. Yes the secure cookies is not secure if you get them the way the question set. Thats why I say that is good to connect 4 information of the user session together. Also if a user pass from one secure page to one other that try to get the cookie he can see at least a warning for the ssl. Now I hope the client not get and run .exe files so easy. –  Aristos Mar 10 '12 at 21:20
@downvoter I kindly ask you to tell me what you not agree because maybe I have miss something here. –  Aristos Jun 10 '12 at 22:23
I didn't downvote, but apparently you wrote a very long answer that doesn't actually answer the original question. –  Niklas B. Jun 10 '12 at 22:35
@NiklasB. Its long because there are many thinks that some one must do for protection. Now read again the question, and have some parts, I have get them one by one and I start answering. Its a difficult issue to solve. three main points. 1) you do not give permission for run on the upload area. 2) You read all information's possible from user to identify him. 3) You monitor the server –  Aristos Jun 11 '12 at 8:21
show 2 more comments

From http://www.codeproject.com/Articles/16645/ASP-NET-machineKey-Generator

Whenever you make use of ViewState, Session, Forms authentication, or other encrypted and/or secured values, ASP.NET uses a set of keys to do the encryption and decryption. Normally, these keys are hidden and automatically generated by ASP.NET every time your application recycles

If the two websites are different web applications, by default they will have different keys so one will not be able to read encrypted tokens generated by the other. The exception to this is if they are using common values in a global web.config or machine.config.

From machineKey Element, decryptionKey: http://msdn.microsoft.com/en-us/library/w8h3skw9.aspx

AutoGenerate, IsolateApps Specifies that the key is automatically generated. This is the default value. The AutoGenerate modifier specifies that ASP.NET generates a random key and stores it in the Local Security Authority (LSA). The IsolateApps modifier specifies that ASP.NET generates a unique encrypted key for each application using the application ID of each application.

So unless the machineKey element is being used to set the decryptionKey at a global level, the method you described should not work. If it is set, you could override at application level using the web.config file.

share|improve this answer
add comment

So, you want to make sure that the cookies you are getting back from a client really came from your app and not something else in the same domain. Not a problem. Before you put whatever you're going to put in the cookie there, encrypt it using a key that is maintained and only known to your application.

When you receive a cookie, your application should then decrypt it using that same key (so, you'll want to use a symmetric algorithm like AES for this). If the results you get back are legitimate (you may want to put a known identifier at the front of the cookie contents at this point to make it very easy to see if the cookie decrypted correctly or not), then you know it came from your server as no one should be able to form a cookie that decrypts properly without knowledge of your encryption key. If the results are illegitimate (you don't see a proper structure/identifier), then you know the cookie didn't come from your server (or it was modified since it left your application) and you should reject it.

This does introduce some overhead into your application, as you need to encrypt anything you store in a cookie before you send it out, and decrypt any cookies that come back in from a client, but it should address this attack.

share|improve this answer
This won't work for a confused delegate situation. A user can go to the same web app, extract the key you describe (say an auth cookie with xx rights), then go to another host in the same domain, and inject that key there. The browser may send both cookies in an undefined order to the web app. ...Or it may overwrite the cookie depending on the scope. The result is that the victim will be running under different credentials. The consequences are app-specific. –  makerofthings7 Mar 9 '12 at 17:10
+1: We built an http module that processes each request coming in to automatically decrypt the cookies and when going back out to encrypt it. The starting point for our solution was: codeproject.com/Articles/21511/… –  Chris Lively Mar 9 '12 at 17:12
@ChrisLively The issue I have is that an encrypted cookie can be copied and sent to "someone else". Perhaps it would be good to limit risk and encrypt the client IP address inside the cookie as well. Though this can cause issues any time the client legitimately changes IP, and doesn't protect them if they are behind a NAT or proxy. –  makerofthings7 Mar 9 '12 at 17:20
Your question (specifically, the linked one) dealt with one server issuing a domain cookie that would then be sent to the original server, either resulting in two cookies being sent to the original server or the original server's cookie being overwritten. Encrypting the cookie's contents will solve this threat, assuming only the original server knows that key. Being concerned about a cookie being copied off the client and sent somewhere else, or a more general concern about domain cookies, while related and important to consider, is not the question that was asked and well off-topic for SO. –  jeffsix Mar 9 '12 at 17:42
@jeffsix, I don't understand how encrypting your cookies stops the kinds of attacks being discussed here. A malicious server at attacker.example.com can still set cookies that will be sent back to target.example.com, or delete target's cookies and overwrite them with new ones. Note that attacker can also connect to target himself to get validly-encrypted cookies to set on the victim's browser. This seems like it may be enough for login CSRF, for instance, if I'm following correctly. Or perhaps I misunderstood something? –  D.W. Mar 13 '12 at 18:10
show 4 more comments

You could set a unique machineKey in the web.config for your application. This way only authentication cookies emitted by that application can be decrypted. If the user visits a malicious site on the same domain, this other site might indeed add an cookie authentication cookie with the same name but different value, but it won't be able to encrypt and sign it with the same machine key used by your application and when the user navigates back an exception will be thrown.

share|improve this answer
This could be helpful if I own every host in the *.company.com domain, including workstations. Any domain joined workstation, in theory, could host a web server and perform this attack, limiting the effectiveness of this solution. –  makerofthings7 Mar 10 '12 at 13:52
@makerofthings7, no, because you will have unique machine key only for your application. –  Darin Dimitrov Mar 10 '12 at 15:05
I think you and @ChrisLively both are thinking of the same type of solution, but it won't fix my problem. Please see this chat to see how the conversation went. @ mention me if you want to further the discussion (let me know when) –  makerofthings7 Mar 10 '12 at 16:11
Yep - we are talking about two different things, I'm certain. The encrypted token you mention is just a blob with random numbers. Any client that possesses that blob "is" the authenticated user. Assume that the cookie key name is equal on victim site and attacker site. If I were to log in and get my own cookie on victim and save it using fiddler. Then suppose I trick an authenticated user to visit my site (say with an IMG request) then I can swap my known working, encrypted value for theirs. The victim app won't care and will allow spoofing –  makerofthings7 Mar 10 '12 at 20:03
Possession of the encrypted blob/cookie doesn't mean that will be the same client who will send it back. I just have to trust the fact that no other host in my CookieSender.com domain doesn't also save cookies with the same name or the same scope. –  makerofthings7 Mar 10 '12 at 20:07
show 6 more comments

The answer is simple: Always bind sessions to a specific client IP (this should be done in any modern web application anyway) and do not use cookies for any other purpose.

Explanation: you always send a single SESSIONID cookie back to the client, which holds no information - its just a very long random string. You store the SESSIONID along with the authenticated user IP within your webapps scope - like i.e. the database. Although the related cookie attack can be used to swap SESSIONID cookies around between different clients, no client can ever masquerade as another user or perform any actions, as the SESSIONID is only considered valid and the privileges are only granted, if its send from the associated IP address.

As long as you do not store actual data which is considered private into the cookie itself, but into the session state on the server side (which is selected solely by the SESSIONID cookie) the related cookie problem should be no problem for you.

share|improve this answer
Yep, this goes along what I was thinking... the first issue is that all clients behind a proxy or NAT will be vulnerable as they share the same external IP. –  makerofthings7 Mar 10 '12 at 20:17
The second issue is that every cookie is vulnerable, and the effect is application specific. In this example I'm talking about authentication cookies, which can be bound to a session.. and the session bound to an IP. But what about other cookies? Would that mean that every cookie should be encrypted and have the client IP in it? If so, then how should errors be handled if there is an IP mismatch? –  makerofthings7 Mar 10 '12 at 20:18
I don't think you can assume that a single session comes on a single IP. What we have observed plenty of times is that user's IP vary between requests, this is not usual but it just happens. Also, users coming from a private network will have the same IP at your server side. –  Wiktor Zychla Mar 10 '12 at 20:19
@Dyna, I don't understand how IP binding prevents the kind of attacks being discussed here. A malicious server at attacker.example.com can still set cookies that will be sent back to victim.example.com, or delete victim's cookies and overwrite them with new ones. IP binding doesn't stop this. –  D.W. Mar 13 '12 at 18:06
@D.W. the attacker can delete or replace any cookies by the victim. But if you restrict yourself usage to a single session id cookie, and store all other key/values you usually do into cookies on your server side, the attacker can do nothing. He could (a) delete the cookie which would only result in a need for the victim to re-authenticate or (b) replace the session id by another value which would eventually get refused by the server because its not bound for that ip –  Dyna Mar 14 '12 at 17:58
show 9 more comments

Your Answer


