防止 XSS 的轻量级且安全的方法

Question

当前项目中的每个文本字段只是普通的平面文本，没有 ubb 或 html 标签。 但是它必须是 unicode，因此我认为包含受支持字符的数组并不是最佳选择。

我知道有很多专门用于 xss 检测的类，但是并非所有 xss 都包含这 2 个字符：

char <

<
%3C
&lt
&#60;
&60;
&#x3C;
PA==

字符；

;
%3B
&#x3B;
&#59
Ow==
&59;

如果我检查上面代码块中字符的所有用户输入（获取、发布、cookie），那么一切都应该是 100% 安全的？ 该项目不在 mysql 上运行，它使用 cassandra，因此 mysql 注入不应该成为问题。

我确信我忘记了什么，但我不知道是什么...... 或者，当用户输入是平面文本时，构建 100% 安全的应用程序真的那么容易吗？

编辑： 列表都有点长，在这里找到第一个字符： http://ha.ckers.org/xss.html

 <
    %3C
    &lt
    &lt;
    &LT
    &LT;
    &#60
    &#060
    &#0060
    &#00060
    &#000060
    &#0000060
    &#60;
    &#060;
    &#0060;
    &#00060;
    &#000060;
    &#0000060;
    &#x3c
    &#x03c
    &#x003c
    &#x0003c
    &#x00003c
    &#x000003c
    &#x3c;
    &#x03c;
    &#x003c;
    &#x0003c;
    &#x00003c;
    &#x000003c;
    &#X3c
    &#X03c
    &#X003c
    &#X0003c
    &#X00003c
    &#X000003c
    &#X3c;
    &#X03c;
    &#X003c;
    &#X0003c;
    &#X00003c;
    &#X000003c;
    &#x3C
    &#x03C
    &#x003C
    &#x0003C
    &#x00003C
    &#x000003C
    &#x3C;
    &#x03C;
    &#x003C;
    &#x0003C;
    &#x00003C;
    &#x000003C;
    &#X3C
    &#X03C
    &#X003C
    &#X0003C
    &#X00003C
    &#X000003C
    &#X3C;
    &#X03C;
    &#X003C;
    &#X0003C;
    &#X00003C;
    &#X000003C;
    \x3c
    \x3C
    \u003c
    \u003C

Answer 1

尝试全面禁止输入中的“邪恶”字符是没有意义的，尝试禁止以各种不同形式编码的版本更没有意义。您将误报并阻止有效输入，同时无法保护自己免受各种可能形式的注入孔的影响。我不确定您想通过禁止 Ow== 来防止哪种攻击
但不是 & 或 "。

停止 HTML 注入的正确方法是调用 htmlspecialchars()停止 URL 组件注入的任何文本字符串是对输出到 URL 的文本字符串调用 rawurlencode() 停止 SQL 注入的正确方法。就是调用相关的DB转义函数（例如 mysql_real_escape_chars()）对任何输出到 SQL 字符串文字的文本进行转义，

等等，对于您可能遇到的每个不同的转义，要点是，这是一个输出。当您将文本放入新的上下文中时，必须使用适合您所拥有的上下文类型的正确函数来应用 level 函数，这不是您可以在输入阶段执行一次然后忘记的事情，因为您不这样做。不知道在输入阶段，您正在处理的文本是否最终会出现在 SQL 文本、HTML 页面、JavaScript 字符串文本、URL 参数或其他内容中。

这并不是说输入阶段验证没有用；而是说输入阶段验证没有用。你会希望它确保提交的应该是数字的字段实际上看起来像数字，或者日期，或者其他什么。但输入验证并不能解决输出转义问题，例如导致大多数 XSS 的 HTML 注入问题。为了做到这一点，你必须禁止几乎所有的标点符号，这对用户来说是非常不利的。

Answer 2

但是，并非所有 xss 都包含这 2 个字符：(...) [<;和&]

不，他们不会...因为您链接到的备忘单将建议。例如（MG 嵌入式命令第二部分）

Redirect 302 /a.jpg http://victimsite.com/admin.asp&deleteuser

当用户输入是平面文本时，构建 100% 安全的应用程序真的那么容易吗？

假设它更简单。你仍然需要担心 SQL 注入、XSS（这种情况较少，但是 它仍然可能存在（即使是最轻微的未正确转义的数据）和 CSRF。