Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Firefox, Opera Allow Phishing By Data URI Claims New Paper

Unknown Lamer posted about 2 years ago | from the but-it-said-it-was-a-cat-picture dept.

Crime 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."

cancel ×

151 comments

Chrome and IE (0, Troll)

harryfeet (2721737) | about 2 years ago | (#41220147)

I'm not surprised to see IE ranking well. It has grown to be one of the most secure browsers ever made. Only Chrome has something like IE. Internet Explorer has sandboxing and JIT hardening and all these things while Firefox and Opera have hardly anything (Firefox is actually the worst in this regard).

Re:Chrome and IE (-1)

gl4ss (559668) | about 2 years ago | (#41220181)

I'm not surprised to see IE ranking well. It has grown to be one of the most secure browsers ever made. Only Chrome has something like IE. Internet Explorer has sandboxing and JIT hardening and all these things while Firefox and Opera have hardly anything (Firefox is actually the worst in this regard).

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.

Re:Chrome and IE (4, Interesting)

macraig (621737) | about 2 years ago | (#41220207)

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

Re:Chrome and IE (3, Informative)

Anonymous Coward | about 2 years ago | (#41220219)

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 (0, Troll)

harryfeet (2721737) | about 2 years ago | (#41220407)

ALERT! Don't mod up gl4ss in this thread. He is wrong. Both Chrome and IE do support data URLS. HE IS WRONG!

Re:Chrome and IE (1, Informative)

Anonymous Coward | about 2 years ago | (#41220901)

You sound like an 7 year old pretending to be a robot.

Re:Chrome and IE (5, Informative)

Ambassador Kosh (18352) | about 2 years ago | (#41221567)

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 (2)

The MAZZTer (911996) | about 2 years ago | (#41221845)

If your webserver supports GZIP compression in HTTP responses the difference might not be too bad.

Re:Chrome and IE (4, Insightful)

macraig (621737) | about 2 years ago | (#41220259)

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 (3, Informative)

RobbieThe1st (1977364) | about 2 years ago | (#41221623)

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:Chrome and IE (4, Informative)

Tom (822) | about 2 years ago | (#41220311)

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 (1)

macraig (621737) | about 2 years ago | (#41220397)

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:Chrome and IE (5, Informative)

nomaddamon (1783058) | about 2 years ago | (#41220327)

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.

Re:Chrome and IE (3, Interesting)

macraig (621737) | about 2 years ago | (#41220409)

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 (1)

RobbieThe1st (1977364) | about 2 years ago | (#41221635)

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:Chrome and IE (0)

TheMMaster (527904) | about 2 years ago | (#41221735)

And we all know that that software is entirely static and won't ever get updated to support data uris before they are in widespread use.

Good catch sir!

Re:Chrome and IE (3, Interesting)

TheRaven64 (641858) | about 2 years ago | (#41220471)

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:Chrome and IE (2)

Lazy Jones (8403) | about 2 years ago | (#41220973)

OTOH if those small images can be cached, the advantage of using data-URIs disappears (is negated) on the 2nd time someone visits the page. So I don't think it's a very good idea to do it in this case.

Re:Chrome and IE (3, Informative)

nomaddamon (1783058) | about 2 years ago | (#41221045)

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.

Re:Chrome and IE (2)

someones (2687911) | about 2 years ago | (#41221359)

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:Chrome and IE (1)

thomthom (832970) | about 2 years ago | (#41220507)

Avoiding expensive HTTP requests.

Re:Chrome and IE (2, Informative)

Anonymous Coward | about 2 years ago | (#41220747)

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 (0)

Anonymous Coward | about 2 years ago | (#41221117)

2 minor points: extracting data URI from canvas is standard API, no need for libraries and Google proposes download="" attribute to give preferred filename for <a> tag.

Still, recent browsers have FileWriter API, so this use-case of data: URIs is only relevant to older browsers.

Re:Chrome and IE (0)

Anonymous Coward | about 2 years ago | (#41221671)

Right, I needed an unsupported file format, so I had to resort to an encoder written in Javascript instead of using a built-in encoder. The download attribute is nice, but apparently it's not widely supported. Neither is the FileWriter API.

Re:Chrome and IE (0)

Anonymous Coward | about 2 years ago | (#41221835)

I stand corrected. Unlike reading [caniuse.com] files [caniuse.com] , FileWriter [caniuse.com] is supported only by 3 browsers now (2 of which are Chrome), so legitimate use for data: isn't yet going anywhere.

Re:Chrome and IE (0)

Anonymous Coward | about 2 years ago | (#41220953)

I use them to encode small icons into greasemonkey scripts instead of dealing with full blown extensions. There's one quite popular one that puts a pdf and envelope icon next to email and pdf links, for instance.

Re:Chrome and IE (0)

Anonymous Coward | about 2 years ago | (#41221597)

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

CSV export of dynamically rendered table data that's already in the browser.

Re:Chrome and IE (1)

The MAZZTer (911996) | about 2 years ago | (#41221913)

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:Chrome and IE (5, Informative)

bersl2 (689221) | about 2 years ago | (#41220229)

it's more about how IE and Chrome don't support DATA uri's

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 (0)

Anonymous Coward | about 2 years ago | (#41220981)

Doesn't work on Android like it says it should. I would change the entry, but every change I make gets reverted by the Wikipedia police.

Re:Chrome and IE (3, Informative)

Anonymous Coward | about 2 years ago | (#41220245)

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:Chrome and IE (1)

bloodhawk (813939) | about 2 years ago | (#41220331)

IE does support Data URI's though??? at least it did, have they removed this functionality or is it merely a more secure implementation than firefox and opera?

Re:Chrome and IE (0)

Anonymous Coward | about 2 years ago | (#41220399)

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.

Re:Chrome and IE (0)

gl4ss (559668) | about 2 years ago | (#41220439)

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 (4, Informative)

psmears (629712) | about 2 years ago | (#41220557)

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 (2)

e70838 (976799) | about 2 years ago | (#41221089)

I never click on a shortened URL. Maybe I am too old :-(

Re:Chrome and IE (0)

Anonymous Coward | about 2 years ago | (#41220551)

It depends. I have my Firefox compiled as a position independent executable (PIE), with full RELRO and ASLR. I also have it "sandboxed" with a Mandatory Access Control system that comes in the Linux kernel. It really depends on how the binary was compiled and with which compiler. On Windows machines such hardening is probably not common, at least for Firefox.

Sure Chrome has its own sandbox (on Linux it is merely a chroot), but I see little benefit of it over using AppArmor, for instance. It accomplishes the same thing.

Re:Chrome and IE (3, Informative)

slacka (713188) | about 2 years ago | (#41220725)

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 (1)

Anonymous Coward | about 2 years ago | (#41221007)

They're doing it wrong, the correct security implementation is a warning prompt for the user.

Re:Chrome and IE (1)

Anonymous Coward | about 2 years ago | (#41221085)

WRONG! "Has a limit to data URIs" is not a security feature, it's just poor implementation. Not redirecting to data URIs is a feature, as evidenced by ERR_UNSAFE_REDIRECT code.

M/24/Cali (-1, Troll)

Anonymous Coward | about 2 years ago | (#41220185)

harryfeet

Lets seem some pictures of those feet!

Re:Chrome and IE (0)

Doctor_Jest (688315) | about 2 years ago | (#41220201)

I'm not surprised to see the astroturfing come in so quickly, either.

gusess what (0, Troll)

Chrisq (894406) | about 2 years ago | (#41220283)

I'm not surprised to see IE ranking well.

I have a piece of shit in my toilet bowl that ranks just as well in this case. It too is incapable of opening data URLs

Re:Chrome and IE (2, Insightful)

Tom (822) | about 2 years ago | (#41220305)

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 (5, Informative)

cpicon92 (1157705) | about 2 years ago | (#41220497)

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 (1)

Tom (822) | about 2 years ago | (#41221113)

Interesting. Then Wikipedia and TFA are at odds regarding their claims regarding IE data support. Thanks for the correction.

Re:Chrome and IE (2)

hairyfeet (841228) | about 2 years ago | (#41220535)

Oh Lord its Twitter! Long time man, WTF you been up to? I can't believe you made a knockoff of my user ID, hell you made knock offs of Macthorpe and all the other old timers so I was starting to feel left out there, nice to see I'm well regarded enough to rip off, thanks.

As for TFA that's why i give my customers Comodo Dragon, based on Chromium but without all the Google phone home bits. the new IE may be secure but frankly who gives a rat's ass, when the refused to backport it to their STILL UNDER SUPPORT operating systems like XP (and isn't the next version only gonna work on 7 & 8?) it became completely useless as far as I'm concerned.

With Dragon you can run any Windows from XP-8 and have the same browser synced so it all "just works" which is nice and as a bonus you have any problems their devs are constantly on their forums and are quick to get back to you with help.

Re:Chrome and IE (0)

Anonymous Coward | about 2 years ago | (#41220731)

Why are you talking to yourself, asswipe?

Re:Chrome and IE (4, Insightful)

higuita (129722) | about 2 years ago | (#41220893)

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.

Something like this was in Old IE 4 (0)

Anonymous Coward | about 2 years ago | (#41220183)

I reported a bug in IE4, where I could basically make a URL:

About://HTML

and the HTML was replaced with whatever I wanted.

It took a couple versions but apparently they fixed it.

In other words... (1, Insightful)

c0lo (1497653) | about 2 years ago | (#41220205)

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".

Re:In other words... (1)

Anonymous Coward | about 2 years ago | (#41220359)

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.

Re:In other words... (1)

BuypolarBear (2713397) | about 2 years ago | (#41220369)

Hey now, as Steve Jobs will tell you, that's a feature.

Re:In other words... (4, Informative)

bloodhawk (813939) | about 2 years ago | (#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:In other words... (3, Interesting)

furbearntrout (1036146) | about 2 years ago | (#41220387)

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:In other words... (2)

micheas (231635) | about 2 years ago | (#41220415)

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.

Re:In other words... (0)

Anonymous Coward | about 2 years ago | (#41220719)

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.

Reducing HTTP requests isn't the only use case. In the past, I have specifically allowed data URLs in shorteners (protocol whitelist). Encoding then pasting the result into a web page can be much faster than uploading to a web server, much safer than entering server login credentials if you're using a 3rd party machine.

The sane thing to do would be a warning dialogue; "you are being redirected to a dataURL". With the requisite "do not show this warning again" checkbox.

Underlying Operating System ... (1)

dgharmon (2564621) | about 2 years ago | (#41220213)

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

Re:Underlying Operating System ... (0)

Anonymous Coward | about 2 years ago | (#41220257)

import os

Re:Underlying Operating System ... (5, Informative)

Tom (822) | about 2 years ago | (#41220299)

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:Underlying Operating System ... (0)

Anonymous Coward | about 2 years ago | (#41220313)

So, the first thing we did against phishing is still working...

Don't click on random links in emails. And if you do anyway, DON'T F*KING ENTER YOUR CC NUMBER.

Re:Underlying Operating System ... (2)

Tom (822) | about 2 years ago | (#41220463)

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:Underlying Operating System ... (0)

Anonymous Coward | about 2 years ago | (#41220899)

If it didn't work, we wouldn't use it.

Yes, it works. That some people refuse to use that method, doesn't mean that it doesn't work.

Your claim is just as stupid that claiming that German cars don't work, because I don't own one.

Re:Underlying Operating System ... (3, Insightful)

Tom (822) | about 2 years ago | (#41221105)

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:Underlying Operating System ... (2)

Robert Zenz (1680268) | about 2 years ago | (#41221003)

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:Underlying Operating System ... (1)

arth1 (260657) | about 2 years ago | (#41221195)

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 pandering to the unprotectable, we will in the long run harm ourselves. There's little reward for being security conscious and network conscientious. There isn't enough impact for evolution to select against the ignorant and for those who exercise common sense, because we protect and pander to the ignoramuses as much as we can.

Mind, this isn't just a computer and Internet phenomenon. 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, beeps or vibrates the steering wheel if you cross a yellow line or the speed limit, and monitors your eyes to wake you up if you drowse.
This won't fix the main problem, which is careless drivers. If anything, it will shape even less careful drivers who will be even more dangerous if they ever get into a car without these support wheels.

Similar for the PC and Internet. Our pampering of the careless and ignorant leads to a breed of users that are even more stupid than before. Put them on a machine without all the protections, and they will be even more a danger too.

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?

Re:Underlying Operating System ... (1)

arth1 (260657) | about 2 years ago | (#41221201)

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:Underlying Operating System ... (1)

Robert Zenz (1680268) | about 2 years ago | (#41221395)

That's exactly my point. OP made it sound like it would be a problem with the technology...which it isn't.

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!

News? (0)

Anonymous Coward | about 2 years ago | (#41220267)

I really wonder about the quality of new papers. There is no new attack vector. It is still phishing. It doesn't matter if the page is loaded from the phishing mail or from another server. I think it is harder to spot a typo in the domain than spotting the data line address.

Also it doesn't matter how you load the phishing website. If you clicked the link in the mail you are either curious to investigate or deserve to fall for it.

Wonder if this works on /. (3, Funny)

Sqr(twg) (2126054) | about 2 years ago | (#41220269)

Testing if I can embed the wikipedia spoof from TFA [data] in a slashdot comment...

Re:Wonder if this works on /. (2)

Sqr(twg) (2126054) | about 2 years ago | (#41220293)

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 /. (4, Interesting)

game kid (805301) | about 2 years ago | (#41220341)

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:Wonder if this works on /. (2)

Sqr(twg) (2126054) | about 2 years ago | (#41220355)

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:Wonder if this works on /. (2)

Vintermann (400722) | about 2 years ago | (#41220945)

Why doesn't slashdot allow editing of posts?)

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

Re:Wonder if this works on /. (0)

Anonymous Coward | about 2 years ago | (#41221125)

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

Because the error ridden nature that makes us all cringe, oft times results in very humorous and entertaining reading. Allowing the editing after the post would change things and the whole reason for reading Slashdot would disappear in the dust. Everyone would spend time thinking about what they are saying instead of just sticking their foot in it.

Do you really think that us anon cowards are really here for any other reason? Other than posting rhetorical questions like this one and constantly commenting about the illiterate state of computer users?

The other reason post editing is not allowed is that there is not enough time in the universe to edit some of the posts on this forum especially ones alluding to Internet Explorer being more secure than Firefox. The way this thread is turning out. I come here to read the nonsense and only on occasion do I find enlightenment but I always find my sides splitting at what happens when articles about user security are discussed.

Re:Wonder if this works on /. (1)

n30na (1525807) | about 2 years ago | (#41220315)

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.

Re:Wonder if this works on /. (0)

Anonymous Coward | about 2 years ago | (#41220615)

Slashdot mangles data URIs. You can still use some anonymous redirection services to get around the restriction: Don't click here [redirect.am]

^bump^ (1)

TubeSteak (669689) | about 2 years ago | (#41221707)

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 (2)

Chrisq (894406) | about 2 years ago | (#41220275)

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 http://en.wikipedia.org/ [wikipedia.org] so surely it is just doing the same thing as if I hosted a mock wikipedia login on "mysite.com" - and is a lot less likely to fool people than if I used a domain like wikipediaLogin.com

Re:Can anyone explain to me why this is worse than (3, Interesting)

Sqr(twg) (2126054) | about 2 years ago | (#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.

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

Chrisq (894406) | about 2 years ago | (#41220429)

Fine for denial of service or such, but for harvesting it still has to get back to you somehow

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

ArsenneLupin (766289) | about 2 years ago | (#41220525)

Theoretically, the phishing page could post the submitted data to some pastebin page (or similar service)

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

someones (2687911) | about 2 years ago | (#41221379)

or be served from there?

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

ArsenneLupin (766289) | about 2 years ago | (#41221453)

it would have the wrong mime-type (text/plain instead of text/html)

But the URL will still not be your bank! (1)

Ash Vince (602485) | about 2 years ago | (#41220279)

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:But the URL will still not be your bank! (1)

John Hasler (414242) | about 2 years ago | (#41221681)

> ...you would have to be pretty stupid...

So it only works on half the population.

And then what? (1)

Hentes (2461350) | about 2 years ago | (#41220281)

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

Re:And then what? (2)

bloodhawk (813939) | about 2 years ago | (#41220437)

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.

Re:And then what? (1)

Hentes (2461350) | about 2 years ago | (#41220875)

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.

Re:And then what? (0)

Anonymous Coward | about 2 years ago | (#41221471)

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.

See http://yro.slashdot.org/comments.pl?sid=3091769&cid=41220309 [slashdot.org]

Works fine in Chrome with two caveats (0)

Anonymous Coward | about 2 years ago | (#41220393)

Caveats:

1) Chrome doesn't seem to work with base64 encoding in the data URI scheme.
2) Chrome appears to have a length limit for page data. I was able to get about 11502 characters of URI encoded text rendered. That works out to 7717 characters of HTML in my test case.

JUST USE BIT.LY AND YOU ARE SAFE !! (0)

Anonymous Coward | about 2 years ago | (#41220547)

Because those are sooo short !!

I'll take what's behind door #2, Monty !!

Works in chrome (0)

Anonymous Coward | about 2 years ago | (#41220597)

Open the url in Chrome. Fails.

Now do Refresh. Voila!

So if someone can embed a refresh, haha.

hmmm (1)

ixuzus (2418046) | about 2 years ago | (#41220677)

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 payload has to be smaller.

While there is much hand wringing about the fact that it cannot be shut down because there is not central server it is hosted on I don't see it as an issue. For phishing to be effective the stolen data has to actually GO somewhere which probably provides a target that can be shut down. It doesn't matter how long the URI circulates after the target is shut down - all that stolen data is probably going to the great byte bucket in the sky.

I think the more interesting point that the paper made is that phishing sites can effectively be hosted on link shortening services using this method.

NoScript says ... (1)

holle2 (85109) | about 2 years ago | (#41220987)

... 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

Re:NoScript says ... (0)

Anonymous Coward | about 2 years ago | (#41221411)

Bump that. Not a shill, just a satisfied user.

How is this an attack? (0)

Anonymous Coward | about 2 years ago | (#41221347)

You click on a link and it displays the inlined HTML in a browser, exactly as the specification demands. The address bar shows a URL that starts with "data:" instead of "http:" and looks nothing like the URL of the spoofed site. What makes this a vulnerability?

Uri (0)

Anonymous Coward | about 2 years ago | (#41221575)

Does it also bend spoons?

You can do a lot with a data URI (1)

crumhorn (2722459) | about 2 years ago | (#41221589)

If you nest your languages, you can do a remarkable amount in a data URI: here's a Javascript chess-playing app, [tinyurl.com] and an unbounded supply of webpages [tinyurl.com] exploring the Collatz Graph, [wikipedia.org] respectively. I expect you could get a small phishing site (which pulled graphics, etc, from the real thing) done similarly, and there's no server to take down. Writing a viral data URI that mailed itself to your friends might be harder.

Re:You can do a lot with a data URI (1)

John Hasler (414242) | about 2 years ago | (#41221723)

> 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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...