Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Crime Firefox Opera Security Your Rights Online

Firefox, Opera Allow Phishing By Data URI Claims New Paper 151

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."
This discussion has been archived. No new comments can be posted.

Firefox, Opera Allow Phishing By Data URI Claims New Paper

Comments Filter:
  • In other words... (Score:1, Insightful)

    by c0lo ( 1497653 )
    In other words, IE and Chrome do not implement the data URI [] to the specification.
    Lucky them, they can pose now as "more secure".
    • by Anonymous Coward
      reading more of the paper, it is more a case of both IE and Chrome have additional security mechanisms around Data URI's, not an issue with them not implementing them.
    • Hey now, as Steve Jobs will tell you, that's a feature.
    • Re:In other words... (Score:5, Informative)

      by bloodhawk ( 813939 ) on Tuesday September 04, 2012 @04:11AM (#41220375)
      nope, it appears to be that both Chrome and IE have other protections around Data URI's, they both implement them. Chrome does it by preventing redirections.
    • Re: (Score:3, Interesting)

      In other words, IE and Chrome do not implement the data URI [] 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.

    • by micheas ( 231635 )

      If I understand the situation correctly, the situation is that tiny url returns a redirect to a data URI.

      IE and Chrome do not forward from an external URI to a data URI, which considering that the point of data URI's is to reduce http requests, this seems somewhat reasonable.

      It seems to me that the core problem is cross domain 30x redirects being transparent in browsers.

  • How do these malicious URIs get access to the underlying Operating System?
    • by Tom ( 822 ) on Tuesday September 04, 2012 @03:55AM (#41220299) Homepage Journal

      They don't. It's a phishing attack, its intent is to get you to enter your password to some interesting site on a fake of that site. Afterwards, they'd redirect you to the real one or show a bogus error message, and then loot your account there.

      One attack vector against phishing attacks has been to take the site down where the fake is hosted. If the bad guys don't have to host the fake anymore because it is entirely self-contained in the phishing mail you send out through their botnet, then there is one less thing we can do against phishing.

    • by Jonner ( 189691 )

      How do these malicious URIs get access to the underlying Operating System?

      If you'd read TFA, you'd know this is potentially useful as part of a phishing attack to fool users supplying private data such as login credentials to an attacker. It is not a vulnerability in any browser.

  • by Sqr(twg) ( 2126054 ) on Tuesday September 04, 2012 @03:47AM (#41220269)

    Testing if I can embed

    • Nothing seems to happen if I click on the link with firefox. However, I do get to the spoof page if I manually copy the link location and paste it in the address bar.

      • by game kid ( 805301 ) on Tuesday September 04, 2012 @04:05AM (#41220341) Homepage

        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.

      • Nope. Apparently "copy location" doesn't work either. Firefox silently left the clipboard unchanged. (I just happened to already have the URI there from copying it into my previous post.)

        Slasdot does include the data URI in the HTML, but firefox seems to be immune to it.

        (Why doesn't slashdot allow editing of posts?)

        • Why doesn't slashdot allow editing of posts?)

          Same reason slashdot doesn't allow unicode: it's based on really old software.

        • by mcgrew ( 92797 ) *

          (Why doesn't slashdot allow editing of posts?)

          Because then you could post an insightful comment, get a +5, and edit it to be Goatse and GNAA. Or you could say something REALLY stupid, and when corrected, edit it to make whoever corrected your stupidity look stupid himself.

          Your editing options are the "preview" button.

          • Slashdot could make it impossible to edit your post if you get a moderation or a comment. It'd be better than nothing I think.

    • by n30na ( 1525807 )
      in chrome, it doesn't work at all.. just can't load page, even if copied to url bar manually. In firefox, clicking the link does nothing, while if copied to the url bar, it would appear that firefox tries to google it.
  • Can anyone explain to me why this is worse than serving up the same "malware" on a web page instead of a data URL? The screenshot in the paper clearly shows the url starting "data:text/hml;" instead of [] so surely it is just doing the same thing as if I hosted a mock wikipedia login on "" - and is a lot less likely to fool people than if I used a domain like
    • by Sqr(twg) ( 2126054 ) on Tuesday September 04, 2012 @03:58AM (#41220309)

      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.

      • by Chrisq ( 894406 )
        Fine for denial of service or such, but for harvesting it still has to get back to you somehow
      • OK, talk me through this. I want to steal a credit card number, Amazon login, or person's favorite color, using this technique. To prevent myself from being shut down before I can harvest the information, I encode the entire form, designed to look like my bank's home page/'s login page/, as a data: URI. The user enters the information into the dubious form and clicks "Submit".

        ...what then? How does the information get back to me without a domain that can be blacklisted?

        • Sends it to you through a chain of anonymous remailers.
        • The data you harvest is encrypted and posted as a comment on the same page where you stored the data URI, or sent to some irc channel, or to any of a million places on the internet that accepts data from a POST form and displays the result publicly.

          • OK, let's go through the options:

            1. Email. You receive email. You click on data: link. Where does phishing form send your crap to?

            2. Forum. You see a message on a forum requesting you log in to Amazon and re-enter your credit card. Wait. What? Anyway, this then takes advantage of the fact it's on a forum, a forum that doesn't have any CAPTCHA type stuff to prevent posting a new message, and nobody notices (a) the original post and (b) the information being posted back to the forum.

            3. One of the other

  • This might technically be a phishing exploit but you would have to be pretty stupid to fall for it still as the address bar at the top of the page would not be your banks a web address.

  • So I click on a link and a page loads, as expected. What happens then? How does that page compromise my browser?

    • It doesn't compromise your browser, it simply allows unsuspecting users to be tricked. hence why it is a phishing vulnerability e.g. a link supposedly to your bank login page, the page looks identical to your bank login page but sends the details to the link authors server where they can harvest your credentials to later empty your bank account while all the time appearing that you clicked on a valid link if you were not paying attention.
      • by Hentes ( 2461350 )

        But you don't need a data URI for that. I just don't see how using this achieves anything more than a traditional link. It won't be able to fake certificates and the URI will look very suspicious.

  • I actually went and read the paper that this is supposedly all based on. (I know, it's not the done thing and I apologise) I don't know if it has changed since the other article was written but I couldn't find any reference to Opera or Firefox.

    It does mention that Chrome will throw an error but if you hit enter or reload it will work. There is a one sentence reference to the fact that IE has "a limit to URIs". I presume that means a length limit and if so IE is not invulnerable - only the initial pa
  • ... in an alert box of it's own:

    javascript: and data: URIs typed or pasted in the address bar are disabled to prevent social engineering attacks.
    Developers can enable them for testing purposes by toggling the "noscript.allowURLBarJS" preference.

    Browsing the Web w/o NoScript is dangerous to the core anyway.

    Just my 2cents

    - Holger

  • The appropriate url is displayed, data URIs serve a purpose. OP, this is ridiculous. Quit giving this guy a voice.
  • To clarify (Score:4, Interesting)

    by hennikl ( 2719785 ) on Tuesday September 04, 2012 @07:01PM (#41228959)
    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 ( 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.

Competence, like truth, beauty, and contact lenses, is in the eye of the beholder. -- Dr. Laurence J. Peter