7

An interface (website/application) that requires authentication should have a proper HTTP caching mechanism. When it doesn't, it allows an attacker to browse back after logout or read the cache in another way.

In order to do so, the server should enforce HTTP headers that require the browser to revalidate (must-revalidate) the source on every request (not to cache it). Practically meaning that when a user is logged out, it should not be possible to browse back in the browser (unauthorized) and see the content that is meant to be restricted to the authenticated user.

What is the proper terminology and base CVSS score for a caching mechanism that allows the browser to cache authenticated content?

I suppose an acceptable CVSS score might be:

Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
  • I would say your AV should be Network as it can be exploited via a browser (one or more network hops away), the way i understand it, it is not a 'local' attack vector. This would change your score to a 5.3 but i agree with the all other values you assigned. Once you navigate back, does the portal work as if you were logged in or if you try and perform an action does it ask for authentication again? – iainpb Jun 21 '17 at 13:53
  • @iain Thanks for the feedback. Can you give an example how this would be done over network? Using an iframe is only possible when they did not set "x-frame-options" (correctly). Using a combination with an existing XSS in that portal? The portal does not perform actions anymore as far as I tested. So, does prompts for authentication. It's only about gaining insight in shown information on previously opened pages. – Bob Ortiz Jun 21 '17 at 13:59
  • My assumption has always been that if someone is attacking the application with a browser over the internet or intranet that that constitutes a network attack, and that local means you needed to be on the same machine as the vulnerability. This assumption could be wrong - I find the CVSS factors a little vague. If the portal forces reauth for any action there's definitely no integrity loss and i'd say there's only a confidentiality issue if when you hit back it shows any sensitive info or a user name. – iainpb Jun 21 '17 at 15:41
  • @iain Do you know the proper terminology for this behavior? – Bob Ortiz Jun 22 '17 at 09:30
  • Not specifically no, i'd say it falls into the OWASP Broken Authentication and Session Management category which does cover Browser Caching so i'd probably identify this as browser cache weakness https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-AUTHN-006) – iainpb Jun 22 '17 at 09:37
  • See also [CWE-525: Information Exposure Through Browser Caching](https://cwe.mitre.org/data/definitions/525.html). – Sjoerd Jun 08 '18 at 09:54
  • I would expect it to be local only. I don't understand how local area network would let you exploit this. The example is hitting the back button to view past pages (presumably even after a log out). There isn't anyway to exploit that *except* on the local machine – Conor Mancone Aug 02 '20 at 22:30

1 Answers1

1

I believe the proper scenario for this would fall into security misconfiguration according to OWASP.And even falls into the top 10.

Top 10-2017 A6-Security Misconfiguration

I currently agree with the score. But it needs to validate other circumstances also. Such as the information that it stores. If the cache stores credit card information or any financial/personal pages then that can even increase some points 4.2 perhaps.

I would consider this a smaller score if it wasn't on the OWASP top 10. What I mean is because it is happening a lot it should have a bigger attention. But it can be something critical if an attacker can access multiple browsers. So then again by it being easy to do makes it more critical.