Firefox, Opera Allow Phishing By Data URI Claims New Paper

hypnosec writes "A student at the University of Oslo, Norway has claimed that Phishing attacks can be carried out through the use of URI and users of Firefox and Opera are vulnerable to such attacks. Malicious web pages can be stored into data URIs (Uniform Resource Identifiers) whereby an entire webpage's code can be stuffed into a string, which if clicked on will instruct the browser to unpack the payload and present it to the user in form of a page. This is where the whole thing gets a bit dangerous. In his paper, Phishing by data URI [PDF], Henning Klevjer has claimed that through his method he was able to successfully load the pages on Firefox and Opera. The method however failed on Google Chrome and Internet Explorer."

Re:Chrome and IE

[macraig]

What are some benevolent use cases of these data URIs that justify supporting them? I'm not baiting you, just ignorant and curious.

Re:Can anyone explain to me why this is worse than

[Sqr(twg)]

It is worse because you can embed the entire spoof in link-spam, and thus have no need for a domain that could be blacklisted, shut down by authorities, or traced back to you.

Re:Wonder if this works on /.

[game kid]

A view-source shows Slashdot transmits the link as data:texthtmlbase64[rest of data], instead of, say, data:text/html;base64;[rest of data], and that change probably breaks the link if the browser didn't already. I'm quite disturbed that /. allowed the [rest of data] anyway (and gave you the legendary Long Comment Modifier for it!), though.

Indeed, nothing (visible) happens on link click here (probably due to that change) in the latest Nightly or IE9, but make sure your blogs disallow data URIs (or gives them a mighty security check) in public comment sections and such.

Re:In other words...

[furbearntrout]

In other words, IE and Chrome do not implement the data URI [ietf.org] to the specification. Lucky them, they can pose now as "more secure".

I actually read TFS(TFRFC?). IIRC, the standard doesn't specify that an application honor redirects. It would depend on your interpretation of

"the same security considerations as any implementation of the given media type."

The passage seems to imply a "default deny" approach.

Re:Chrome and IE

[macraig]

My worry, if I understand this correctly, is that this could be used as a means to thwart every ad-blocker and page tweaker and HTTP proxy filter in existence. That would not be a good thing at all....

Re:Chrome and IE

[TheRaven64]

HTTP2.0 / SPDY will solve this, but it will take many years till they are widely adopted.

Not entirely. You still need to completely fetch and parse the main web page before you start fetching the images from it. If you use data URLs, then you implicitly fetch them before you even know that you need them. This is one advantage that Flash and Java applets have over JavaScript + HTML + image + sound files. There was some plan for allowing browsers to grab a page plus all of its resources in some kind of container file, but I don't recall it going anywhere.

To clarify

[hennikl]

As the author of the cited paper, I feel that I have to clarify a few issues here: As well as Opera and Firefox, GOOGLE CHROME ALSO "suffers" from the ability to host data URIs. It just distrusts being redirected to one. IE (it is said) has a size limit to data URIs of 32 KB. However, in my tests, a ~26 KB URI was tried, unsuccessfully. The data URI phishing pages can be made in many ways, differing in how they use other data. One can make a true offline (or local) version of a web page if all linked content on the page is contained in the "root page" through yet another data URI. If the data URI web pages are presented on a computer running a related trojan program, this program may handle the communication of the "secret information" (credit card #, passwords, etc.). This can be done P2P (as in botnets) thus no need for server infrastructure. Another issue I'm discussing in my paper (http://klevjers.com/papers/phishing.pdf) is that of ownership to the data URI contents. I feel TinyURL unwittingly takes ownership of whatever content that is hosted there, as they store the entire (phishing) web page on their servers.