1032564 - redirects to data: URL allows forgery that can't be reported

Status: REOPENED

(Toolkit :: Safe Browsing, defect, P5)

Description

[Rob Mueller]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

A recent phishing attack I came across did this:

1. Link in email to site http://evilsite.com
2. http://evilsite.com returned html that was:

<script>window.location="data:text/html;base64,...base64 encoded version of phishing login page...</script>

So in the address bar, there was a data: URL. When this happened, the "Report Web Forgery" option was disabled.

This means the attack was rather hard to report and stop.



Expected results:

"Report Web Forgery" should still have been available, and should have shown the URL for the page (e.g. http://evilsite.com) that changed the window.location to a data: URL.

Comment 1

[Dave Garrett]

A test link: http://tinyurl.com/p38rlvv

Comment 2

[Dave Garrett]

A test link for same concept, but using meta refresh instead of a script: http://tinyurl.com/p39u7fp

Comment 3

[Matthew Elvey]

I ponder whether the right course of action is to

A)change mozilla so that it can report these 
and/or
B)pressure URL shortening services to ban data: URLs.

Variants of the above URLs that are handy for seeing the data:
http://preview.tinyurl.com/p39u7fp
http://preview.tinyurl.com/p38rlvv

Is there a compelling use case for data: support from URL shortening services that makes a ban impractical?  Can't think of one.  If not, B seems like a far more sensible solution than A, which is a high-maintenance whackamole solution.

If there is a compelling use case, then there's option

C)pressure URL shortening services to perform phasing tests on decoded data: URLs.

Comment 4

[Dave Garrett]

(In reply to Matthew Elvey from comment #3)
> I ponder whether the right course of action is to
> 
> A)change mozilla so that it can report these 
> and/or
> B)pressure URL shortening services to ban data: URLs.

This bug doesn't really have anything to do with URL shortening. That just happens to be the method by which I implemented my testcase in comment 1. The reporter likely got a redirect from an actual page to a data URI.

Comment 5

[Matthew Elvey]

Right, in the sense that this bug is about Mozilla; it's filed at bugzilla.mozilla.org...

But in the sense that there's an overarching issue - that base64 encoded data: URLs are making it easier for phishing to succeed, URL shorteners are relevant.  When you posted about that (http://blog.fastmail.fm/2014/07/01/new-phishing-trick-data-urls-to-avoid-forgery-reporting/) the phisher was using an URL shortener.

Here's a comment from TinyURL about how this should be handled (cleared to post)

We handle data URLs like all other URLs in our handling of abuse. A web browser should do the same, in that they should allow the reporting of data URLs and therefore be able to handle all use cases in which data URLs are abused, which is not limited to URL shorteners.

Kevin "Gilby" Gilbertson
TinyURL, Founder
http://tinyurl.com

Comment 6

[Dave Garrett]

(In reply to Matthew Elvey from comment #5)
> But in the sense that there's an overarching issue - that base64 encoded
> data: URLs are making it easier for phishing to succeed

This doesn't rely on base64 either. Percent encoded would have the same issue.

The problem isn't redirecting to data URIs, it's the fact that they have no domains to report on and check for. Conceivably, you could report the URL as-is and block that, but only a minor change would be needed to the script to get around that. Being able to report a (hash of a) data URI and the URL of the page redirected from through the existing system would be where to start, I think. A user confirmation to redirect to a data URI would probably be the next step.

URL shorteners should put upper limits on how large of a data URI they'll accept and should probably prompt before redirecting to HTML, sure, but that's a side-issue, really. The reported incident didn't rely on URL shorteners; the data URI was redirected to from a hosted webpage. The user got there via an initial short URL, but again, this is all doable without that.

Comment 7

[mimosh_pisholack]

we have issue with data:text/html,<script>location='http://ravis.hamnavaz.com/default.aspx'</script> too, some of out rival still our data from an unauthorized source, then redirect them to our websites, we decide to block this kind of traffic, so we check for referral address, and now they use this... data:text/html,<script>location='http://ravis.hamnavaz.com/default.aspx'</script>

it generates error on chrome, but it's OK with FF

Comment 8

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.