php CodeIgniter - 为什么使用 xss_clean
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5337143/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
CodeIgniter - why use xss_clean
提问by Dan Searle
if I'm sanitizing my DB inserts, and also escaping the HTML I write with htmlentities($text, ENT_COMPAT, 'UTF-8')- is there any point to also filtering the inputs with xss_clean? What other benefits does it give?
如果我正在清理我的数据库插入，并且还转义了我编写的 HTML htmlentities($text, ENT_COMPAT, 'UTF-8')- 是否还有必要使用 xss_clean 过滤输入？它还有什么其他好处？
回答by rook
xss_clean()is extensive, and also silly. 90% of this function does nothing to prevent xss. Such as looking for the word alertbut not document.cookie. No hacker is going to use alertin their exploit, they are going to hiHyman the cookie with xss or read a CSRF token to make an XHR.
xss_clean()很广泛，也很傻。这个函数的 90% 对防止 xss 没有任何作用。如找字alert却没有document.cookie。没有黑客会alert在他们的漏洞利用中使用，他们会用 xss 劫持 cookie 或读取 CSRF 令牌来制作 XHR。
However running htmlentities()or htmlspecialchars()with it is redundant. A case where xss_clean()fixes the issue and htmlentities($text, ENT_COMPAT, 'UTF-8')fails is the following:
然而，运行htmlentities()或htmlspecialchars()使用它是多余的。其中A的情况下xss_clean()解决这一问题，htmlentities($text, ENT_COMPAT, 'UTF-8')失败如下：
<?php
print "<img src='$var'>";
?>
A simple poc is:
一个简单的 poc 是：
http://localhost/xss.php?var=http://domain/some_image.gif'%20onload=alert(/xss/)
http://localhost/xss.php?var=http://domain/some_image.gif'%20onload=alert(/xss/)
This will add the onload=event handler to the image tag. A method of stopping this form of xss is htmlspecialchars($var,ENT_QUOTES);or in this case xss_clean()will also prevent this.
这会将onload=事件处理程序添加到图像标记。停止这种形式的 xss 的方法是htmlspecialchars($var,ENT_QUOTES);或者在这种情况下xss_clean()也可以防止这种情况。
However, quoting from the xss_clean() documentation:
但是，引用 xss_clean() 文档：
Nothing is ever 100% foolproof, of course, but I haven't been able to get anything passed the filter.
当然，没有什么是 100% 万无一失的，但我一直无法通过过滤器。
That being said, XSS is an output problemnotan input problem. For instance this function cannot take into account that the variable is already within a <script>tag or event handler. It also doesn't stop DOM Based XSS. You need to take into consideration how you are using the datain order to use the best function. Filtering all data on input is a bad practice. Not only is it insecure but it also corrupts data which can make comparisons difficult.
话虽这么说，XSS是output problem不是一个input problem。例如，此函数无法考虑变量已在<script>标记或事件处理程序中。它也不会阻止基于 DOM 的 XSS。您需要考虑如何使用数据才能使用最佳功能。过滤输入的所有数据是一种不好的做法。它不仅不安全，而且还会破坏数据，使比较变得困难。
回答by sourcejedi
In your case, "stricter methods are fine, and lighter weight". CodeIgniter developers intend xss_clean() for a different use case, "a commenting system or forum that allows 'safe' HTML tags". This isn't clear from the documentation, where xss_clean is shown applied to a username field.
在你的情况下，“更严格的方法很好，重量更轻”。CodeIgniter 开发人员打算将 xss_clean() 用于不同的用例，“允许'安全'HTML 标签的评论系统或论坛”。这在文档中并不清楚，其中 xss_clean 显示为应用于用户名字段。
There's another reason to never use xss_clean(), that hasn't been highlighted on stackoverflow so far. xss_clean() was broken during 2011and 2012, and it's impossible to fix completely. At least without a complete redesign, which didn't happen. At the moment, it's still vulnerable to strings like this:
还有另一个永远不要使用 xss_clean() 的原因，到目前为止还没有在 stackoverflow 上突出显示。xss_clean() 在2011和2012期间被破坏，并且不可能完全修复。至少没有完全重新设计，这没有发生。 目前，它仍然容易受到这样的字符串的影响：
<a href="j&#x41;vascript:alert%252831337%2529">Hello</a>
The current implementation of xss_clean() starts by effectively applying urldecode() and html_entity_decode() to the entire string. This is needed so it can use a naive check for things like "javascript:". At the end, it returns the decoded string.
xss_clean() 的当前实现首先将 urldecode() 和 html_entity_decode() 有效地应用于整个字符串。这是必需的，因此它可以对诸如“javascript：”之类的东西进行简单的检查。最后，它返回解码后的 string。
An attacker can simply encode their exploit twice. It will be decoded once by xss_clean(), and pass as clean. You then have a singly-encoded exploit, ready for execution in the browser.
攻击者可以简单地对他们的漏洞进行两次编码。它将被 xss_clean() 解码一次，并作为干净传递。然后，您就有了一个单独编码的漏洞利用程序，可以在浏览器中执行。
I call these checks "naive" and unfixable because they're largely reliant on regular expressions. HTML is not a regular language. You need a more powerful parser to match the one in the browser; xss_clean() doesn't have anything like that. Maybe it's possible to whitelist a subset of HTML, which lexes cleanly with regular expressions. However, the current xss_clean() is very much a blacklist.
我称这些检查为“幼稚”且无法修复，因为它们在很大程度上依赖于正则表达式。HTML 不是常规语言。 您需要一个更强大的解析器来匹配浏览器中的解析器；xss_clean() 没有这样的东西。也许可以将 HTML 的一个子集列入白名单，该子集使用正则表达式清晰地进行词法分析。但是，当前的 xss_clean() 是一个黑名单。
回答by Anthony
I would recommend using http://htmlpurifier.org/for doing XSS purification. I'm working on extending my CodeIgniter Input class to start leveraging it.
我建议使用http://htmlpurifier.org/进行 XSS 净化。我正在扩展我的 CodeIgniter Input 类以开始利用它。
回答by jondavidjohn
Yes you should still be using it, I generally make it a rule to use it at least on public facing input, meaning any input that anyone can access and submit to.
是的，您仍然应该使用它，我通常规定至少在面向公众的输入中使用它，这意味着任何人都可以访问和提交的任何输入。
Generally sanitizing the input for DB queries seems like a side-effect as the true purpose of the function is to prevent Cross-site Scripting Attacks.
通常清理数据库查询的输入似乎是一种副作用，因为该功能的真正目的是防止跨站点脚本攻击。
I'm not going to get into the nitty gritty details of every step xss_clean takes, but i will tell you it does more than the few steps you mentioned, I've pastied the source of the xss_clean functionso you can look yourself, it is fully commented.
我不会深入了解 xss_clean 所采取的每一步的具体细节，但我会告诉你它比你提到的几个步骤做得更多，我已经粘贴了 xss_clean 函数的源代码，所以你可以看看自己，它已完全评论。
回答by shankar kumar
If you want the filter to run automatically every time it encounters POST or COOKIE data you can enable it by opening your application/config/config.php file and setting this: $config['global_xss_filtering'] = TRUE;
如果您希望过滤器在每次遇到 POST 或 COOKIE 数据时自动运行，您可以通过打开 application/config/config.php 文件并设置以下内容来启用它： $config['global_xss_filtering'] = TRUE;
You can enable csrf protection by opening your application/config/config.php file and setting this: $config['csrf_protection'] = TRUE;
您可以通过打开 application/config/config.php 文件并设置以下内容来启用 csrf 保护： $config['csrf_protection'] = TRUE;
for more details, please see on following link.
有关更多详细信息，请参阅以下链接。
https://ellislab.com/codeigniter/user-guide/libraries/security.html
https://ellislab.com/codeigniter/user-guide/libraries/security.html
