Bug 218980 - Treat loopback addresses (127.0.0.0/8, ::1/128, localhost, .localhost) as potentially trustworthy URL
Summary: Treat loopback addresses (127.0.0.0/8, ::1/128, localhost, .localhost) as pot...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
: 231035 (view as bug list)
Depends on: 218623 218627
Blocks:
  Show dependency treegraph
 
Reported: 2020-11-16 05:53 PST by Frédéric Wang (:fredw)
Modified: 2024-01-25 14:36 PST (History)
11 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frédéric Wang (:fredw) 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.
Comment 1 Radar WebKit Bug Importer 2020-11-16 18:15:56 PST
<rdar://problem/71468048>
Comment 2 Sam Sneddon [:gsnedders] 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?
Comment 3 Frédéric Wang (:fredw) 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.
Comment 4 Sam Sneddon [:gsnedders] 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?
Comment 5 Frédéric Wang (:fredw) 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
Comment 6 Sam Sneddon [:gsnedders] 2021-10-01 09:15:42 PDT
*** Bug 231035 has been marked as a duplicate of this bug. ***
Comment 7 Frédéric Wang (:fredw) 2021-12-10 02:14:02 PST
Removing myself from assignee since I'm not working on this anymore.
Comment 8 Julian 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!