Open
Bug 1291540
Opened 8 years ago
Updated 2 months ago
Warning about superfluous auth isn't shown for iframe
Categories
(Core :: Networking: HTTP, defect, P3)
Tracking
()
NEW
People
(Reporter: st0n310n3, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
56.37 KB,
image/png
|
Details |
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://www.firefox.com.cn%2f@inurl.pw'></iframe> url:inurl.pw/1.html The test has been jump to the "inurl.pw". If the jump is a phishing site?
Reporter | ||
Comment 2•8 years ago
|
||
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://www.firefox.com.cn%2f@inurl.pw'></iframe> Real requests and parsing is performed "http://www.firefox.com.cn%2f@inurl.pw" Results Jump to inurl.pw。 %2f => / http://www.firefox.com.cn%2f@inurl.pw => 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•8 years ago
|
||
"www.firefox.com.cn%2f" part is username.
Reporter | ||
Comment 4•8 years ago
|
||
(In reply to Tooru Fujisawa [:arai] from comment #3) > "www.firefox.com.cn%2f" part is username. yes.
Comment 5•8 years ago
|
||
(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://www.firefox.com.cn%2f@inurl.pw", 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?
Reporter | ||
Comment 6•8 years ago
|
||
(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://www.firefox.com.cn%2f@inurl.pw", 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•8 years ago
|
||
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.
Reporter | ||
Comment 8•8 years ago
|
||
(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•8 years ago
|
||
I see. confirmed the behavior difference.
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: HTTP
Ever confirmed: true
Flags: needinfo?(st0n310n3)
Product: Firefox → Core
See Also: → 232567
Summary: Firefox 48.0 for Macos location pollution. → Warning about superfluous auth isn't shown for iframe
Comment 10•8 years ago
|
||
Valentin is this our bug or dom? (you have dealt with URIs :)
Flags: needinfo?(valentin.gosu)
Whiteboard: [necko-next]
Comment 11•8 years ago
|
||
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?
Flags: needinfo?(valentin.gosu) → needinfo?(bugs)
Comment 12•8 years ago
|
||
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.
Flags: needinfo?(bugs)
Comment 13•8 years ago
|
||
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•8 years ago
|
||
I don't still quite understand what the issue is there. iframes can load whatever, and iframe urls aren't exposed in location bar.
Reporter | ||
Comment 15•8 years ago
|
||
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://www.mozilla.org%2f@inurl.pw/), 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•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P2
Comment 17•6 years ago
|
||
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
Priority: P2 → P3
Updated•2 years ago
|
Severity: normal → S3
Updated•2 months ago
|
Blocks: necko-auth
Whiteboard: [necko-next] → [necko-triaged]
You need to log in
before you can comment on or make changes to this bug.
Description
•