Closed
Bug 1440462
Opened 6 years ago
Closed 6 years ago
e10s: stop sending httponly cookies to child processes
Categories
(Core :: Networking: Cookies, enhancement, P2)
Core
Networking: Cookies
Tracking
()
RESOLVED
FIXED
mozilla64
Tracking | Status | |
---|---|---|
firefox64 | --- | fixed |
People
(Reporter: jduell.mcbugs, Assigned: u408661)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
Looks like we removed *access* to httponly cookies in the child in bug 1339129, but we're still storing them on the child. We should simply stop sending them to the child.
Reporter | ||
Updated•6 years ago
|
Whiteboard: [necko-triaged]
Comment 1•6 years ago
|
||
Unfortunately that would regress bug 1421324.
Hrm... I don't have access to that bug, which indicates to me it's a sec bug. I'm guessing we don't want to regress one of those. Jason?
Flags: needinfo?(jduell.mcbugs)
Reporter | ||
Comment 3•6 years ago
|
||
Nick--I cc'd you. Looks like we'll need to handle the case where an httponly cookie overwrites a non-httponly cookie, i.e. instead of simply not sending httponly cookies to the child, we should send them, just so we can check to delete any matching non-httponly cookies, then drop them on the floor (at least that's my read of it).
Flags: needinfo?(jduell.mcbugs)
I'm not sure it'll be that simple - what happens (heck, what is *supposed* to happen) when, after we do the steps Jason outlined, some script on the child sets a (non-httponly) cookie of the same name as the httponly cookie? I have to assume that is supposed to fail... but is it supposed to, say, throw an exception, or just silently not set the cookie? jdm - do you know the cookie spec well enough to answer those hypotheticals?
Flags: needinfo?(josh)
Nevermind, I've figured out the answer to comment 4.
Flags: needinfo?(josh)
Reporter | ||
Comment 6•6 years ago
|
||
Nick--you're right, comment 3 isn't enough. We can't just drop the httponly cookie info on the child, we have to keep it around so we can stop JS from overwriting existing httponly cookies. But we don't need to store the /value/ of the cookie, just the name and attributes (path, etc). That should be enough for our purposes here.
Previously, if script tried to set a cookie that matched a cookie we had received via Set-Cookie that was labeled httponly, script would think that cookie was properly set (even though it wasn't). This ensures that script knows just enough about httponly cookies to prevent this inconsistent view while avoiding leakages of the potentially-sensitive cookie values.
Reporter | ||
Comment 8•6 years ago
|
||
Nick--did you mean to ask for review of this patch?
Flags: needinfo?(hurley)
Yes. It's marked as review requested in phabricator. I've heard they're going to no longer sync those flags, so maybe that's why it doesn't show up here?
Flags: needinfo?(hurley)
Assignee | ||
Comment 10•6 years ago
|
||
jdm - see comment 7 and comment 9 (and then phabricator). Thanks!
Flags: needinfo?(josh)
Comment 11•6 years ago
|
||
Comment on attachment 9008514 [details]
Send httponly cookie names to content processes.
Josh Matthews [:jdm] has approved the revision.
Attachment #9008514 -
Flags: review+
Updated•6 years ago
|
Flags: needinfo?(josh)
Comment 12•6 years ago
|
||
Pushed by hurley@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4b87a1cf5afe Send httponly cookie names to content processes. r=jdm
Comment 13•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4b87a1cf5afe
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in
before you can comment on or make changes to this bug.
Description
•