Why is ASP.NET forms authentication setting cookie

Question

I have an ASP.NET (MVC) website that is serving static content (images) as well as dynamic content from the same domain. The site uses forms auth, and has a login controller. There have been some very strange / irregular issues with people finding themselves logged in or out at random intervals, and we've tracked it down to an issue with a reverse proxy caching an image file that has a set-cookie response header that sets the auth cookie. Once this is cached, everyone then gets the same auth cookie, which leads to some very weird outcomes.

My question is - how on earth would an image get a set-cookie header in the first place? What is the ASP.NET forms authentication module doing to cause this - surely it sets the cookie on the main HTML content response. I get that the auth cookie is then sent with all subsequent requests to the domain, but I cannot figure out how the cookie is set in the first place.

(BTW this issue may also be the culprit in at least two existing large ecommerce sites that are suffering from similar problems, with no solution, so it would be a good one to solve).

The response is shown below (taken from fiddler).

HTTP/1.1 200 OK
Cache-Control: public, max-age=86400,max-age=86400
Content-Type: image/png
Last-Modified: Thu, 04 Nov 2010 16:00:52 GMT
Accept-Ranges: bytes
ETag: "0528474397ccb1:0"
Server: Microsoft-IIS/7.5
Set-Cookie: my-auth-cookie=6BC25F1EF71989466A48C0120E7739E; path=/; HttpOnly
Date: Wed, 17 Nov 2010 17:15:08 GMT
Content-Length: 15790

Update: additional info - we are using IIS 7.5 on Win2008 R2, 64bit, and the app is running under an app pool that is using the integrated pipeline / .net 4.

Update 2: I am not looking for a solution to the problem, we have one already. I am looking for an answer to the question, which is why it happened in the first place? Please don't answer telling me about subdomains or how cookies work!

Update 3: adding in the request:

GET https://www.example.com/sprite.png HTTP/1.1
Host: www.example.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.44 Safari/534.7
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: my-auth-cookie=6BC25F1EF71989466A48C0120E7739E;

Answer 1

browser by default sends the cookies with each request made on the same domain.

the simple solution is to move your images to some other domain, like youtube guys have a domain http://s.ytimg.com/yt/img/watch/ to save all the images.

Answer 2

Because you can use Forms Authentication to secure static content.

Answer 3

Seems like a bug in IIS to me. I'm going to write some straw-man code to see if I fully understand what's going and and post the results. I'll also test it on IIS 7 and IIS 7.5 to see if it's different.

It really doesn't seem that one request should get ANY cookies associated with a previous request (we DO NOT have any caching proxies on our site and this is happening to us on our internal network, so my conclusing is that IIS is doing it somewhere).

--Owen

Answer 4

I suspect this isn't actually a .NET problem per-se, and the key to your issues is actually the Reverse Proxy.

When serving static content from a forms-auth'ed path, the cookies associated with your connection will get sent along with it. So, if you're signed in as user X, session 1 and get image foo.png, your reverse proxy is seeing the PNG file come across with headers indicating it can be cached.

The next time that file is being requested, the reverse proxy is serving the file directly, along with the cookie it had associated with that file when it last got it.

As an experiment, I suggest setting the reverse-proxy to turn off it's caching functionality and see if the problem persists.

If you do need the reverse proxy to be doing caching of content - then I'd suggest then looking to see if the proxy can be told to ignore cookies for cached files, or moving files to another cookieless/auth-less domain.

Answer 5

Answering this myself to close out the question and prevent further updates.

The root cause of the behaviour that I was seeing was due to the integrated pipeline setting cookies on static files (css, images, js) - see the comment thread for further details.

It was solved when we moved static content to a different host in the production / staging environment.