轻量级和安全的方式来防止XSS - Lightweight and secure way to prevent XSS

当前项目中的每个文本字段都只是没有ubb或html标记的普通平面文本。然而，它必须是unicode，所以我想一个包含支持的字符的数组不是最佳的。

我知道有很多专门的类用于xss检测，但是不是所有的xs都包括这两个字符：

字符<

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

炭；

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

如果我检查所有用户输入（get，post，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

试图在输入中全面禁止"邪恶"字符是没有意义的，更不用说试图禁止以各种不同形式编码的版本了。你会出现假阳性并阻止有效输入，同时不能保护自己免受各种可能形式的注射孔的影响。我不确定你试图通过禁止Ow==而不是&或"来防止什么样的攻击。

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

等等，对于你可能遇到的每一种不同的逃跑方式。重点是，这是一个输出级函数，当您将文本放入新上下文时，必须使用适合您所拥有上下文类型的正确函数来应用它。这不是在输入阶段只做一次就可以忘记的事情，因为在输入阶段，你不知道你处理的文本最终是SQL文本、HTML页面、JavaScript字符串文本、URL参数还是什么。

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

但是，不是所有的xs都包括这两个字符：（…）[<和&]

不，他们没有。。。正如你链接到的备忘单所暗示的那样。例如（MG嵌入式命令第二部分）

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

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

让我们说它更简单。您仍然需要担心SQL注入、XSS（它的数量较少，但它仍然可能存在于最轻微的错误转义数据中）和CSRF。