NEW 218980
Treat loopback addresses (127.0.0.0/8, ::1/128, localhost, .localhost) as potentially trustworthy URL
https://bugs.webkit.org/show_bug.cgi?id=218980
Summary Treat loopback addresses (127.0.0.0/8, ::1/128, localhost, .localhost) as pot...
Frédéric Wang (:fredw)
Reported 2020-11-16 05:53:59 PST
Preliminary work is done in bug 218623 and bug 218627, but it is including the loopback URLs directly in the definition of "a priori authenticated URL" (https://w3c.github.io/webappsec-mixed-content/#a-priori-authenticated-url) rather than in the one of "potentially trustworthy url" (https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-url). This bug is about moving these things around, which might lead to some behavior changes.
Attachments
Radar WebKit Bug Importer
Comment 1 2020-11-16 18:15:56 PST
Sam Sneddon [:gsnedders]
Comment 2 2021-02-19 11:44:42 PST
https://github.com/WebKit/WebKit/blob/51b6659009f49c33837e1ed10cddbd454315fb44/Source/WebCore/page/SecurityOrigin.cpp#L157 makes it look like we already treat localhost and loopback addresses as potentially trustworthy origins?
Frédéric Wang (:fredw)
Comment 3 2021-02-19 11:48:09 PST
(In reply to Sam Sneddon [:gsnedders] from comment #2) > https://github.com/WebKit/WebKit/blob/ > 51b6659009f49c33837e1ed10cddbd454315fb44/Source/WebCore/page/SecurityOrigin. > cpp#L157 makes it look like we already treat localhost and loopback > addresses as potentially trustworthy origins? IIRC, these functions are confusing since they are actually not used by MixedContentChecker::isMixedContent. See the patches I attached on bug 218623 and bug 218627 for where we would actually want to plug the new thing.
Sam Sneddon [:gsnedders]
Comment 4 2021-02-19 11:55:46 PST
Right, so there's the mixed content case, but also the… not-mixed content (lone content?) case for WebIDL's [SecureContext], for example. Not totally clear what this specific bug is meant to be for, given the title. Using the SecurityOrigin checks more widely?
Frédéric Wang (:fredw)
Comment 5 2021-02-19 12:17:21 PST
(In reply to Sam Sneddon [:gsnedders] from comment #4) > Right, so there's the mixed content case, but also the… not-mixed content > (lone content?) case for WebIDL's [SecureContext], for example. > > Not totally clear what this specific bug is meant to be for, given the > title. Using the SecurityOrigin checks more widely? Yes, so I think I opened this and other related issues in order to address bug 171934 reported by users, which was specifically about mixed content. I agree that in general it would be good to rely more on this "potentially trustworthy URL" concept when checking whether we are in a secure context. I think this is a bit a mess in browsers & spec currently, the call sites in Chromium are https://github.com/whatwg/html/issues/6369#issuecomment-779212659
Sam Sneddon [:gsnedders]
Comment 6 2021-10-01 09:15:42 PDT
*** Bug 231035 has been marked as a duplicate of this bug. ***
Frédéric Wang (:fredw)
Comment 7 2021-12-10 02:14:02 PST
Removing myself from assignee since I'm not working on this anymore.
Julian
Comment 8 2024-01-25 14:36:35 PST
Got tripped up today by WebKit not accepting cookies with `Secure=true` from localhost, while gecko and chromium accepted them no problem. Would really like to see this fixed, thanks!
Note You need to log in before you can comment on or make changes to this bug.