我一直在使用 Security Compass 的免费 Firefox 扩展 XSS Me测试 XSS 问题。然而，使用我所理解的安全过滤，XSS me 仍然会报告警告。这些警告是准确的还是虚假的？
使用下面的代码作为测试用例：
<form method="post" action="">
<input type="text" name="param" value="<?php echo htmlentities($_POST['param'])?>">
<input type="submit">
</form>
<?php echo htmlentities($_POST['param'])?>
我手动运行了一些令人讨厌的代码，但它们都没有在浏览器中执行，并使用 Charles 调试代理< /a> 我可以看到响应已按预期进行编码。
然而，XSS Me 报告了许多警告，就好像它可以在 HTML 源代码中看到未编码的字符串一样：
替代文本 http://img696.imageshack.us/img696/8850/xss.png< /a>
同时查看 Charles，我可以看到字符串已编码并且应该是安全的，例如 
- 是否存在我尚未修复的漏洞？
- 这些是流氓警告信息吗？
- 如果是这样，另一个 Firefox 扩展（Firebug？）是否与 XSS Me 冲突？
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. <IMG SRC="jav ascript:document.vulnerable=true;">
- 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?
发布评论
评论（4）
我在 Security Compass 工作，是 Exploit Me 工具的首席开发人员。
您是对的，XSS Me 报告了警告，因为这些攻击字符串（对 XSS Me 来说）似乎从服务器返回时完全未编码。另一个解析器/JavaScript 引擎（如 IE 6/7/8、Safari 或 Chrome）可能会执行此代码，即使 Firefox 的解析器和 JavaScript 引擎不会执行。
XSS Me 提交两个请求：
您收到的警告是由于通过第二个请求。
如果您可以执行以下操作，我可以帮助您找到此问题的根本原因：
使用数据包嗅探软件（即 Wireshark http://www.wireshark.org/）来检测攻击字符串而不是 Charles。有时代理可以修改或以其他方式更改请求
在 Firefox 中，您可以转到工具->插件并禁用除 XSS Me 之外的所有扩展吗？这样您就可以确保在响应（或请求）到达 XSS Me 之前没有其他扩展程序正在更改响应（或请求）。
在 Firefox 中查看响应页面的源代码，看看是否出现未编码的字符串
如果您想向我发送电子邮件 ( [email protected]）与这些结果我很乐意帮助计算这个出来了。如果这是 XSS Me 中的错误（我当然希望不是），那么我可以修补它并获得新的版本。
谢谢，
汤姆
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:
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:
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
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.
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
我很确定这是误报。我认为你应该得到一个更好的 xss 测试工具。 Acuentix 有一个非常好的免费 xss 扫描器：http://www.acunetix。 com/cross-site-scripting/scanner.htm 。 Wapiti 和 w3af 是开源的，也是很棒的扫描仪。
在 php 中，最好的 xss 过滤器是：
你还必须解码引号的原因是因为你不需要 <>利用某些 xss。例如，这很容易受到 XSS 攻击：
您不需要 <>在这种情况下执行 javascript 因为你可以使用
onmouseover，这是一个示例攻击：
ENT_QUOTES 负责处理双引号。
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:
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:
You don't need <> to execute javascript in this case because you can use
onmouseover, here is an example attack:
the ENT_QUOTES takes care of the double quotes.
如果该字段中不包含任何 HTML，您可能需要尝试类似
strip_tags($strings)的方法。它会从字符串中去除（大多数）HTML 标签。我说“大多数”是因为我相信它并不完美，而且正如其他人会告诉您的那样，HTML 解析器可能最适合剥离 HTML。但在大多数情况下应该足够了。
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.
我正在我的服务器上测试它，看起来像是扩展中的一个错误。我不认为任何其他扩展与“XSS ME”扩展发生冲突。
顺便说一句，对于 htmlentities，您无法涵盖插入 XSS 的所有可能性，因此请考虑使用某种反 XSS 库:)
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 :)