我们有一个脚本接收用户评论(所有评论都是英文).两年来,我们已经收集了大约300万条评论.我正在检查评论表中有任何恶意行为的迹象,这次我扫描了撇号.在所有情况下,这应该已经转换为HTML实体('),但是我发现这个角色幸存下来的18个记录(300万个).真正打破我头脑的事情是,在这18条评论中,其中一条撇号实际上已成功转换 – 另一条挽救了.

这表明我们有可能的XSS漏洞.

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

有没有人以前遇到过或知道发生了什么？

更重要的是,有没有人知道我如何测试我的脚本？移动到HttpUtility可能会修复这种情况,但是直到我知道这是怎么回事,我不知道问题是固定的.我需要能够测试这个来了解我们的解决方案.

编辑

哇.已经在20分,所以我可以编辑我的问题.

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

在审查中,我认为问题是这些角色本身并不构成威胁,所以HttpUtility没有理由转换它们.在一个Javascript框架中,它们是无害的.在一块HTML中,它们只是字符数据,是无害的.而在一块sql中,它们是无害的(如果数据库共享相同的代码页).我们的问题是,因为我们在数据库中使用的代码页是不同的,数据库中的插入过程涉及将这些“不可打印”字符转换为“已知等效物”(在这种情况下为“不良”)和“未知等价物“(将其呈现为”？“).这完全是盲目的我们,我有点失望的MS不建立更多的他们的HttpUtility编码功能.

我认为解决方案是更改受影响的表的排序规则.但如果其他人有更好的想法,请在下面发贴.