CodeIgniter - 为什么使用xss_clean

xss_clean（）是广泛的，也是愚蠢的。此函数的 90% 不执行任何操作来阻止 XSS。比如找词，但不是。没有黑客会在他们的漏洞利用中使用，他们将用XSS劫持cookie或读取CSRF令牌来制作XHR。alertdocument.cookiealert

但是，运行或使用它是多余的。修复问题但失败的情况如下：htmlentities()htmlspecialchars()xss_clean()htmlentities($text, ENT_COMPAT, 'UTF-8')

<?php
print "<img src='$var'>";
?>

一个简单的 poc 是：

http：//localhost/xss.php？var=http：//domain/some_image.gif'%20onload=alert（/xss/）

这会将事件处理程序添加到图像标记。停止这种形式的XSS的方法正在或在这种情况下也会阻止这种情况。onload=htmlspecialchars($var,ENT_QUOTES);xss_clean()

但是，引用xss_clean（）文档：

当然，没有什么是100%万无一失的，但我无法让任何东西通过过滤。

话虽如此，XSS不是.例如，此函数无法考虑变量已在标记或事件处理程序中。它也不会阻止基于DOM的XSS。您需要考虑如何使用数据才能使用最佳功能。根据输入筛选所有数据是一种不好的做法。它不仅不安全，而且还会损坏数据，从而使比较变得困难。output probleminput problem<script>

在你的情况下，“更严格的方法很好，重量更轻”。CodeIgniter开发人员打算为不同的用例xss_clean（），“一个允许'安全'HTML标签的评论系统或论坛”。这在文档中没有明确说明，其中显示了应用于用户名字段xss_clean。

还有另一个原因永远不要使用xss_clean（），到目前为止，StackOverflow上还没有突出显示。xss_clean（）在2011年和2012年被打破，不可能完全修复。至少没有完全的重新设计，这并没有发生。目前，它仍然容易受到这样的字符串的攻击：

<a href="j&#x26;#x41;vascript:alert%252831337%2529">Hello</a>

xss_clean（） 的当前实现首先有效地将 urldecode（） 和 html_entity_decode（） 应用于整个字符串。这是必需的，因此它可以对诸如“javascript：”之类的东西使用天真的检查。最后，它返回解码的字符串。

攻击者可以简单地对其漏洞进行两次编码。它将被xss_clean（）解码一次，并作为干净传递。然后，您就有了一个单独编码的漏洞利用，可以在浏览器中执行。

我称这些检查“幼稚”且无法修复，因为它们在很大程度上依赖于正则表达式。HTML不是一种常规语言。您需要一个更强大的解析器来匹配浏览器中的解析器;xss_clean（）没有这样的东西。也许有可能将HTML的子集列入白名单，该子集使用正则表达式干净利落地进行lex。但是，当前的xss_clean（）在很大程度上是一个黑名单。