Slashdot Mirror
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."
What are some benevolent use cases of these data URIs that justify supporting them? I'm not baiting you, just ignorant and curious.
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.
I'm not actually sure that this is the case. (Change the Wikipedia entry if it's wrong, then.)
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
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.
Testing if I can embed
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.
Assorted stuff I do sometimes: Lemuria.org
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.
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.
Assorted stuff I do sometimes: Lemuria.org
Take a website with 100 small images, with average image size 10kb, latency (3-way handshake+data) = 25ms, and your bandwidth = 10Mbit/s
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.
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.
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.
Crap. What did the new CSS do with the "Post anonymously" option??
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....
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.
I am TheRaven on Soylent News
I'm sorry, but that's downright untrue. See for yourself: https://en.wikipedia.org/wiki/Data_Uri#Web_browser_support
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.
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...
Need to type accents and special characters in Windows? Use FrKeys
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.
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 and https://code.google.com/p/chromium/wiki/LinuxSUIDSandbox... things might be better when seccomp 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.
Higuita
In some cases, data-URI might be still faster (though less bw-effective), i.e if you take the original example and account for 54ms latency (3way handshake+initial response packet) then reloading the page (with all images cached) would take 0,054*20=1,08s since a query to the server for each image is still required
When using high-latency - high-throughput connection (i.e. mobile, satellite) then data-URI will be a lot faster than caching.
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?
Assorted stuff I do sometimes: Lemuria.org
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.
Computer modeling for biotech drug manufacturing is HARD!
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.
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.