Cenzic 232 Patent
Paid Advertising
web application security lab

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

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

11 Responses to “JavaScript Protocol Comment Newline Injection”

  1. yawnmoth Says:

    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.

  2. Gareth Heyes Says:

    It’s not big or clever it’s obvious. Sorry to be a ball breaker but you know I can’t help it

  3. Gareth Heyes Says:

    Filter evasion class 101:-

    http://%0aalert(1)

  4. MaXe Says:

    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?

  5. Gareth Heyes Says:

    @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/)

  6. commander keen Says:

    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?

  7. kaes Says:

    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.

  8. sirdarckcat Says:

    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

    :) Anyway, nice re-finding

    Greetz!!

  9. Gareth Heyes Says:

    @kaes

    Yes I know. My point was that http://%0aalert(1) is executing as javascript hence filter evasion 101. Jeez I give up.

  10. RSnake Says:

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

  11. Gareth Heyes Says:

    @RSnake

    haha no that’s my point try executing (in javascript):-

    http://%aalert(1)