Issue metadata
Sign in to add a comment
|
User can abuse cache clearing to restore pages that were previously logged in order to gain access to another persons account
Reported by
marcusgr...@gmail.com,
Jan 11 2018
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Steps to reproduce the problem: I noticed this problem specifically when accessing a gmail account but also noticed that the google account was logged in automatically to all other google based application such as Youtube. 1. Have user login to their email 2. Have user logout of their email 3. Have a new user login to their email caching the new page 4. In Chrome settings clear cache to the time frame in which the previous user was logged into their email 5. Have user browse to email page 6. You will now be successfully logged into the account that was logged out of with full access to anything that they had opened that doesn't require 2-factor authentication What is the expected behavior? When clearing the cache back, the user shouldn't be automatically logged back into the email as if the instance was live. I believe as the cache loads there needs to be some verification factor using the date of the cache versus the current date to prevent this issue in the future. Possibly, the browser / page sees that the cache was loaded at another date it should request the user to log back in. What went wrong? There isn't enough security when it comes to caching Google logins. When the user deletes their cache and essentially rolls back the browser they expose HUGE security errors. This security error would allow a user to for example gain access to your bank account knowing that you had logged into it prior if said bank account doesn't have 2-factor authentication. 2 factor authetnication isn't a solution for this issue because that would assume every third party website that is cached would be using some type of 2 factory authentication. Did this work before? Yes 63.0.3239.132 Chrome version: 63.0.3239.132 Channel: stable OS Version: 10 Flash Version: Shockwave Flash 27.0 r0 I am hopefully this will be solved and I think that if this was to be exposed there could be potential for damage of funds and maybe much worse. Exposing of data that is sensitive to users is taken very seriously by google and I know this working with some of the public APIs. Good luck!
,
Jan 11 2018
Fundamentally, it's NEVER safe to use an untrusted computer to browse anything of value, as there are *many* different ways to steal data, from basic keyloggers to data recovery tools, etc. This is explained here: https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Why-arent-physically_local-attacks-in-Chromes-threat-model Use of a Guest Profile or an Incognito instance can help limit these threats, but only using a different User Account (at the operating system level) provides true security isolation (and only if the potential attacker is not a system administrator). Having said that, I am interested in your repro case-- can you be specific about an *exact* set of repro steps that reproduce this behavior, including the URLs? In a well-designed web application, the "Have user logout of their email" step will result in an immediate revocation of the user's login-token cookie, such that even if you were to send the cookie-token to the server again, the server will reject it and force reauthentication.
,
Jan 18 2018
,
Jan 18 2018
Closing for lack of actionable data. Feel free to reopen if you can provide exact repro steps as requested in #2. Thanks.
,
Apr 27 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by marcusgr...@gmail.com
, Jan 11 2018