Security: Session cookie is never destroyed and always send to server under certain circumstances even when Chrome is restarted
Reported by
szesi...@gmail.com,
Jun 13 2018
|
||||||
Issue descriptionVULNERABILITY DETAILS Under normal cases, when server side HTTP response to web browser with 'Set-Cookie' header omitting expires/max-age value, then the web browser will create a session cookie that is destroyed upon the exit of web browser process. However, when switching to the commonly used Chrome settings 'Continue where you left off' under the 'On startup' section, created session cookie is never removed from Chrome even when closing all the browser tabs and after terminating the Chrome process. Under this mode to preserve the earlier tabs, when Chrome is reopened again and opening a tab to visit websites with earlier created session cookies are still submitting these session cookies to the server. Please provide a brief explanation of the security issue. Session cookie is not destroyed even after restarted when Chrome browser settings is set to preserve earlier tabs. VERSION Chrome Version: [Version 67.0.3396.87 (Official Build) (64-bit)] + [stable] Operating System: [macOS High Sierra, 10.13.5] REPRODUCTION CASE I've created a simple webapp in AWS Lambda that creates a session cookie called 'TEST_SESSION_COOKIE' when web browser does not send session cookie with that key to it. This webapp also produces all the HTTP request headers sent by the web browser as output of the response. https://t3xobl3f6i.execute-api.eu-west-1.amazonaws.com/test Steps to reproduce: 1. Open Chrome browser, go to Settings/On startup and change to 'Continue where you left off'. 2. Load https://t3xobl3f6i.execute-api.eu-west-1.amazonaws.com/test 3. First you will observe the headers do not contain Cookie header and TEST_SESSION_COOKIE key. 4. Open 'More Tools/Developer Tools' to start Chrome debugger and switch to Network tab. 5. Reload the page and you will see a HTTP request for /test endpoint happened. 6. When you click on it, you can see the Headers under Response Headers section shows the server side returns 'set-cookie: TEST_SESSION_COOKIE=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx; Secure; HttpOnly; Path=/'' for web browser to create a session cookie as there is not expires/max-age parameter specified. 7. Close all the tabs and Chrome browser entirely. 8. Open Chrome again and go to https://t3xobl3f6i.execute-api.eu-west-1.amazonaws.com/test 9. You will see the output for 'Cookie: TEST_SESSION_COOKIE=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' with the same UUID value is still there even if you reload. 10. The webapp only generates a new random UUID if the web browser didn't not submit the session cookie to the server side. --- Source code for the session cookie webapp test (Python) --- import uuid from flask import * app = Flask(__name__) @app.route('/', methods=['GET']) def main(): headers = str(request.headers).strip() web_display = '<pre>%s</pre>' % headers if 'TEST_SESSION_COOKIE' in request.cookies: return web_display, 200 else: response = make_response(web_display, 200) response.set_cookie( key='TEST_SESSION_COOKIE', value=str(uuid.uuid4()), max_age=None, secure=True, httponly=True ) return response --- end of file ---
,
Jun 13 2018
hmm this seems bizarre that it would only happen on restart. is this related to issue 817335, or issue 403312 ?
,
Jun 13 2018
I'm no longer working on Chromium, so I'm not a good person to cc on this type of problem. Having said that, I thought we sometimes persisted session cookies to deal with unexpected program kills on e.g. Android, though I wouldn't expect that on Mac OS X. CCing in a few more people, and removing myself.
,
Jun 13 2018
I can't see how this would have anything to do with issue 817335. Session cookies are saved to disk, but QuotaPolicyCookieStore should delete them before teardown. So either it's not doing that, the browser is being shut down / crashing before those tasks complete, or there's some issue on the database side of things (That code's failing, or losing access to the file, or something). If you check about:crashes, is there anything there that corresponds to when you quit chrome?
,
Jun 14 2018
the result from about:crashes shows 0 crashes as it was normal shutdown of Chrome process by closing it.
,
Jun 14 2018
The session cookie is persisted every time when Chrome settings is changed to 'Continue where you left off' under the 'On startup' section. This is reproducible every time.
,
Jun 14 2018
I'm sorry, I missed the "continue where you left off" bit in your original report. Thanks for bearing with me! That's expected behavior. This seems like not a security issue (Though I'll defer to the security team on that, rather than removing the label myself), but rather a privacy issue.
,
Jun 14 2018
I'm trying to understand why is that an expected behavior? So basically enabling that 'Continue where you left off' breaks the standard behavior of session cookie and there is not way for user to kill a session automatically when closing browser? Session cookies are supposed to be removed whenever a session is closed but this isn't the case. This becomes a security issue when the computer is a shared one.
,
Jun 14 2018
If it's a shared one, you presumably don't want someone else continuing where you left off. If someone has local access to your computer, they have full access to your cookie store, anyways, and can install extensions to do whatever they want to your web activity. Chrome's threat model doesn't cover someone who has physical access to your machine. Resuming a browsing session keeps your session cookies, because it's (attempting) to resume your browsing session. I don't own the session logic, but this is definitely working as it was intended to.
,
Jun 14 2018
As mmenke@ notes, this is the behavior we intentionally built. "Continue where you left off" aims to do just that, maintaining the state associated with your session across restarts. It might be reasonable to reevaluate that decision from both a privacy and product standpoint: CCing interested folks. In the short term, however, the definition of a "session" varies wildly from browser to browser, and the length varies wildly from user to user. If a given application would like to ensure that user sessions are short-lived, then explicit expiration dates when setting cookies are the only way to do so in an interoperable way. I'd recommend that approach.
,
Jun 14 2018
Okay, sounds like this is WAI then, so closing. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by szesi...@gmail.com
, Jun 13 2018