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

NEW
Unassigned

Status

()

Core
Document Navigation
--
enhancement
7 years ago
2 years ago

People

(Reporter: Aditya K Sood, Unassigned)

Tracking

({sec-low})

Trunk
x86
Windows Vista
sec-low
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low] dom-triaged)

(Reporter)

Description

7 years ago
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.

Comment 2

7 years ago
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]
(Reporter)

Comment 3

7 years ago
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.

Comment 5

7 years ago
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
(Reporter)

Comment 7

7 years ago
I think its going to be good solution to implement this feature.

Comment 8

7 years ago
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

Comment 9

7 years ago
http://blog.armorize.com/2010/08/iframes-and-url-stringency-mozilla.html

http://tech.slashdot.org/story/10/08/17/138251/New-Firefox-iFrame-Bug-Bypasses-URL-Protections
Group: core-security

Comment 10

7 years ago
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 11

7 years ago
Comment 2 and comment 5 describe some cases where this /might/ matter.

Comment 12

7 years ago
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.

Comment 13

7 years ago
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/
(Reporter)

Comment 15

7 years ago
The POC - http://www.secniche.org/videos/mozilla_bug_570658.html
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">

Comment 17

7 years ago
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.
Keywords: sec-low
Component: Networking → Document Navigation
Whiteboard: [sg:low] → [sg:low] dom-triaged
You need to log in before you can comment on or make changes to this bug.