JavaScript Protocol Comment Newline Injection
I got an email from MaXe describing a way to inject JavaScript protocol directives in such a way, that they got around a rather stupid filter that looks for :// (naturally limiting you to things like http:// https:// ftp:// and the like:
Basically when researching this vulnerability I found out a “new” way: (at least in my little world) http://forum.intern0t.net/exploits-vulnerabilities-pocs/1502-vbulletin-3-8-4-cross-site-script-redirection.html http://forum.intern0t.net/blogs/maxe/62-having-fun-cross-site-scripting.htmlBasically some forum applications and such checks url inputs for ://, just like vBulletin did before the patch so after some time I came up with javascript:// ..
Which wouldn’t really do anything, but if you apply “new line” or “carriage return” (%0a or %0d) to the url then you have all the power in the world.
So basically javascript://%0A is “cancelling” the comment (actually the browser interprets it as a new line just as described in my blog) and there by making f.ex. alert(0) possible.
javascript://alert(0) wouldn’t work of course since alert(0) is commented out.
javascript://%0Aalert(0) works because alert(0) is placed on a new line!
Pseudo example:
<script>
// %0A ( \n aka new line )
alert(0)
</script>I know it looks so simple and anyone could have come up with that, but I haven’t seen it yet anywhere on the net and it made my day.
Pretty clever filter evasion there. Easy enough to patch, of course, but just another great example of how people’s mis-understanding of the protocol and languages they are attempting to thwart works against them. Chalk this up to another blacklist that shouldn’t exist.
October 14th, 2009 at 8:52 am
There was a vulnerability of this nature found in phpBB over 4.5 years ago:
http://marc.info/?l=vulnwatch&m=111774418113841&w=2
On the surface, it doesn’t seem like the proposed fix would work, but, in point of fact, it does. The reason being that by replacing : with its html entity, bbcode parsing is prevented. ie. the bbcode parser is looking for something matching the regex [\w]+?:// and an html entitized : doesn’t.
Now, sure, maybe a whitelist would be better (I only mention that because of your “blacklist that shouldn’t exist” comment), but whatever. The point is, this particular filter evasion is atleast 4.5 years old.
That said, I do believe it reasonable that this particular filter evasion be added to the XSS cheat sheet.
October 14th, 2009 at 11:24 am
It’s not big or clever it’s obvious. Sorry to be a ball breaker but you know I can’t help it
October 14th, 2009 at 11:26 am
Filter evasion class 101:-
http://%0aalert(1)
October 14th, 2009 at 12:58 pm
yawnmoth: Nice, I couldn’t find any information about this at all. But I also mentioned in my e-mail to RSnake that I did try to find information about this on the Internet but wasn’t able to find any. I just wanted to share it with the community.
Gareth Heyes: http://%0aalert(1) will try to resolve the following in FireFox: http://www.%0aalert(1).com/ version 3.0.14 and most likely also the newest version, which browser are you using?
October 15th, 2009 at 12:10 am
@MaXe
%0a is a new line, should work in any browser, if you want a IE specific example this is better:-
//@cc_on alert(/I love it/)
October 15th, 2009 at 2:26 pm
from yawnmoth’s link:
Vendor B: (nameless)
Vendor Notified: 12 May 2005
Acknowledged: 12 May 2005
Responded: 26 May 2005 (Deemed a non-issue)
how much do you want to bet that vbulletin is vendor b?
October 16th, 2009 at 2:22 am
um Gareth, it’s not the %0a thing, but more the bit where you forgot to specify the javascript: part in the URI that prevents it from working in most (if not all?) browsers.
October 16th, 2009 at 7:34 am
I agree with you MaXe, that’s new in your little world.
In the real world, we have sla.ckers haha
http://sla.ckers.org/forum/read.php?24,28643
Greetz!!
October 20th, 2009 at 5:15 am
@kaes
Yes I know. My point was that http://%0aalert(1) is executing as javascript hence filter evasion 101. Jeez I give up.
October 20th, 2009 at 7:48 am
@Gareth - I think the part that’s confusing this is that you keep typing “http” instead of “javascript” in your examples. As you well know http isn’t going to render anything as JavaScript. s/http/javascript/ and I think this discussion is over.
October 22nd, 2009 at 4:16 am
@RSnake
haha no that’s my point try executing (in javascript):-
http://%aalert(1)