Reputation: 330
In some situations when my application responds with 404 Not Found code it also returns Set-Cookie directive with session identifier, but there is no Cache-Controle or Pragma directive. Does this mean that session identifier can be stored in browser cache and does this influence the security of the application? I am not sure if all responses with Set-Cookie should contain caching directives.
Upvotes: 2
Views: 2610
Reputation: 15599
Whether a cookie is permanently stored in the browser or not is controlled by the Expires and Max-Age properties. Cache-Control and Pragma headers only affect page contents. So I think you're good on 404 pages even without explicit cache headers (* but see the edit below).
Session cookies should always be set without an explicit expiry date, in which case they won't normally be stored on disk and will be removed when the user quits the browser.
(Note that there are cases beyond your control when such data from memory will still be persisted to disk, like for example when a user decides to hibernate, or the computer runs out of memory and starts to swap.)
Edit (see comments):
In case of normal pages that set cookies, you usually have headers to prevent caching of sensitive info like Cache-control: no-cache,no-store,must-revalidate
. This I think inherently includes not caching cookie responses either, so you don't need to explicitly set it on normal pages.
So the question is then, what cookie is set on a 404 page? If an unauthenticated user downloads the 404 page and gets a session cookie, that cookie is useless for an attacker, as the application should not be vulnerable to session fixation (the cookie value should change upon logon anyway). If it is an authenticated user, why would the application set the session cookie again on a 404 page? If it does though, you should send headers to prevent caching, that's a good catch by Skipfish. (In fact, you can do this for unauthenticated users too, but I would rate that a very low risk.)
Upvotes: 1