1291540 - Warning about superfluous auth isn't shown for iframe

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect, P3)

Description

[Loneyer@DianRongSecurity]

Attachment: 1.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

Firefox 48.0 for Macos location pollution.


Actual results:

Test environment:Mac os 10.11.5
Test software:Firefox 48.0
poc:<iframe src='http://[e-mail]'></iframe>
url:inurl.pw/1.html

The test has been jump to the "inurl.pw".
If the jump is a phishing site?

Comment 1

[Tooru Fujisawa [:arai]]

what do you mean with "jump" ?
there is no jump.

Comment 2

[Loneyer@DianRongSecurity]

Because the browser parses certain location protocol error cause contamination。When a user accesses the page。
url：inurl.pw/1.html
poc：<iframe src='http://[e-mail]'></iframe>
Real requests and parsing is performed "http://[e-mail]" Results Jump to inurl.pw。

%2f => /
http://[e-mail]  => http://www.firefox.com.cn/@inurl.pw
But,When a user Browse this address “http://www.firefox.com.cn/@inurl.pw”。
Will jump to the next page www.firefox.com

Comment 3

[Tooru Fujisawa [:arai]]

"www.firefox.com.cn%2f" part is username.

Comment 4

[Loneyer@DianRongSecurity]

(In reply to Tooru Fujisawa [:arai] from comment #3)
> "www.firefox.com.cn%2f" part is username.

yes.

Comment 5

[Tooru Fujisawa [:arai]]

(In reply to Loneyer from comment #4)
> (In reply to Tooru Fujisawa [:arai] from comment #3)
> > "www.firefox.com.cn%2f" part is username.
> 
> yes.

Which behavior do you think is the bug?

If you write "http://[e-mail]", it means username is "www.firefox.com.cn%2f", hostname is "inurl.pw", and path is empty.
If you write "http://www.firefox.com.cn/@inurl.pw", it means username is empty, hostname is hostname is "www.firefox.com.cn", and path is "/@inurl.pw"
"%2f" and "/" have totally different meaning there.

What's the parse error do you mean?

Comment 6

[Loneyer@DianRongSecurity]

(In reply to Tooru Fujisawa [:arai] from comment #5)
> (In reply to Loneyer from comment #4)
> > (In reply to Tooru Fujisawa [:arai] from comment #3)
> > > "www.firefox.com.cn%2f" part is username.
> > 
> > yes.
> 
> Which behavior do you think is the bug?
> 
> If you write "http://[e-mail]", it means username is
> "www.firefox.com.cn%2f", hostname is "inurl.pw", and path is empty.
> If you write "http://www.firefox.com.cn/@inurl.pw", it means username is
> empty, hostname is hostname is "www.firefox.com.cn", and path is "/@inurl.pw"
> "%2f" and "/" have totally different meaning there.
> 
> What's the parse error do you mean?

Browser this web site. http://inurl.pw/f1r3f0x/

Comment 7

[Tooru Fujisawa [:arai]]

Okay, so the issue is that the alert about possible phishing website isn't shown when it's an iframe, but is shown when loading same URI as new tab, right?
If not, please describe the issue more precisely.

Comment 8

[Loneyer@DianRongSecurity]

(In reply to Tooru Fujisawa [:arai] from comment #7)
> Okay, so the issue is that the alert about possible phishing website isn't
> shown when it's an iframe, but is shown when loading same URI as new tab,
> right?
> If not, please describe the issue more precisely.

yes.

Comment 9

[Tooru Fujisawa [:arai]]

I see.  confirmed the behavior difference.

Comment 10

[Dragana Damjanovic [:dragana]]

Valentin is this our bug or dom? (you have dealt with URIs :)

Comment 11

[Valentin Gosu [:valentin] (he/him)]

This definitely needs _some_ input from the DOM team.

At the moment, nsHttpChannelAuthProvider::ConfirmAuth() does something like:
> if (!(loadFlags & nsIChannel::LOAD_INITIAL_DOCUMENT_URI))
>     return true;
This is why we don't trigger this for iframes.

Olli, any opinion on this?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

http://52.25.115.98/viewvc/main/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp?view=annotate#l3242

So, see bug 232567 for reasoning for that code.

Comment 13

[Valentin Gosu [:valentin] (he/him)]

We're already doing a weird thing here. If I refresh the page, I get a warning message, but if I do a hard refresh, I don't :)

From what I can tell of other UAs, Chrome allows the iframe and Edge seems to block it without asking.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

I don't still quite understand what the issue is there. iframes can load whatever, and iframe urls aren't exposed in location bar.

Comment 15

[Loneyer@DianRongSecurity]

Tested Software：Firefox 50.0 
OS：MacOS 10.12.1

This problem I in the latest version of Firefox test, still exist。
If you access this url（http://[e-mail]/）, alone will pop up warning.
But, if you put this string of characters embedded iframe or other framework, will bypass the tip. Direct access to the site.

Comment 16

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 17

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 18

[Daniel Veditz [:dveditz]]

The "superfluous auth" warnings were intended to combat dot-com era plain-text phishing links. People were unfamiliar with URL structure, but a text link was the URL and people assumed they knew where they were going. These links primarily came from email or chat programs, and to some extent the blog comments and web forums of the day that would auto-linkify "URL-looking" text.

HTML links largely make that protection obsolete. There's no longer a connection between what https://www.apple.com looks like and where it takes you. And for aficionados of link hovering who think they are safe, event handlers can send you to any arbitrary location after you click.

We don't need these annoying warnings for frame navigations because phishers have not ever needed this style of URL to fool people into clicking. And after users do navigate the frame they don't know whether they have ended up on the "legit" version of whatever the content looks like. All they can do is decide if they trust the top-level site whose address appears in the URL bar.