Bug 218980
| Summary: | Treat loopback addresses (127.0.0.0/8, ::1/128, localhost, .localhost) as potentially trustworthy URL | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Frédéric Wang Nélar <fred.wang> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | achristensen, beidson, gsnedders, jfernandez, julian.fortune, kevin.flanagan, lidel, me, rik, smoley, webkit-bug-importer, youennf |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Other | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=254991 https://bugs.webkit.org/show_bug.cgi?id=232088 https://bugs.webkit.org/show_bug.cgi?id=281149 |
||
| Bug Depends on: | 218623, 218627 | ||
| Bug Blocks: | |||
Frédéric Wang Nélar
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
<rdar://problem/71468048>
Sam Sneddon [:gsnedders]
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 Nélar
(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]
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 Nélar
(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]
*** Bug 231035 has been marked as a duplicate of this bug. ***
Frédéric Wang Nélar
Removing myself from assignee since I'm not working on this anymore.
Julian
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!