Closed Bug 1484026 Opened 7 years ago Closed 9 months ago

Add IPC Checks to Get/SetCookie methods

Categories

(Core :: Networking: Cookies, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
133 Branch
Fission Milestone Future
Tracking Status
firefox133 --- fixed

People

(Reporter: tjr, Assigned: baku)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

While reviewing the IPC for document.cookie, I used it as a guinea pig for where IPC layer checks could be inserted. I believe they need to be in CookieServiceParent::RecvPrepareCookieList which receives a Host and an OriginAttributes object from the content process, and looks up the cookies based on those values. Inside of CookieServiceChild::GetCookieStringFromCookieHashTable there is at least one check that should become superfluous, and could be removed or turned into an Assert: if (cookie->IsSecure() && !isSecure),
So, one way to structure this is as PCookieService currently does -- GetCookieString takes a host string, and looks things up for it. To make this fission-ipc-secure we would insert a check into RecvGetCookieString that verifies that the host is allowed for that pid. However, an alternate way we could structure it is to add the host to the PCookieServiceParent constructor, and simply remove the host argument from GetCookieString. The child gets a PCookieServiceParent actor that only knows how to look things up for one host.
(In reply to Alex Gaynor [:Alex_Gaynor] from comment #1) > So, one way to structure this is as PCookieService currently does -- > GetCookieString takes a host string, and looks things up for it. To make > this fission-ipc-secure we would insert a check into RecvGetCookieString > that verifies that the host is allowed for that pid. For one thing, I think we're about to remove the sync GetCookieString anyway (bug 1483986). Its use is preffed off anyway. > However, an alternate way we could structure it is to add the host to the > PCookieServiceParent constructor, and simply remove the host argument from > GetCookieString. The child gets a PCookieServiceParent actor that only knows > how to look things up for one host. That's a really interesting approach. I think that could work. But to implement it we must be in a world where we only have one origin in each process.
Priority: -- → P3
Whiteboard: [necko-triaged]
We could also provide one actor per origin-in-the-process to the child. The overhead for that might be higher than is acceptable though, I don't know off-hand how heavyweight child actors are (or how much refactoring would be required to make that work).
It's not how heavy they are, I assume not very. It's the way the nsICookieService works - it's a singleton; changing the API to allow for multiple instances of it would prove challenging.
See Also: → 1483986
Depends on: fission-ipc-map
Additionally, the async SetCookieString method needs to have checks on it's host/OriginAttributes also.

This bug is not a Fission MVP blocker.

Fission Milestone: --- → Future
Severity: normal → S3

I fixed this issue as part of the CookieStore implementation. In case we want to accelerate, we can land the fix immediately without waiting for the entire CookieStore review process. Valentin, what do you think? The fix is here: https://phabricator.services.mozilla.com/D217734

Flags: needinfo?(valentin.gosu)

I don't think this is super urgent. The cookieStore impl seems to have some momentum, so we can probably land it with bug 1475599.

Depends on: 1475599
Flags: needinfo?(valentin.gosu)

while working on CookieStore API, I implemented this extra IPC checks for Get/Set cookie methods. Currently we use IPC_FAIL only on nightly:
https://searchfox.org/mozilla-central/rev/9fa446ad77af13847a7da250135fc58b1a1bd5b9/netwerk/cookie/CookieServiceParent.cpp#311-315

I suggest removing the #ifdef bit.

Assignee: nobody → amarchesini
Status: NEW → ASSIGNED
Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/26015048a84c Enforce Cookie IPC checks in RecvSetCookies, r=valentin,cookie-reviewers
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 133 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: