HttpOnly non-session cookies are lost after several page visits
Reported by
tedermx@gmail.com,
Oct 23 2017
|
||
Issue description
Chrome Version : 61.0.3163.100
OS Version: OS X 10.11.6
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 5x: FAIL
IE 7/8/9:
What steps will reproduce the problem?
1. Make sure you have a usual amount of cookies saved in your browser and don't do any cleanups. Go to https://www.livejournal.com/ and authorize with "Remember me" option on. Observe that several auth cookies are created: "ljsession" , "ljmastersession" , "ljloggedin", and that they are non-session (having an expiration date) and HttpOnly.
2. Traverse several different pages of the site, e.g. article links like these:
https://lj-cinema.livejournal.com/13838.html
https://melfm.livejournal.com/73873.html
https://dimagrib.livejournal.com/3443873.html
https://nasedkin.livejournal.com/870002.html
https://shakko-kitsune.livejournal.com/1164989.html
https://radulova.livejournal.com/3726746.html
https://maxim-nm.livejournal.com/364945.html
https://e-kaspersky.livejournal.com/440152.html
https://abolenkin.livejournal.com/108253.html
https://beauty-spirit.livejournal.com/269091.html
https://yaponskiebudni1.livejournal.com/99584.html
https://deadokey.livejournal.com/344890.html
https://odin-moy-den.livejournal.com/2163433.html
https://selyanka1.livejournal.com/27312.html
https://kononenkome.livejournal.com/1756551.html
https://arkhip.livejournal.com/845564.html
Reproduction may require to visit from 3 to 30 links, and will happen faster if browser has accumulated cookies from other sites. Time-wise, the bug can be reproduced in several minutes.
What is the expected result?
Mentioned auth cookies persist up to expiration date.
What happens instead of that?
After several redirects, the cookies disappear (not necessarily all at the same time), and you are logged off.
Please provide any additional information below. Attach a screenshot if
possible.
* Bug reproduces much less often after cookie data cleanup.
* I've managed to reproduce bug not only for HttpOnly cookies, but also for simple non-HttpOnly cookies set from the console. They disappear after a few page visits on the site.
* Trying to find a minimal reproduction setups, I've discovered that "https://stats.g.doubleclick.net/dc.js" alone as a third-party script on the site triggers a bug with the same speed even if all other JS file requests are blocked. It doesn't mean that "dc.js" is the only script capable of triggering the bug -- you may block this one, enable all others, and get the bug again.
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
,
Oct 23 2017
This may be expected behavior. Cookies per top-level-domain are capped, so if a single domain sets a ton of cookies on a variety of its subdomains, it will eventually run into the per-domain cookie quota. We do have some heuristics to try and figure out which cookies to keep longer (Favoring secure cookies, and higher priority cookies), but it doesn't look like live journal uses either cookie priorities or secure cookies.
,
Oct 24 2017
Thanks a lot for diagnosis! Explains lots. So am I correct that you mean additional flags `Secure;Priority=High` on more important cookies?
,
Oct 24 2017
Correct, though if you set too many cookies, you'll still run into the issue. We keep 150 cookies per top-level domain. When purging cookies, we keep 30 low priority cookies, and 50 medium priority or lower cookies (i.e., we will delete higher priority cookies, to save that many lower priority cookies, if the lower priority cookies were set more recently). We'll actually wait until 180 cookies are set before destroying cookies, but then we'll delete 30 at once. If there are no secure cookies, we'll keep 150 medium cookies, etc. You don't need both Secure and Priority=High - one or the other should do the trick. Secure cookies can't be read, deleted, or overwritten by HTTP (non-HTTPS) requests or pages, so they may or may not work for your use case.
,
Oct 24 2017
The actual algorithm is: Figure out how many cookies we need to delete (num cookies for that domain - 150). * Try to delete that many low priority non-secure cookies, oldest first, keeping at least 30 cookies of those types. * If not enough cookies were deleted, try to delete that many low priority secure or non-secure cookies, oldest first, keeping at least 30 cookies of those types. * If not enough cookies were deleted, try to delete that many medium priority non-secure or lower priority (secure or non-secure) cookies, keeping at least 50 of those types. etc. There are also rules for expiring cookies globally, which are based on total number of cookies, but those are deleted in order of age, and we don't delete cookies set less than 30 days ago when doing this, regardless of total number of set cookies, so that's unlikely to be the issue here.
,
Oct 24 2017
Thanks for such a detailed view! I think there will be demand for that info. Team is already in the process of testing the flags on selected cookies. `Secure` gives a few issues, yes, so currently it's just a `Priority=High`. Even while alone, this flag seems to work and helps selected cookies to persist.
,
Oct 24 2017
I'm going to go ahead and close this bug, but feel free to ask questions here, or via email, if you have them (Or it turns out there is a bug here, I can reopen the bug).
,
Oct 25 2017
Agreed, no bug here! Let's close it. |
||
►
Sign in to add a comment |
||
Comment 1 by meh...@chromium.org
, Oct 23 2017