Issue metadata
Sign in to add a comment
|
Security: Clear browsing data 'Cachcel images and files' also deletes HSTS storage
Reported by
goo...@gavin.sh,
Jun 19 2018
|
||||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS Clearing 'Cached images and files' via 'Chrome -> Clear Browsing Data' also clears all stored HSTS settings. (Apologies, been unable to confirm/deny if this is expected behaviour - certainly wasn't expected on our side for the 'Cached images and files' option) VERSION Chrome Version: Version 67.0.3396.87 (Official Build) (64-bit) [stable] Operating System: macOS 10.13.5 REPRODUCTION CASE 1. Ensure any pre-existing HSTS headers for test domain (www.troyhunt.com) are cleared using chrome://net-internals#hsts 2. Open Network tab of Developer Tools 3. Visit http://www.troyhunt.com The following steps take place: - Request sent to http://www.troyhunt.com - Redirect response on to https://www.troyhunt.com - HSTS header sent in response from https://www.troyhunt.com 4. Query troyhunt.com in chrome://net-internals#hsts, confirms HSTS header has been stored. 5. Visit http://www.troyhunt.com again This time, the following steps take place: - Browser follows HSTS policy, and HTTP request is instead sent to https://www.troyhunt.com 6. Select 'Chrome -> Clear Browsing Data Time range: All time Tick *only* 'Cached images and files' Press 'CLEAR DATA'. 7. For the second time, query troyhunt.com in chrome://net-internals#hsts, HSTS header will now be missing. 8. Visit http://www.troyhunt.com The following and original steps take place due to the missing HSTS information: - Request sent to http://www.troyhunt.com - Redirect response to https://www.troyhunt.com - HSTS header sent in response from https://www.troyhunt.com Many thanks for your time.
,
Jun 20 2018
This doesn't look like what we consider to be a security vulnerability, so rerouting.
,
Jun 20 2018
,
Jun 20 2018
Please note, I believe this continues to have some security implications if confirmed. Issue allows for unexpected MITM downgrade attacks on sites from which you expect Chrome to protect via previously set HSTS headers.
,
Jun 20 2018
As per comment #0 we have tested this issue on reported chrome version 67.0.3396.87 using macOS 10.13.5.Attaching screen-cast for reference. Steps: -------- 1. Launched chrome 2. cleared using ""chrome://net-internals#hsts"" and Opened Dev tools and navigated to Network tab 3. Navigated to ""http://www.troyhunt.com"" and run query troyhunt.com in chrome://net-internals#hsts>> here we have seen ""Not Found"" 4. Navigated again http://www.troyhunt.com @Reporter: As we are unable to reproduce the issue from our end. Could you please review the attached screen-cast and confirm if anything being missed here and if possible provide screen-cast for better triaging this issue. Thanks!
,
Jun 26 2018
There may be privacy/security tension here --- keeping an HSTS entry for a site reveals that you have visited the site... though that may suggest that may be it's better off under the "History" checkbox? Just going to kick this upstairs.
,
Jun 26 2018
This behaviour is intentional. Chrome tries to find a balance between privacy (e.g. HSTS supercookies) and security. You can find some of the past discussions and reasoning behind this in issue 104935 and issue 784958 . |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by goo...@gavin.sh
, Jun 19 2018