Last Comment Bug 570658 - Username-in-URL obfuscation warning isn't shown for iframe loads
: Username-in-URL obfuscation warning isn't shown for iframe loads
Status: NEW
[sg:low] dom-triaged
: sec-low
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: x86 Windows Vista
: -- enhancement with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-07 21:56 PDT by Aditya K Sood
Modified: 2016-02-05 09:07 PST (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Aditya K Sood 2010-06-07 21:56:32 PDT
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.
Comment 1 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-06-08 00:23:58 PDT
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 Jesse Ruderman 2010-06-08 07:35:01 PDT
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.
Comment 3 Aditya K Sood 2010-06-08 08:39:43 PDT
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.
Comment 4 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-06-08 09:26:51 PDT
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 Jesse Ruderman 2010-06-08 09:34:48 PDT
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.)
Comment 6 Daniel Veditz [:dveditz] 2010-06-09 10:59:40 PDT
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
Comment 7 Aditya K Sood 2010-06-11 20:15:50 PDT
I think its going to be good solution to implement this feature.
Comment 8 timeless 2010-08-15 12:27:51 PDT
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".
Comment 10 Michal Zalewski 2010-08-17 12:54:09 PDT
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 Jesse Ruderman 2010-08-17 13:20:03 PDT
Comment 2 and comment 5 describe some cases where this /might/ matter.
Comment 12 Michal Zalewski 2010-08-17 13:24:18 PDT
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 Alexandra (retired) 2010-08-18 02:19:05 PDT
In that case any URI shortening service should be considered a spoofing launchpad. Pretty old news.
Comment 14 Johnathan Nightingale [:johnath] 2010-08-18 07:52:41 PDT
(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/
Comment 15 Aditya K Sood 2010-08-18 19:47:36 PDT
The POC - http://www.secniche.org/videos/mozilla_bug_570658.html
Comment 16 Johnathan Nightingale [:johnath] 2010-08-19 08:30:23 PDT
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 kei100 2010-08-21 02:47:05 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.