On Encapsulation
I got an email from unsticky the other day that I thought was fairly interesting because it shows one of the rather obscure ways to get outside of encapsulation when certain characters (in his case the semicolon) are disallowed to attempt to prevent XSS. Here’s his email:
I know you’ve discussed ';alert('xss');// and the like, but when I’ve been trolling some sites for xss vulns, I’ve found that a few of them escape semi-colons, but the apostrophes, slashes, or parenthesis. To compensate, I’ve been using a plus instead of the first semi-colon and leaving out the second one all together, leaving me with '+alert('xss')//. I don’t know if it’s worth mentioning on your site or adding to the xss cheat sheet, but it’s sort of a ‘new concept’ that I don’t believe has been brung up before. Since most of the time, for the sites I’m pestering, the injection point is into a variable, you can add an alert() to a string. The alert() will be excuted when your browser tries to add the return value to the variable.
For example: var str=''+alert('xss')//;doSomething(str);
This is a variant of the escaping JavaScript escapes cross site scripting vector. The major difference is that instead of ending the assignment and starting a new line he is allowing his vector to fire within the confines of the variable assignment. The function (in this case alert()) returns true since it fires and the JavaScript doesn’t fail. The end slashes are actually not required as you could continue the assignment with something like, '+alert('xss')+' which would have the same effect.
There are other weird things like this that I’ve found that cause some minor issues when you are trying to allow some sort of function to fire. A number of times I’ve had to jump out of comment tags that are actually encapsulating the JavaScript. That’s another weird situation that requires no quotes, despite what most people think. Simply by ending the comment tag, then by ending the script (regardless if you are encapsulated this will still work) you can jump out of it.
Sometimes I think encapsulation is just silly. It’s nearly useless at preventing XSS unless everything is URL encoded or all special characters have been removed.
November 22nd, 2006 at 1:40 pm
interesting, i hadn’t thought to just use + and append it. that being said, i’ve looked at injnections in many many sites .. and if semicolons aren’t working, it’s just because they need to be hex encoded to %3B because it’s not automatic (the same way + isn’t automatic) .. i’m sure there’s a couple sites among the 100million out there, that don’t allow ; nor %3B - but i can’t remember seeing any
still a good technique, and worth remembering ^^
November 23rd, 2006 at 2:23 am
i was on a site once that replaced ( and ) with their html brothers.
i found a way to inject script, but there wasnt a lot i could do, really.
all i could have done would be hoping that another script was alerting or document.writing a value that was defined on top of the page (before my injected script)
so i could add x=’XSS’;
but no, no such thing.
i find this filter intresting and i dont really see a way around it…
November 23rd, 2006 at 10:46 am
I think I’d have to see the example to make a determination one way or another, but from what you’re saying that does sound like a pretty effective filter if the only place you can inject is within the JavaScript itself. But I’m also assuming you couldn’t use angle brackets and end quotes. Othewise you could just end the script at that point and start your own script right after it. Parens wouldn’t be required at that point because you could simply encode it within whatever context you injected the XSS after it. Anyway, tough to say without seeing the example.