c# - 撇号通过 C# 中的过滤器

Question

我真的很抱歉这样做，但这个问题代表我工作的网站上可能存在可利用的安全问题，因此我将使用新帐户发布此问题。

我们有一个接受用户评论的脚本(所有评论都是英文的)。我们在两年内积累了大约 3,000,000 条评论。我正在检查评论表是否有任何恶意行为的迹象，这次我扫描了撇号。在所有情况下都应该将其转换为 HTML 实体 (')，但我发现了 18 条记录(共 300 万条)，该字符在其中幸存下来。真正让我头疼的是，在这 18 条评论的其中一条中，一个撇号实际上被成功转换——另一个幸存下来。

这向我表明我们可能存在 XSS 漏洞。

我的理论是，用户在使用非西方代码页的计算机系统上点击页面，并且他们的浏览器忽略了我们页面的 utf-8 字符集规范，他/她的输入没有得到转换为服务器的本地代码页，直到它到达数据库(因此 C# 无法将字符识别为撇号，因此无法转换它，但数据库会在它尝试将其写入 LATIN1 表时进行转换)。但这完全是猜测。

有没有人以前遇到过这个问题或者知道这是怎么回事？

更重要的是，有人知道如何测试我的脚本吗？移动到 HttpUtility 可能会解决这个问题，但直到我知道这是怎么发生的，我才能知道问题是否已解决。我需要能够对此进行测试，以了解我们的解决方案是否有效。

编辑

哇。已经 20 分了，所以我可以编辑我的问题。

我在我的一条评论中提到，我发现有几个字符似乎有问题。它们包括:0x2019、0x02bc、0x02bb、0x02ee、0x055a、0xa78c。这些直接通过我们的过滤器。不幸的是，它们也直接通过所有 HttpUtility 编码方法。但是一旦它们被插入到数据库中，它们就会被转换成一个实际的撇号或一个“？”。

回顾一下，我认为问题在于这些字符本身并不构成威胁，因此 HttpUtility 没有理由转换它们。在一段 Javascript 中，它们是无害的。在 HTML block 中，它们只是字符数据并且是无害的。在 SQL block 中它们是无害的(如果数据库共享相同的代码页)。我们的问题是因为我们在数据库中使用的代码页不同，数据库中的插入过程涉及将这些“不可打印”字符转换为“已知等价物”(在本例中为“坏”)和“未知等价物”(呈现为“？”)。这完全让我们措手不及，我对 MS 没有在他们的 HttpUtility 编码函数中构建更多内容感到有点失望。

我认为解决方案是更改受影响表的排序规则。但是，如果其他人有更好的主意，请在下面发布。

Answer 1

恕我直言，您在错误的地方过滤。数据库应包含用户输入的实际字符。您应该将 HTML 的转义留给表示层，它更清楚如何去做。