WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2020-11-16 18:15:56 PST
<
rdar://problem/71468048
>
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.
Top of Page
Format For Printing
XML
Clone This Bug