Image caching, HTTPHandler and FormsAuthentication

Question

The Setup:

I'm working on a website that uses Formsauthentication using cookies to store the login ticket. The site also has an HTTPHandler that manages images stored in the database. The handler caches the images to be public and expire in 20 minutes. We have noticed that since the images have the same lifecycle as a page the images also include the Formsauthentication cookie. The configuration is IIS 6, Win2k server, Content Expiration is not enabled.

The Problem:

What we are experiencing is Person A logs in and hits a couple of pages. Then Person B hits the default page not logging in and get's the cookie for Person A and is able to see all of Person's A data. We have reproduced the problem once by turning on Content Expiration in IIS but have not reproduced consistently so we are not sure if Content Expiration helped us reproduce it. We are assuming since the images are being cached as public and they also contain the cookie with the FormsAuthentication, it's somehow possible for Person B to unintentionally get Person A's cookie. We know this isn't a attack on the website.

Has anyone experienced anything similar to this behavior? If so, can you provide any advice on how to reproduce this issue consistently?

Answer 1

Why does Person B get Person A's cookie? I'm assuming you mean Person B's session cookie is being associated with A's login ID. That's the nub of the problem.

It sounds to me that A's login ID is being stored in a place that could cross requests -- such as a temp file or in the DB -- without associating it with a session cookie. (Related issue: Page output is being cached, but not properly associated with or retrieved via the session cookie.) When session information is stored or cached, it must be associated with the cookie. Think in terms of session data belonging to a brower, not a login.

I would install the Firefox extension LiveHTTP and examine the request/response headers. My bet is, you'll see A and B have different cookies, but on the server they're both associated with the same login ID.

Answer 2

We are assuming the cookie is in the Response Header and is writing out the same cookie that exist on Person A's machine to Person B. Its important to note that this issue occured with Person A in IE 7 and Person B in FireFox. Also when Person A logged out it logged out Person B was logged out as well since the Formsauthentication ticket was no longer valid on the server. So yes they did have differnet cookies but the same formsauthentication ticket within each of thier cookies. One was however generated without logging in.

We also found this article but haven't been able to confirm if this is the cause. http://support.microsoft.com/default.aspx?scid=kb;EN-US;917072

I'll see what LiveHTTP tells me and will report back. Thanks.

Answer 3

Sure, if those images (and CSS and static JS files, etc...) aren't being served as HTTPS, they'll be subject to caching by ISPs or other proxies (well, caches actually), along with their cookies.

There's a caching directive something like this:

Cache-control: no-cache="set-cookie,set-cookie2"

...which is supposed to instruct caches not to cache the "set-cookie" response headers, but I'm not sure how widely supported this is (despite it being standard).

Avoid set-cookie response headers when serving images if you can (might not be easy if you're not in complete control of session management). If a user must be authenticated to see certain images, then those images shouldn't be publicly cached anyway.

Answer 4

Sorry I forgot to mention that all traffic was going through port 443 as SSL. We are planning on removing the set cookie for images. However, we are little confused how this could happen when all traffic is processed through SSL.

Answer 5

All traffic was SSL... reviewing the IIS logs everything was going through port 443. The only caching that was being set was on the images to public as mentioned earlier. Our assumption is this is in result output caching causing the issue.

Answer 6

Are you sure you don't have something like output caching enabled on the page?

Answer 7

It may help to install Fiddler to investigate your http requests as specified above. Also, confirm the cookies are the same. Does your handler, or forms authentication system use a static object reference? You may have a race condition in your code. and aren't properly locking your resources.