AFAIK all recent versions of noscript detect malicious DOM in data:

Good times… Good times…

One thing is for certain, there are tones of vulnerable sites and extensions due to this data: URL scheme behavior

Sure. And every site that filters links using a blacklist will be vulnerable to *something*. But most sanitizing attempts don’t go much beyond filtering out the word “javascript” (and we don’t need the XSS cheat sheet to know that this is not nearly enough). This is an education issue of course, but one that we probably won’t see solved in the next few years.

Note that Firefox no longer allows HTTP redirects to data: URLs. Blind redirects are very common and this was making each of them an XSS vulnerability.

I mean it serves no real purpose, I can use ajax for client to server communications, javascript to control the gui, xml for data and xslt for style. The only _real_ benefit is image generation and even then why would generate images on the fly. There are already many and fair better ways to deliver image and rich media content to the screen.

Mozilla should just drop it and let it die.

Boris and Jesse, first of all, the reason I’ve put this together is mainly to inform my personal surprise that actually this thing works. I’ve been playing with data urls for ages, though never new they are executed within the context of the calling page. Of course it makes sense but, because, as you said, the caller needs to communicate somehow with the spawned page, you have to allow this type of communication. Though, not Safari nor Opera follow Mozilla’s design decision. So, even if this is the intended behavior, you guys have a lot of work to do in order to make sure that developers clearly perceive data: URLs as javascript: URLs. Yes, this vector has been in the cheat sheet for ages. I wrote about it like an year ago over here. RSnake, the guy who put the cheat sheet, has responded on this with the following:

This has been on the XSS Cheat Sheet for nearly two years and has been documented elsewhere for years before that. It’s no different than the javascript: directive in a URL. This isn’t new. It’s useful for certain things, like building CSRF tools, but cookie theft is not one of them.

One thing is for certain, there are tones of vulnerable sites and extensions due to this data: URL scheme behavior, mainly because of the lack of education, including on my side as well.

And no, it is not the same as file: or any other URL protocol. These protocols are successfully blocked by the browser when served from http: and https: origins.

The best way to pro[j]ect yourself from this kind of attack

Netscape 4 has “mocha:” and “livescript:”, and IE has “vbscript:”, so it has never been the case that blacklisting just “javascript:” in web applications was safe.

This wasn’t exactly secret. The bug report is not hidden, and http://ha.ckers.org/xss.html and http://www.squarefree.com/secu.....opers.html both mention data: URLs as potential XSS vectors.

Giving data: the origin of its loader has the obvious benefit that one can communicate back and forth with an loaded via a data: URI.

As for extensions, they are supposed to do security checks on all URI loads. And in most cases they want to use the “disallow loads that inherit the origin” flag to said security check. Any extension that doesn’t do that is in for a world of hurt, and not just due to data:. It’s easy to abuse other protocols (file:// comes to mind) if the extension blindly loads them.

http://www.criticalsecurity.ne.....73&hl=

You can also use base64 in the meta tag

<META http-equiv="refresh" content="5;URL=data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTs8L3NjcmlwdD4=">

or drop the base64 altogether

data:text/html,<script>alert(1)</script>

you can also use it to get the use to be prompted to download files but i haven’t worked out how to make that work correctly yet

data:text/cmd;,test