Cenzic 232 Patent
Paid Advertising
web application security lab

XSS Scanning

I got an email from another lurker today that I thought was pretty interesting. He’s intending to build a scanner to do some self-pen testing on his own websites and wanted some guidance. He was stuck on one of the three big questions (the others are the calendar or infinite depth issue and the login state issue). His issue was how to know what is bad and what isn’t from a web application security scanning perspective.

1. Without going into to much detail, could you suggest some ways that I could intelligently check the responses to see if the given page is vulnerable to a particular attack. I’ve been able to parse the page, locate parameters that I want to try to attack, and build the POST/GET requests. But should I be doing something more than just checking for in tact javascript in the HTTP responses? It’s obviously very easy to tell when an alert box pops up in your browser window, but from a programming standpoint, do you have any suggestions for validating each attack?

That’s a very tricky question and depends on a few things - are you only interested in XSS or also CSRF or more? Second question, assuming it’s XSS is are you interested in HTML injection or JavaScript injection? Those answers might help you narrow down what you are looking for. Here’s what I mean. There’s basically two schools of thought used by the web application security scanning community. I gotta tell you, both of those concepts make me wince a little.

The first is “Anything that looks like HTML is probably bad.” If you assume that any HTML injection is bad, you are making false assumptions about what is deemed acceptable by that application. Maybe <BR> tags are okay, or even <XSS> tags are okay, but <IFRAME is not programmatically. Secondly, making that same assumption if you are only testing for HTML (because it would stand to reason that HTML is the only way to get JavaScript on a page) you are missing script injection (like the JSON issue Google had), weird encoding methods, blah blah blah. Also maybe they use a whitelist like <XSS> isn’t allowed since it’s not on a whitelist, but <IMG SRC=… is. Eesh! As I said, it makes me wince.

The second is, “If you can’t get it to render JavaScript, it’s not a valid attack.” Basically this is taking the super simple concept above and making it a thousand times more difficult. Basically this assumption is, unless the DOM is fired it’s not a valid attack vector. They use tools like spidermonkey to detect if the DOM is accessed by their injected script. Fantastic idea, tons of holes though. The primary issue I have with this is that the Firefox DOM acts nothing like the Internet Explorer DOM and vice versa when you are talking about XSS filter evasion. They’re kinda vaguely close with the most basic script injection but with anything weird? Forget it. My other big issue with this concept is that just because you injected a great string doesn’t mean you jumped out of the encapsulation properly. You might have just missed one more backslash or semicolon. Maybe trapping JavaScript errors gets you 95% the way there, but I still wouldn’t rely on it. It just makes me nervous.

Both of those ideas have their merits, and both their major pitfalls. The first is easier to code, certainly, but as I said, it’s missing a lot of granularity in the way JavaScript and HTML is parsed.

6 Responses to “XSS Scanning”

  1. Sven Vetsch / Disenchant Says:

    Hi RSnake,
    for a talk I’ll hold in exactly a week I also build some scripts in Javascript and in PHP. One part of my “XSS Toolbox” is also a small POC of an easy XSS vulnerability scanner. The scanner is working in two modes:

    1.) You set the URL where a webserver is running the file you’ll test and also a local copy of it on your machine. Then last but not least you can set the request-type (atm. only GET and POST are supported). Then you can start the scan. First it checks the local file for variable names and in a second step it tests the same variables for XSS on the webserver.

    2.) The second mode is nearly similar to the first in the way it works but has a significant difference. You don’t set the local file to the source file, for example because you’re going to do a blackbox testing, you only give the scanner a file in which you wrote down a list with often used variables. So in this way it’s more like a XSS bruteforce or guessing attack.

    As I said, it’s only a POC at the moment but I think it shows how it’s possible to build a webbased webapp scanner in an easy way :)

    PS: I’m looking forward to release my POC code after my talk next week.

    Regards,
    Disenchant

  2. RSnake Says:

    Thanks for writing Sven, I’d be interested in seeing the material you release. Let me know when/where you put it up.

  3. RSnake Says:

    What ever happend to that speech, Sven? It’s been more than a week, I was hoping to hear more about it.

  4. Sven Vetsch / Disenchant Says:

    I’m so sorry but i had much to do this week :(

    But if I say something, I’ll do it. So, I wrote some text to it and published the source :)

    Here you’ll find it:
    http://www.disenchant.ch/blog/xss-vulnerability-scanner/10

    PS: I’ve also some more scripts which are packed into a XSS-tool-kit but it’s not finished yet and so it’s not published.

    Regards,
    Sven / Disenchant

  5. RSnake Says:

    As always, when you get closer to publishing it, let me know. I’m always interested in checking out new code. Btw, what is the footer page you keep including into the script you wrote? Is it just fluff or is there importance to it?

  6. Sven Vetsch Says:

    As I said, I hadn’t much time and so I put directly my script online which I’m using for my XSS-Toolkit I’m working on and there’s a design part which is named footer.php but it’s not needed for using the script outside of my kit :)

    Regards,
    Sven