1

用户输入的 unicode 是否存在任何真正的危险，而不是由用户代理/浏览器等处理？

显然，从服务器到客户端，存在真正的欺骗威胁，但我试图弄清楚在处理 unicode 输入时我应该注意哪些具体的“攻击”（如果有的话）或不满。

这个问题与语言无关，但我提出这个问题时考虑到对 GWT 应用程序的安全影响。

4

2 回答 2

5

任何用户输入的最大危险是在具有“特殊字符”的上下文中使用该输入。即，天真地将其连接到 SQL 查询中或将其输出到 HTML 中。如果您的应用程序的部分行为是由字符串（如 SQL 查询或 HTML 页面）控制的，并且用户可以控制这些字符串并可以注入自己的命令，那将是危险的。

不过，在这方面，Unicode 与其他编码相比并没有什么特别之处。您的环境中的特殊字符定义明确，您需要做的就是转义、过滤或清理任何用户输入，以便将这些特殊字符呈现为非特殊字符。对于任何其他编码，您也需要这样做。您需要注意您的转义/过滤/清理功能知道正确的编码，以便他们可以正常工作。

除此之外，Unicode 编码的文本只是文本。当您对其中包含的任何特殊字符进行中性处理并正确处理编码时，仅文本就没有危险。除了您的用户 sbuıɥʇ pɹıǝʍ buıʇıɹʍ 或出于某些特定目的利用相似字符之外，但这不再是普遍的危险。

于 2012-04-26T11:20:35.120 回答
4

我可以想到用户控制的 unicode 字符串的几个问题：

  1. 有多种方法可以在 unicode 中表示等效字符串。例如ä，可以表示为单个代码点，或者a后面跟一个组合¨. Unicode 规范化有助于解决大多数这些问题。
  2. 有些字符允许奇怪的插入符号移动。我听说过一个聊天，您可以将自己的消息放在其他人的消息之上。这让他们因为说不恰当的话而被禁止，因为管理员没有意识到谁实际发送了所述消息。
  3. 有相似的字符。例如，有一些俄语或希腊语字符在光学上与它们的 ASCII 等效字符没有区别。字符串应该唯一标识某些东西是非常有问题的。例如用户名或域。类似于经典的lvsI问题，除了更糟。
  4. 使用 UTF-8 和 UTF-16，在代码点中间拆分字符串可能会导致一些问题。
  5. 对字符串的某些操作可能会意外更改其长度。例如，将字符串大写可能会使其更长。

可能还有更多问题，我当然不是 unicode 专家

于 2012-04-26T11:16:43.390 回答