Bugzilla

(In reply to Rob Wu [:robwu] from comment #5)
> (In reply to Agi Sferro | :agi | ni? for questions | ⏰ PST | he/him from comment #4)
> > Looks like we're getting this URI from `DocumentChannel` directly here: https://searchfox.org/mozilla-central/rev/31ddf859c57e812878a5f817e4097efb06de4d97/netwerk/ipc/DocumentLoadListener.cpp#579
> > 
> > So to recap the problem here is that a load involving a `moz-extension://...` URI triggers a `onLoadRequest` call with the translated `jar:file:///` URI which confuses the front-end.
> 
> I don't think that this recap is complete. As my STR in comment 1 shows, it's not merely a problem of the app trying to open the internal URL,
> but also associating the loaded content with the wrong pre-redirect URL. That is very concerning, bordering on the edge of a sec issue.

Oh I missed this part! This _is_ a security issue:

>     The content area shows that the redirection target is actually loaded in the content area, but with the wrong document URL. The content area contains:
>
> This URL: https://example.com/redir
> This base URL: https://example.com/redir
> Subresource loaded: no

Am I reading this correctly that the web page thinks it's loaded from `https://example.com/redir` but it's actually loading from an extension? Could you do this, say, with `google.com` or `bankingwebsite.com` and pretend you're somebody you're not? (and worse, read the cookies?)

Restricting for now.

(In reply to Rob Wu [:robwu] from comment #5)
> (In reply to Agi Sferro | :agi | ni? for questions | ⏰ PST | he/him from comment #4)
> > Looks like we're getting this URI from `DocumentChannel` directly here: https://searchfox.org/mozilla-central/rev/31ddf859c57e812878a5f817e4097efb06de4d97/netwerk/ipc/DocumentLoadListener.cpp#579
> > 
> > So to recap the problem here is that a load involving a `moz-extension://...` URI triggers a `onLoadRequest` call with the translated `jar:file:///` URI which confuses the front-end.
> 
> I don't think that this recap is complete. As my STR in comment 1 shows, it's not merely a problem of the app trying to open the internal URL,
> but also associating the loaded content with the wrong pre-redirect URL. That is very concerning, bordering on the edge of a sec issue.

Oh I missed this part! This _is_ a security issue:

>     The content area shows that the redirection target is actually loaded in the content area, but with the wrong document URL. The content area contains:
>
> This URL: https://example.com/redir
> This base URL: https://example.com/redir
> Subresource loaded: no

Am I reading this correctly that the web page thinks it's loaded from `https://example.com/redir` but it's actually loading from an `moz-extension` page? Could you do this, say, with `google.com` or `bankingwebsite.com` and pretend you're somebody you're not? (and worse, read the cookies?)

Restricting for now.