问如何防范Unicode安全漏洞

EN

您正在谈论的内容被称为同形文字攻击。

这里有一个Unicode here的"confusables“列表，也可以看看this。应该有基于这些或其他数据库的库。this one就是这样一个库，您可以在Java或Javascript中使用它。对于其他语言，也必须存在相同的情况，或者您可以编写一种。

我认为重要的是不要有自己的数据库--库或服务很容易建立在好的数据之上。

至于你是否应该过滤掉看起来相似的用户名--我想这要视情况而定。如果用户有兴趣尝试伪造对方的用户名，也许是这样的。对于许多其他类型的数据，这样做可能没有意义。除了你应该用你的数据点评估你的应用程序中的风险之外，我认为没有通用的最佳实践。

还有一种不同的方法来解决不同的问题，但是，如果您的正则表达式支持\w，那么通常适用于Unicode输入验证的是正则表达式中的Unicode word字符。在这样的引擎中，\w应该匹配word字符的所有Unicode类，即。任何语言的字母、修饰语和连接符，但不包括其他字符(无特殊字符)。这不能防止同形文字攻击，但可以防止某些注入，同时保持您的应用程序对Unicode友好。

当您有一个已知安全值的白名单并排除所有其他值时，所有清理效果最好。

ASCII就是这样一组字符。

这可以通过各种方式来解决，但是每一种方式都可能增加误报的数量，从而导致合法用户的烦恼。而且，它们都不能100%适用于所有情况(即使组合在一起)。他们只会添加一个额外的层。

一种方法是让表中的字符看起来相似，并检查是否存在重复的名称。在许多情况下，“看起来相似”的意思是主观的，所以建立这样的列表可能很棘手。此方法在某些情况下可能会产生误报。

此外，颠倒某些字母的顺序可能会欺骗许多用户。可以使用Jaro-Winkler和Levenshtein distance等算法来检查变形图或非常相似的名称(即，检查类似的用户名/公司名称是否已经存在)。然而，有时这可能是由于某些单词在某些地区的拼写不同(例如，‘center’与‘center’的拼写不同)，或者某些公司的名称可能故意包含字谜。这种方法可能会进一步增加误报的数量。

此外，正如Jonathan提到的，杀毒也是一种很好的方法，但是它可能不会防止字形变化，并会给想要使用某些特殊字符的合法用户带来问题。

正如OP还提到的，特殊字符也可以被剥离。名称的其他部分可能也需要删除，例如常用名称，如“inc.”、“.com”等。

最后，名称可以限制为只包含一种语言的字符，而不是来自不同语言的字符的混合(更宽松的版本可能不允许在同一个词中混合字符-而允许使用空格分隔)。限制使用首字母大写和其他字母的小写可以进一步改进此方法，因为在使用某些字体时，某些小写字母(如'l')可能看起来像大写字母(如'I')。排除使用某些符号(如'|')将进一步加强这一方法。此解决方案将增加某些用户的烦恼，这些用户将无法使用某些名称。

也可以使用上述一些/所有方法的组合。方法的选择以及如何准确地应用它们(例如，您可以选择禁止类似的名称，或者在名称相似的情况下要求版主批准，或者不采取任何操作，而只是警告版主/管理员)取决于您试图解决的场景。