撇号在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块中,它们只是字符数据并且是无害的.在SQL块中,它们是无害的(如果数据库共享相同的代码页).对我们来说问题是因为我们在数据库中使用的代码页是不同的,数据库中的插入过程涉及将这些"不可打印"的字符转换为"已知的等价物"(在这种情况下是"坏")和"未知等价物"(将其呈现为"？").这完全是盲目的我们,我对MS没有进一步构建其HttpUtility编码功能感到有些失望.

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

Answer 1

这听起来像是 DBMS 内的存储使用非 unicode 列类型，而 .net 使用 unicode。

您可以在 .net 中首先将 unicode 转换为 dbms 的排序规则，然后返回 unicode 以删除应用程序级别的任何不支持的字符，而不是将其留给 dbms/连接器。

var encoding = Encoding.GetEncoding("Latin1") //this should be matched to the column's collation
foo = encoding.GetString (encoding.GetBytes (foo)); // couldn't see a more efficient way to do this.

尽管如前所述，理想情况下您会将实际字符存储在 DBMS 中，并将编码留给表示步骤。其中您将尝试以这样的方式设置框架，您不会忘记对字符串数据进行编码，例如asp.net 4使用<%: %>JSON，使用JSON.Net而不是字符串连接，对于XML XLINQ等。