5

I'm considering the relative benefits/disadvantages of making a login page cacheable. Note that here I'm referring to the page containing the form into which the user enters their username and password.

Certainly it doesn't add any protection against SSL stripping (the HTTP page is treated as a seperate entity from the HTTPS age for caching purposes).

It would seem to add some value in protecting the form from modification by rogue certificates and potentially against future issues in SSL - although it can only enhance the integrity of the form for entering the data - which must then be sent over a compromised connection. Does this nulify all the benefits of loading the page from the local cache?

I did find this report which asserts that caching the login page is a vulnerability, on the grounds that "It is not recommended to enable the web browser to save any login information, since this information might be compromised when a vulnerability exists" - however the login page is surely the one form we really don't want to pre-populate before sending to the browser? OTOH there would be issues in using a challenge/response based mechanism where the challenge is issued within the login page - but then it simply won't work rather than compromising the security.

It does not open a new attack vector via the browser cache - this already exists when the page is served as non-cacheable (although it does potentially make an attack by this root a bit simpler if the page is already in the cache).

Is there a significant benefit/disadvantage I have overlooked here?

Improve this question
1
  • Only issue I see is if one is injecting a random unique anti CSRF token/nonce onto the page. In that case, part of the login information is the token embedded in the form html.
    – ewanm89
    Commented Jan 28, 2014 at 16:57

3 Answers 3

Reset to default
3

According to OWASP Application Security any page that can have sensitive information should not be cached if it can be accessed by public shared computers like libraries.

https://www.owasp.org/index.php/OWASP_Application_Security_FAQ

Any page after the user is logged on is much more sensitive and candidate for no-cache than the login page it self (since login page is public).

I think that in the "Cacheable Login Page Found" report they mixed up two concepts. One concept is the caching of sensitive information as included in the page itself. The other is the caching of the login and password information, as part of browser configuration. That I know of, one directive does not affect the other (that is, considering the page as non-cacheable will not affect the ability for the user to store the password on the browser profile).

To ask the browser not to store login information you can use the autocomplete='off' form attribute.

https://stackoverflow.com/questions/32369/disable-browser-save-password-functionality

Improve this answer
2

The login page is not login information; the latter should be cached only with great caution. But the page itself is no secret; everybody can obtain it. Therefore, there is no problem in applying to that page the same caching mechanism as for all other pages.

As for extra protection, don't count on it. If the attacker can break through SSL in some way, then he can feed the user a fake page, because that's how HTTP caching mostly works: the client asks for a page but states that it already has a copy from date T; the server can then respond "you can reuse the old copy", or send a new one.

Improve this answer
2
  • That's not my understanding of howHTTP caching works: the client only refers back to the server if the expiry time on an item of content has expired (at which point it will usually make a conditional request - if-none-match/if-modified-since) at which point the server may make a 304 not modified response. If the cache time has not expired, the browser won't attempt to contact the server for GET operation.
    – symcbean
    Commented Jan 28, 2014 at 13:40
  • There are several modes of caching. Moreover, an attacker who can intercept communications can force things, if only by sending some hostile Javascript which downloads dozens of megabytes of data (not displayed) in order to fill the cache and force eviction of previously cached pages.
    – Thomas Pornin
    Commented Jan 28, 2014 at 13:56
0

Consider a scenario where i think caching of the login page itself can be an issue.

taking example of an application where the user is presented with the login form and is requested to sign-in using his email and password. If the email or password is off even by 1 character, then login fails. Some applications then might send the back both the email and password as part of the response back to the browser for correction and resubmition. Since the login page itself is cache-able the email and password might get cached as well.

Note: I have not tested this yet so please feel to share your though on this.

Improve this answer
2
  • 1
    One would surely POST a login form and the response to a POST is never cached. But it is a scenario which needs to be handled
    – symcbean
    Commented Jan 13, 2015 at 20:58
  • @symcbean I am not so sure about this , that response to a POST is never cached by the browser. I was checking one web app. On resetting the password for your account the new password was part of the response.(visible in source not in browser, phew!) When i looked at the chrome browser cache i found the server response containing the new password in plaintext. I am not really confident as it was some time ago but it think that it was a POST as well.
    – Sanchit Sharma
    Commented Jan 14, 2015 at 6:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .