views:

601

answers:

4

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

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?
A: 

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.

Chacha102
Thanks Chacha102. However, if the HTML is escaped/sanitized correctly then it shouldn't be a vulnerability. Does encoding the HTML as shown in the original post leave open attack vectors?
PeterB
he is already doing htmlspecialchars which is a lot better htan strip_tags because it doesn't remove data, instead it just makes it human readable. I'd vote you down more if i could.
Rook
Before downvoting, have you understood what he said? 'IF THE FIELD ISN'T SUPPOST TO HAVE ANY HTML'.. whats wrong with it? it is perfect.Since noone is named `Sm<em>ith</em>`, if you dont expect html tags in, for example, name field, why dont kill all the tags in it?
DaNieL
Because DaNieL, that seems tangential to my question. Which is whether this is safe or not. Removing tags would make it safer, but there are many situations where that's not the wanted behaviour.
PeterB
@PeterB, You asked is there anything you are missing. I provided something you might be missing based on what type of data you are outputting.
Chacha102
A: 

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 :)

Pedro Laguna
+1  A: 

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]).'"&gt;link&lt;/a&gt;');

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.

Rook
it is indeed trivial to insert additional attributes. See the OWASP XSS prevention cheat sheet http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
Cheekysoft
even this use of htmlspecialchars can be still vulnerable to some multi-byte character attacks
Cheekysoft
Dude, you have to give an example of a multi-byte attack that can be bypassed. I am VERY interested in that method.
Rook
A: 

Hi Peter B,

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 ([email protected]) 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

Mystic
Thanks, I just need to get XSS Me installed on Firefox 3.6 - any chance of a compatible release?
PeterB
We hope to get an "experimental" (read: unreviewed) release up on addons.mozilla.org this week. I'll post a link when it's up :-).The review process should be quick but isn't something we control.
Mystic