Open Bug 570658 Opened 14 years ago Updated 2 years ago

Username-in-URL obfuscation warning isn't shown for iframe loads

Categories

(Core :: DOM: Navigation, enhancement)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows Vista
Type:
enhancement

Tracking

()

People

(Reporter: adi.zerok, Unassigned)

Details

(Keywords: sec-low, Whiteboard: [sg:low] dom-triaged) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)

The Firefox implements a check when a URL obfuscation is done in the address bar. It has been noticed that if Iframe are used with the Obfuscated URL, the alert notification is bypassed.

Address bar will raise an error when "http://www.google.com@yahoo.com" this link is applied.

Iframes will bypass the alert notification when "http://www.google.com@yahoo.com" is used in the frameset.

This impacts the user security because obfuscated links in the iframes might trick the user to visit false links.


Reproducible: Always

Steps to Reproduce:
<html>

<body>
<iframe src="http://www.google.com@yahoo.com" width="600" height="600" />
</body>
</html>
Actual Results:  
No alert notification.
The frame redirects the src to yahoo not google

Expected Results:  
Alert notification should be generated. 
If not user should go to Google not Yahoo.

MFSA advisory should be worked upon for this issue.
We trigger an error when loaded via the location bar because the user might be fooled by the text in the location bar not matching the site they're seeing. When loaded in an iframe, there's no confusion, because we don't show the URL anywhere - so there's no benefit to having the iframe load "http://www.google.com@yahoo.com" vs. just loading yahoo.com directly.
Maybe you trust the parent frame and child frame to not use window.status tricks to hide link destinations, but the child frame can contain links from untrusted sources (e.g. email messages or forum posts).

I could imagine this happening if you visit a forum thread using the diggbar.  It's a little far-fetched, but we should probably be consistent in applying the warning.
Summary: Firefox (3.6.3 )URL Obfuscation through Iframes -Alert Notification Bypass Vulnerability. → Username-in-URL obfuscation warning isn't shown for iframe loads
Whiteboard: [sg:low]
It is an issue if we look from the perspective stealth behavior. A user can be tricked to visit the destination which he should not suppose to go. Direct linking in Iframe is a normal behavior but considering different scenarios the consistency pattern should be there.
How will the user be tricked? How are the "google.com@yahoo.com loaded in an iframe" from "yahoo.com loaded in an iframe" cases user-distinguishable?

Whether or not a username was specified doesn't even persist beyond the initial page load, even when loaded from the URL bar, so I really don't understand how this is an issue.
Here's the scenario I'm thinking of:

Diggbar or GoogleImageSearch frames a forum thread page.  An asshat posts a link to http://www.google.com@yahoo.com in the thread.  A user clicks the link, thinking it's a Google link.

(An evil site could do worse things with window.status, but in these cases neither the framer nor the framed page are evil, and perhaps the user knows this.)
When the SuspiciousAuth checks were added it was a conscious decision to skip warnings about frames. It'd be very easy to change nsHttpChannel::ConfirmAuth() to prompt for sub-frame loads if we decide to do so.

http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#3891
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think its going to be good solution to implement this feature.
i'm not sure it's a good thing. i suppose we're basically talking about cases where a trusted site has been subverted. from my perspective, once a trusted site is subverted, it doesn't really matter how it was subverted, the game is over.

Someone is more or less telling sites "Don't be XSS'd", it seems reasonable to tell sites "Don't let people provide phishy urls".
Component: Security → Networking
Product: Firefox → Core
QA Contact: firefox → networking
Version: unspecified → Trunk
I am not sure why this is even being seriously discussed?

The only point of the check on top-level location is to warn users about the use of a potentially confusing and relatively obscure URL syntax in the address bar (although hiding the login:password@ part is probably about as good and less disruptive). This does not apply to subresources, period. No?
Comment 2 and comment 5 describe some cases where this /might/ matter.
Well, yeah, but then the browser is not displaying the actual destination URL, and it's not its responsibility to keep it readable (in fact, browser-originating warnings would be rather confusing with a different URL shown in the address bar).

The responsibility for sanitizing and correctly reporting the origin of the content lies squarely with the framing page. I am pretty sure Image Search gets it OK.
In that case any URI shortening service should be considered a spoofing launchpad. Pretty old news.
(In reply to comment #10)
> I am not sure why this is even being seriously discussed?

http://blog.mozilla.com/security/2010/08/17/obfuscated-urls-within-iframes/
Aditya - thanks for taking the time to document your concerns more completely. That video highlights, for me, the risk inherent in sites that expose CGI to frame arbitrary content and is a compelling argument for sites to lock down their use of such autoframing scripts.

But I don't really see the relevance to this bug or to Firefox behaviour. Sure, you could provide an obfuscated url in the src field, but it seems to be that by far the greater user confusion in that case will come from seeing the domain of the site offering the auto-framer, not from the details of the URL you provide to the CGI script. Are you worried that our phishing/malware support wouldn't understand what was going on? It is not fooled by obfuscation attempts, e.g.

data:text/html,<iframe src="http://foo.com@www.mozilla.com/firefox/its-a-trap.html">
Another POC - http://www.youtube.com/watch?v=myTlsIG5T8U
(Video Lang:Ja)
Poor *Engrish* can be displayed by the annotation. 

This is not ArcHTTP(WebBased RAID Console) bug.
And *NOT* this Web-based console only.(like router,WiFi AP,NAS,WebCam,etc...)
Danger of default password.

But,Firefox confirm to me,please.
Component: Networking → Document Navigation
Whiteboard: [sg:low] → [sg:low] dom-triaged
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.