XSS Me Warnings - real XSS issues?

2019-04-02 19:22发布

问题:

I've been using the free Firefox extension XSS Me from Security Compass to test for XSS problems. However, using what I understand to be safe filtering, XSS me still reports warnings. Are these accurate warnings or spurious?

Using the code below as a testcase:

<form method="post" action="">
<input type="text" name="param" value="<?php echo htmlentities($_POST['param'])?>">
<input type="submit">
</form>
<?php echo htmlentities($_POST['param'])?>

I run some nasties by hand but none of them are executed in the browser, and using Charles debugging proxy I can see that the response is encoded as expected.

However, XSS Me reports a number of warnings, as if it can see the unencoded string in the HTML source: alt text http://img696.imageshack.us/img696/8850/xss.png

Looking in Charles at the same time, I can see the strings are encoded and should be safe e.g. &lt;IMG SRC=&quot;jav ascript:document.vulnerable=true;&quot;&gt;

  • Is there a vulnerability I haven't fixed?
  • Are these rogue warning messages?
  • And if so, is another Firefox extension (Firebug?) conflicting with XSS Me?

回答1:

I work at Security Compass and am the lead developer for the Exploit Me tools.

You're right that XSS Me is reporting a warning because these attack strings seem (to XSS Me) to have come back from the server completely unencoded. Another parser/JavaScript engine (like IE 6/7/8, Safari, or Chrome) might execute this code even though Firefox's parser and JavaScript engine don't.

XSS Me submits two requests:

  • One request where we detect exploitation using FireFox's JavaScript engine, which we call "errors"
  • A second request where we detect exploitation by simply grepping for the attack string in the HTML response page

The warning you're getting is caused by this second request.

I can help you get to the root cause of this issue if you can do the following:

  1. Use packet sniffing software (i.e. Wireshark http://www.wireshark.org/) to detect the attack string rather than Charles. Sometimes proxies have a way of modifying or otherwise altering requests

  2. In Firefox, can you go to tools->addons and disable all the extensions except XSS Me? That way you can be sure no other extension is changing the response (or request) before it gets to XSS Me.

  3. View the source of the response page in Firefox to see if the unencoded string appears

If you'd like to send me an email (tom@securitycompass.com) with those results I'd be happy to help figure this out. If it's a bug in XSS Me (which I certainly hope not) then I can patch it and get a new build out.

Thanks,

Tom



回答2:

I am pretty sure this is a false positive. I think you should get a better xss testing tool. Acuentix has a very good and free xss scanner: http://www.acunetix.com/cross-site-scripting/scanner.htm . Wapiti and w3af are open source and are also great scanners.

In php the best xss filter is:

htmlspeicalchars($_POST['param'],ENT_QUTOES);

The reason why you also have to decode quotes is becuase you don't need <> to exploit some xss. for instance this is vulnerable to xss:

print('<A HREF="http://www.xssed.com/'.htmlspecialchars($_REQUEST[xss]).'">link</a>');

You don't need <> to execute javascript in this case because you can use onmouseover, here is an example attack:

$_REQUEST[xss]='" onMouseOver="alert(/xss/)"';

the ENT_QUOTES takes care of the double quotes.



回答3:

If the field isn't suppose to have any HTML in it, you might want to try something like strip_tags($strings). It will strip out (most) HTML tags from the string.

I say most because I believe it isn't perfect, and as other people will tell you, HTML parsers are probably best for stripping out HTML. But it should be sufficent in most cases.



回答4:

I' m testing it at my server and looks like a bug in the extension. I don't believe that any other extension is making conflicts with the "XSS ME" extension.

BTW, with htmlentities you don't cover all the possibilities to insert XSS, so consider using some kind of anti XSS library :)