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."
Re:Chrome and IE (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)
I'm not actually sure that this is the case. [wikipedia.org] (Change the Wikipedia entry if it's wrong, then.)
Re:Chrome and IE (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: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: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: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:In other words... (Score:5, Informative)
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: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:Chrome and IE (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:Chrome and IE (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 which convert HTML5 canvases into data URIs.
Generally data URIs come in handy when a roundtrip to the server is undesirable. Many use cases have different solutions now ("sprite collections" instead of many small files in web design, MIME embedded images in email.) Unfortunately, the potential for mischief has been quite obvious for a long time, because data URIs avoid many detection schemes by avoiding the server roundtrip, and consequently they have fallen from grace somewhat and saw no further improvement. You can't even suggest a filename if you use data URIs as a downloadable link.
Re:Chrome and IE (Score:1, Informative)
Re:Chrome and IE (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: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: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.