Self-contained XSS Attacks
The essence of all Cross-site scripting (XSS) attacks is unsanitized verbosity. In that respect every application that echoes input is vulnerable and can be potentially exploited by attackers to steal session identifiers, trick the user into performing some malicious activity, gather important information, etc.
XSS attacks can be persistent and non-persistent. Persistent XSS is more dangerous since it allow attackers to control exploited clients for longer. On the other hand non-persistent XSS is considered less dangerous although it has been widely used in many phishing attempts.
In this article I will expose some of my findings around a new attack vector which is of type non-persistent XSS but a lot more dangerous than the persistent one. This method can be used to successfully bypass some mail filters, XSS filters, application firewalls and sanitization functions. In fact if you are previewing this post with an RSS reader that is vulnerable you may try clicking on the following link which will result in a harmless greeting alert box.
Some of you might be familiar with this attack vector; this subject has been covered very vaguely in the past and none of its full potentials has been explored. The impact of this attack is much bigger today and could affect many web applications.
The name “Self-contained XSS” explains it all. It is a Cross-site scripting attack that does not require vulnerable web resource to echo input. Everything that is needed is contained in a single URL. Once this URL is executed the resource will be automatically assembled.
The URL must be prefixed with the data: protocol and follow special syntax. There are many protocols in modern browsers such as http:, https:, ftp: and about: but data: seams to be the most functional one because it could potentially enable rich AJAX applications to generate PDF, DOC, MP3, etc formats without the need of server side scripts. The specifications of this protocol were outlined 1998 rfc2397 from Xerox Corporation.
The following example demonstrates the enormous capabilities of the data: url schema and also outlines the possible security risks. In the text area bellow you will be able to generate html payloads that can be opened and executed.
The impact of Self-contained XSS is even bigger than one can imagine. This technique allows dynamic creation of binary files from JavaScript. JavaScript worms are now able to create DOC and PDF files that may contain malicious payload for exploiting various overflow vulnerabilities. For example the following link opens a Self-contained word document which luckily is absolutely harmless.
This issue is mainly related to Firefox, Opera and probably other browsers. IE6 and IE7 are not affected in that respect although it is believed that there might be other means of achieving the same result. Keep in mind that this is not a vulnerability but rather a feature.
My research shows that too many applications are vulnerable to Self-contained XSS attacks. Applications from Google, Yahoo, MSN and Live, Youtube and many more may fall into this group.
It is important to understand that this attack vector can be exploited on a massive scale so standard practices for testing for this issue must be implemented and included in all web application testing procedures.
GNUCITIZEN is one of the most influential organizations of its kind, reaching thousands of users every day and having a strong relationship with numerous printed and web-based media outlets. Part of our mission is to let others succeed the same way GNUCITIZEN did. Therefore, if you have a research or an interesting information you would like to share, 
comments
2001 called, they want their exploit back.
I’ve played around with data uri’s and there is certainly potential to evade specific character filters using this method in certain situations.
I have created a test document.
first
click
after
the script included in the link is this:
Well, guess what: d is null!
So, this is not actually an XSS.
You cannot access document DOM or cookies.
What attack vectors do you see for this vuln?
The test document is:
This is huge and amazing.
Thankyou. The more I read your blog, the more I get excited by reading your blog. The more I get excited the more I want to read. So I am on a never ending circle of reading and waiting for more to read!
Of course d is null, you’re loading a whole new “page”.
Blad3, near is quite right. Data URLs are not able to access cookies and other information mainly because they are loaded in completely new page, not to mention that they exist in the about:blank space.
The impact of Self-contained XSS Attacks varies depending on how skillful attackers are. There are many possible attacker scenarios. Please feel free to check AttackAPI project for more information what is possible from JavaScript. These are just some of the things.
Jason, I am happy that you like my blog. I hope that it continues to be this way in the feature. Thanks.
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.
RSnake,
I am not claiming it is new. In fact I clearly stated in my post that some of you may already be familiar with it. Apparently you are.
To be honest with you, cookie theft is probably one of least things I am interested in. Data URLs are brilliant for enabling very powerful attacks. I am surprised that they have been covered so vaguely in past. There is so much potential in them.
I am quite concerned about JavaScript tools being able to assemble PDF and DOC documents on the fly. What about worms that carry their payloads in a single URL? IMHO this is a serious security issue.
this is not work in IE.6.0
The browser shows that “the page can not be displayed”. Even if it works, all this is harmless, just useless tricks.. I cannot get remote control, cannnot install files remotely, cannot change/delete html pages..
RSnake, would you like to describe in more detaila what do you mean with “building CSRF tools”. CSRF - cross site request forgery - I suppose.
Thanks
Hi Denver,
I stated that it doesn’t work in IE6 and IE7. I don’t quite agree that it is harmless for reasons I have already discussed in this post. You may browse through this website for clues why this is so. Thank you for your comments.
RSnake, I didn’t even know this attack vector was in your cheat sheet and I have been through it loads of times - A table of contents might be cool.
pdp, cool paper.. I think this area needed additional light and explanation.
I would like to think that any half decent application filter should be able to decode base64 and check it for script tags, but heck, who am I kidding :)
Nice work pdp! Another reminder that we shouldn’t trust anything when we go online.
Here is my personal recipe for those users that are paranoid:
- go online using restricted-user privileges
- use a browser extension which allows you to whitelist which domains are allowed to run scripting (i.e.: Firefox’s NoScript)
- use common sense!
Will keep checking your site regularly pdp!
This reminds me of the old functionality (now disabled) in Netscape’s about: “protocol”. Circa ‘98 I used to set the start pages on my high school’s machines to “about:Hi [the admin’s name]!” or something stupid like that.
Also see http://www.guninski.com/netscape.html
this is very useful and helpful article.But i have one question,the uri like this:
can it work on IE?i really want to know,thanks!
Hi superlone,
As far as I know IE6 and IE7 does not support data URLs. However, I believe that this is quite useful feature that could benefit many AJAX applications. I won’t be surprised if Microsoft implements data URLs or similar mechanism some day.
Again, although it is quite useful, keep in mind that this can be used in very bad ways.
heh nice guys, i’ve known about this for a while, didnt think it would work for other applications, nice jobb i love your guy’s work at this site :)
pdp and RSnake. Why do you think, that cookies theft don’t work with this attack vector. As I tested the alert(document.cookie) script is working fine and you may see cookie (and so you may steal it).
You just need to put a link with appropriate (encrypted) data in href attribute on site. And than cookies tricks will be possible in current domain.
Not sure under what topic should I put this.
http://wasjournal.blogspot.com.....d-www.html
Kishor, that is quite interesting but it will be even more if we can see some HTML. :)
pdp,
Unfortunately I do not have the HTML stored, because they fixed it too quickly.
Fortunately I had taken this snapshot.
But I’m sure many Indians have seen that flag that day.
URL decoded version looks like this
I’m able to read cookies using this technique! Not directly but certainly possible. MustLive is right
My original tests were a failure but now when you are saying that it is possible I must have a second look at this issue. Thanks, man.
This is how Orkut thing could have happened
http://wasjournal.blogspot.com.....ector.html
nice