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."
In other words... (Score:1, Insightful)
Lucky them, they can pose now as "more secure".
Re: (Score:1)
Re: (Score:1)
Re:In other words... (Score:5, Informative)
Re: (Score:3, Interesting)
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: (Score:3)
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.
Underlying Operating System ... (Score:2)
Re:Underlying Operating System ... (Score:5, Informative)
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.
Re: (Score:3)
So, the first thing we did against phishing is still working...
No, it isn't. For a lot of people it doesn't. It may work for you and me because we understand the technology, but it doesn't for millions of users who don't.
The issues in phishing are multiple - I've given speeches about some of them - and "don't click those links" as a "solution" is about as good as telling smokers to "just quit already" - there is a small fraction on which that actually works, but for most people it doesn't.
Re: (Score:3)
No, it isn't. For a lot of people it doesn't. It may work for you and me because we understand the technology, but it doesn't for millions of users who don't.
People who are falling for E-Mail scam would also fall for it they'd receive it via mail, or get a phone call...or if you suddenly stand at their doorstep. Heck, some of them even would fall for it if you talk to them in a public park.
Re: (Score:2)
People who are falling for E-Mail scam would also fall for it they'd receive it via mail, or get a phone call...or if you suddenly stand at their doorstep. Heck, some of them even would fall for it if you talk to them in a public park.
This is obvious. What's not so obvious is that we collectively, if not individually, encourage this behavior. We made "network" into a verb. We allowed "inherited trust" (like "friends of friends"). And we advocated antivirus and firewalls as a solution, not a remedy.
And we don't punish them, or allow them to be punished for their crimes when their machines spew out spam or attempt to infect others with viruses. No, then we call them "victims". We don't call fences or johns "victims", do we?
By panderi
Re: (Score:2)
but it breaks if you get too close to the car in front
While they have brought back the Dodge Dart, I really meant "brakes" here...
Re: (Score:2)
Can we please start fining a lack of common sense? So these people at least pay for all the extra costs to society, and evolution can slowly start selecting against them?
THIS!
Re: (Score:2)
Look at a modern car. Not only does it parallel park for you, but it breaks if you get too close to the car in front
Man, your car sure is poorly engineered. You have to see a mechanic every time you get too close to another car?? I think I'd trade that clunker in!
Re: (Score:2)
Can we please start fining a lack of common sense? So these people at least pay for all the extra costs to society, and evolution can slowly start selecting against them?
Part of it is common sense, part of it is bad design and bad technology and lots and lots of bad on our end.
I have a nice slide that I use in my presentations on the subject. I don't think I need it here on /. - picture your typical phishing e-mail displayed in your typical e-mail app. Here's your problem:
Everything that invites you to click on that link, fall for that scam, make that mistake, is in the center of your field of vision, big, in colour, drawing your attention. Psychology at work.
Everything tha
Re:Underlying Operating System ... (Score:4, Insightful)
If it would work, we would see a considerable decline in phishing activities and success, because we (i.e. the IT security industry) have been telling that line to users for about a decade now.
All the statistics I have available show no such decline. The Verizon data breach report is publicly available and has been saying on and off for many years that phishing is still an issue, is getting bigger, is not decreasing as much as everyone had hoped, etc. etc.
Fact: Phishing still works enough to be a big industry.
Fact: We've been saying "don't click on e-mail links" to users for 10+ years.
Fact: The IQ 100 median norm has slightly increased during that time.
Conclusion: People are dumb is not a sufficient answer.
Addendum: Humanity has used lots and lots and lots of stuff in its history that didn't work. Raindances, homeopathy, coins for the ferryman, need I go on?
Re: (Score:2)
As a matter of fact, at least one study concluded that IT professionals score only marginally better at phishing detection than average users (within the margin of error, I believe), and IT security professionals just slightly better again.
It's not a matter of "we are doing it right, they are stupid".
Your counter-argument is flawed because it does ignore the emergence and education of new users, which due to the constant growth of Internet access has been a major factor that you can not ignore.
User educatio
Re: (Score:2)
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.
Wonder if this works on /. (Score:4, Funny)
Testing if I can embed
Re: (Score:3)
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.
Re:Wonder if this works on /. (Score:5, Interesting)
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: (Score:3)
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?)
Re: (Score:3)
Same reason slashdot doesn't allow unicode: it's based on really old software.
Re: (Score:3)
(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.
Re: (Score:2)
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.
Re: (Score:1)
^bump^ (Score:2)
Well played Anonymous Coward.
This changes everything
Here's an online Base64 decoder for those unwilling to click the link
http://www.motobit.com/util/base64-decoder-encoder.asp [motobit.com]
Don't forget to set it for "decode"
Can anyone explain to me why this is worse than (Score:2)
Re:Can anyone explain to me why this is worse than (Score:4, Interesting)
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: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:3)
But the URL will still not be your bank! (Score:2)
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.
Re: (Score:2)
> ...you would have to be pretty stupid...
So it only works on half the population.
Re: (Score:2)
> ...you would have to be pretty stupid...
So it only works on half the population.
Good point.
And then what? (Score:2)
So I click on a link and a page loads, as expected. What happens then? How does that page compromise my browser?
Re: (Score:3)
Re: (Score:2)
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.
hmmm (Score:1)
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
NoScript says ... (Score:1)
... 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
This works as intended, not an attack (Score:2)
To clarify (Score:4, Interesting)
Re: (Score:1)
I'm not surprised to see the astroturfing come in so quickly, either.
Re: (Score:2, Insightful)
Whatever may or may not be true in regards to IE security, this particular vulnerability does not work on IE because it has a length limit on data URIs, not because anyone thought of it and secured it against it. It's accidental. Chrome is the browser that has an actual security feature preventing this attack.
Re:Chrome and IE (Score:5, Informative)
I'm sorry, but that's downright untrue. See for yourself: https://en.wikipedia.org/wiki/Data_Uri#Web_browser_support [wikipedia.org]
Microsoft has limited its support to certain "non-navigable" content for security reasons, including concerns that JavaScript embedded in a data URI may not be interpretable by script filters such as those used by web-based email clients. Data URIs must be smaller than 32 KiB in Version 8.
Version 9 does not have the 32 KiB limit.
Re: (Score:2)
Interesting. Then Wikipedia and TFA are at odds regarding their claims regarding IE data support. Thanks for the correction.
Re: (Score:2)
No worries, IE still supports MHTML which doesn't have the lenght limit.
Re: (Score:3)
Re:Chrome and IE (Score:5, Insightful)
sandboxing is just another layer of security, it isnt a silver bullet solution... in fact many times (like in chrome) is used as a excuse to not proper check things and do a more careless development (from the security point of view). all is well until someone finds a way to break out the sandbox (just look at the recent java security problems) and then you can use one of the many holes to hop jump the sandbox and reach the OS.
Firefox mostly dont have sandbox, but have many other proper security checks that other lack, and its secure because of then. Of course sandbox is yet another layer that should exist and they are slowly sandboxing key areas. Its harder because they want to support various OS at the same level where chrome have a full sandbox in windows but a lot weaker one in linux (see https://code.google.com/p/chromium/wiki/LinuxSandboxing [google.com] and https://code.google.com/p/chromium/wiki/LinuxSUIDSandbox [google.com]... things might be better when seccomp [lwn.net] is enabled by default in chrome)
So yes, sandbox is good, but should not be trusted as the main security barrier in one application, other checks are always needed.
Re:Chrome and IE (Score:5, Interesting)
What are some benevolent use cases of these data URIs that justify supporting them? I'm not baiting you, just ignorant and curious.
Re: (Score:3, Informative)
small inline images on a webpage, it saves a separate retrieval of the image. Of course the download is a bit larger since the image is first base64 encoded.
Re:Chrome and IE (Score:5, Informative)
The best use case I know of is to inline all your small images you use for styling the site in the master stylesheet for the website. This way you only have one request instead of the hundred plus that many sites have.
Based on some tests I have done on many sites the vast majority of the time is spent on just getting 304s back on all the resources that have not changed. Inlining those small images can save 90% or more of the page load time.
Re: (Score:3)
To solve this latency problem, most well-designed websites use a single large GIF or PNG for all their tiny CSS images, then slice the image to indicate each independent icon, border, etc. This not only reduces the total image overhead but also greatly reduces the total number of 304s to receive.
Example: one of Facebook's icon resource files [fbcdn.net]
Re: (Score:3)
Re: (Score:1, Informative)
Re:Chrome and IE (Score:5, Insightful)
I've been reading the Wikipedia entry, and if I grasp it correctly there's a distinct negative repercussion to use of them: they could apparently be used to stuff HTML elements into one "get" and possibly defeat all sorts of HTTP proxy filters, ad blockers, and other sundry Web-page tweakers in the process. If that's true, I would not be in favor of their use or support at all. I use all sorts of tools and extensions to "take back the Web"; I don't want to lose the abilities those tools enable.
Re:Chrome and IE (Score:4, Informative)
It would block proxy filters and adblockers, /if/ the ads were kept onsite(which is one of the main problems with most ads today - loading them from offsite takes ages). Otherwise, any browser-based tools will simply treat it like a image/object from the page which can then be blocked accordingly. It will be loaded, but the extra KB or so in the single main page request won't really affect load time on anything but dialup, and the time will be far less than if the image was seperate.
Re: (Score:2)
If the server side code pulled the ads and the page was dynamically generated, you'd have the "best" of both worlds. Unblocked ads that weren't stored locally.
Re: (Score:2)
The problem is advertizers don't trust their customers not to cheat. What's to stop you, a site owner, from requesting the ad a billion times and sending it to /dev/null?
Only a customer-originated request hitting your adserver assures the customer got the ad.
Then, client-side adblocks would still be able to block the ads...
For me,the greatest yet-unrealized advantage of data URIs is what the article lists as its disadvantage: ability to easily integrate rich user content, without need to upload it to some s
Re:Chrome and IE (Score:5, Informative)
They were originally implemented to contain data inside documents where you need everything to be contained in one file - such as early e-mail systems.
Re: (Score:2)
I noticed from the Wikipedia article that it had a long history dating back to the late Nineties. Webmail certainly had more limitations back then, not that HTML was really designed to handle that job.
Re: (Score:3)
And they're AWESOME for packing a few small images into a CSS file to save round-trips to the server and make life MUCH better on mobile devices with high latency.
Re:Chrome and IE (Score:5, Informative)
Using 5 paralel connections (max allowed by http) the site will download in 10/1280*100 + 0,025*20 = 1,28 seconds
Embeding all images in original document using data URI's (~1.37x overhead to data size but no latency impact), the site will download in 10*100*1,37/1280 = 1,07 seconds
HTTP2.0 / SPDY will solve this, but it will take many years till they are widely adopted.
Re:Chrome and IE (Score:4, Interesting)
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: (Score:2)
Only until you create rules for blocking that include it; it won't prevent the ad from /loading/, but it can stop it from displaying. And this sort of ad wouldn't allow for load tracking specifically, so it wouldn't matter - you're loading the mainpage anyway, right?
Re: (Score:2)
Ads are always loaded from other domains, don't worry about that.
Re: (Score:2)
It's not at all nice to deliberately misframe the comments of another merely to create an artificial opportunity to mock him. You're being a tool, and not the useful kind.
I said it was a WORRY that it COULD be used that way. I said nothing at all about whether I thought such extensions and proxies could be updated to compensate, and I said nothing about it because I don't actually know that to be the case with any authority; for all I know it might not even be possible to intercept such repackaged element
Re:Chrome and IE (Score:4, Interesting)
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.
Re: (Score:3)
Re: (Score:3, Informative)
When using high-latency - high-throughput connection (i.e. mobile, satellite) then data-URI will be a lot faster than caching.
Re: (Score:2)
1,08s since a query to the server for each image is still required
That's not the case if the images came with an "Expires" header or similar, browsers will just reuse them without any network operation. You can verify this with all the built-in header/network debugging facilities in major browsers.
Re: (Score:2)
The problem I ran into is that in practice people rarely actually use expires. They just let their web framework send a 304 when the browser checks. Also if you use expires it makes things more complex since if you change the image the new information does not show up instantly.
Mostly though the problem is very very crappy web frameworks.
What I do is set the expires etc stuff to 30 years or so and then I change the urls to the images whenever the image changes. That works insanely well since everything cach
Re: (Score:2)
What they usually do is create one CSS-file with all the smaller images included. The CSS-file can be cached, but still saves a whole bunch of requests for small images.
Re: (Score:2)
Your argument is invalid.
Most of us are using http1.1 which has connection keep alive.
That would make your example 0.80625 seconds where uris would still need 1,07 seconds.
Also if you live somewhere where you need 25ms for a tcp handshake to complete, consider changing your ISP.
Re: (Score:2)
Re: (Score:2)
Are you crazy? 25ms is very fast for a tcp handshake.
Re: (Score:2)
Embeding all images in original document using data URI's (~1.37x overhead to data size but no latency impact), the site will download in 10*100*1,37/1280 = 1,07 seconds
The size overhead would be likely not much of an issue; the data URIs would compress quite reasonably back down to something close to the originating data size (assuming a compressed data format, of course, but that's the overwhelmingly common case). Reworking the math to allow for the compression takes the download time estimate back to 0.78s; that's about ~40% faster, not ~20% faster as you had worked out.
On the other hand, I suspect your calculations are an oversimplification anyway due to the fact that
Re: (Score:2)
The biggest problem with TCP is False Start, but which means many small HTTP-requests will still be a lot slower than sending one large HTTP response.
Re: (Score:2)
You could also stitch all the images together in a grid and then use CSS to display different portions of the same image. JQuery does this for widgets.
Re: (Score:2)
Many do both, include the sprite (as such a grid is called) in a CSS-file, the CSS-file is referenced on many pages on the site.
Re: (Score:1)
Re: (Score:2, Informative)
One use case is the local generation of downloadable content. For example, if you generate a sound file with Javascript, you can present the file as a clickable link that will allow the user to save the file, without first sending all the data to the server and then downloading it from there. A DTMF sequence generator could be written as a 100% client side script. An image processing script could likewise allow the user to save the edited image locally. There exist Javascript libraries for that purpose whic
Re: (Score:2)
Chrome uses data uris internally for inline background-images in CSS.
Webpages can use them for similar purposes. One less resource to query for.
They can also be used to easily construct files for the user to download, then you can stick them in a data uri and present them to the user as a link, or navigate to a data uri to force a download or display the resource to the user.
Re: (Score:2)
Any relation to account 527904? Hope not. That one's a tool.
Re: (Score:2)
It's convenient to put a black-and-white low-res placeholder image on a page using a data uri, so the area of the page where the full-resolution image will eventually be placed isn't blank while waiting for the much larger image to download.
Re:Chrome and IE (Score:5, Informative)
I'm not actually sure that this is the case. [wikipedia.org] (Change the Wikipedia entry if it's wrong, then.)
Re: (Score:3, Informative)
it's more about how IE and Chrome don't support DATA uri's. the article is stupid. that's what the article really is about, if it supports data uri's or not.
Chrome and IE both support data URIs. Chrome doesn't allow redirecting to a data URI for this reason
Re: (Score:2)
Re: (Score:3, Informative)
it's more about how IE and Chrome don't support DATA uri's. the article is stupid. that's what the article really is about, if it supports data uri's or not.
WRONG! From the PDF:
"In Google Chrome in particular, a control for unsafe redirection is im-
plemented, disabling the user direct access to a data URI if that URI is
the target of a redirection, such as from a URL shortening service."
"Internet Explorer has a limit to data URIs,"
Google Chrome and IE have implemented security features to prevent this form of attack.
Re: (Score:1)
They're doing it wrong, the correct security implementation is a warning prompt for the user.
Re: (Score:1)
Why the fuck is he marked insightful. Both Chrome and IE do support DATA uri's. FFS at least check if someone is talking out their arse before modding them up.
their implementation of data uri's is different, from what I gathered from the guys posts some browsers just don't support as long mega-long data uri's.
and a guy is likely to link the link rather than be redirected to one in the first place, no? but ultimately the article isn't about phishing, but about different support for data uri's. the phishing angle is just tacked on so that the guys paper would get eyeballs.
Re:Chrome and IE (Score:5, Informative)
and a guy is likely to link the link rather than be redirected to one in the first place, no?
No - that was one of the points of the article.
Increasingly the source of phishing URLs is social media rather than email. In tweets (and to a lesser extent on other social media) it's common to send a shortened URL (tinyurl, bit.ly, goo.gl etc) that redirects to the actual URL, and consequently users won't be surprised to receive such a short URL, and will probably click on it - whereas if they received a massively long "data:" URL with lots of base64 data after it, their suspicions would be more likely to be raised...
Re: (Score:3)
Re:Inconsistantly Odd Alert (Score:2)
File this one under uninteresting and an obvious forgery.
Technically this is not much different than just hosting a look-alike page to collect passwords. The phishing attack would be much more interesting if the URL wasn't so obviously bogus. According to the paper an attack could use a URL shortener to further hid the obviously odd URI. The problem with this is that the URI attack described in the article requires that you send the URI with payload to the victim. A URL shortener service has no reasonab
Re: (Score:2)
> You can do a lot with a data URI
But can you do anything actually useful with one? Seems like a poorly thought out idea to me. I see no good reason why anything in a URI should ever be rendered or executed.