我刚刚回答了一个问题,答案提示AntiXss库以避免跨站点脚本.听起来很有意思,在阅读msdn博客时,它似乎只是提供了一个HtmlEncode()方法.但我已经使用了HttpUtility.HtmlEncode().
为什么我要在HttpUtility.HtmlEncode上使用AntiXss.HtmlEncode？
实际上,我不是第一个提出这个问题的人.事实上,Google 主要提出了一些 答案
白名单而不是黑名单方法
性能提升0.1ms
嗯,这很好,但这对我意味着什么？我不那么在乎为0.1ms的表现,我不觉得自己真的要下载并添加另一个库的依赖了,我已经拥有的功能.
是否存在AntiXss实现可以防止HttpUtility实施不会发生攻击的情况示例？
如果我继续使用HttpUtility实施,我是否有风险？怎么样这个"错误"？
我没有专门针对你的问题的答案,但我想指出白名单与黑名单的方法不仅仅是"好".这一点很重要.很重要.在安全方面,每件小事都很重要.请记住,使用跨站点脚本和跨站点请求伪造,即使您的站点没有显示敏感数据,黑客也可以通过注入javascript来感染您的站点并使用它来从其他站点获取敏感数据.所以做对是至关重要的.
OWASP指南指定使用白名单方法.PCI合规性指南也在编码标准中指明了这一点(因为它们引用了OWASP指南).
此外,较新版本的AntiXss库有一个很好的新功能:.GetSafeHtmlFragment(),它适用于您希望将HTML存储在数据库中并将其作为HTML显示给用户的情况.
另外,对于"bug",如果您正确编码并遵循所有安全准则,那么您正在使用参数化存储过程,因此单引号将被正确处理,如果您没有正确编码,请不要关闭货架库将充分保护您.AntiXss库旨在成为一种可以使用的工具,而不是知识的替代品.依托图书馆做适合你会期待一个真正的好画笔转出良好的画作没有一个好的艺术家.
编辑 - 添加
正如问题中所提到的,反xss将保护你和HttpUtility的例子不会:
HttpUtility.HtmlEncode和Server.HtmlEncode不会阻止跨站点脚本
但是根据作者的说法.我没有亲自测试过.
这听起来像是你的安全准则,所以这可能不是我需要告诉你的事情,但是如果一个经验不足的开发人员在那里阅读这个,我之所以说白名单方法很关键这是.
现在,今天,HttpUtility.HtmlEncode可以成功阻止每一次攻击在那里,只需将其取出/编码<和>,加上其他一些"知可能不安全"字,但有人总是试图想打破的新途径.只允许已知安全(白名单)内容比试图考虑攻击者可能向您投掷的每个可能的不安全位输入(黑名单方法)要容易得多.
就你为何使用其中一个而言,考虑到AntiXSS库比ASP.NET框架更频繁地发布 - 因为正如David Stratton所说'有人总是试图想出新的攻击方式',当有人提出一个时,AntiXSS库更有可能获得更新版本以防御它.
以下是Microsoft.Security.Application.AntiXss.HtmlEncode和System.Web.HttpUtility.HtmlEncode方法之间的区别 :
Anti-XSS使用白名单技术(有时也称为包含原则)来提供针对跨站点脚本(XSS)攻击的保护.此方法首先定义有效或允许的字符集,并对此集合之外的任何内容进行编码(无效字符或潜在攻击).System.Web.HttpUtility.HtmlEncode该命名空间中的其他编码方法使用排除原则,并仅编码指定为潜在危险的某些字符,例如<,>,&和'字符.
Anti-XSS Library的白色(或安全)字符列表支持十几种语言(希腊语和科普特语,西里尔语,西里尔语补充语,亚美尼亚语,希伯来语,阿拉伯语,叙利亚语,阿拉伯语补充,Thaana,NKo等)
Anti-XSS库专门用于缓解XSS攻击,而HttpUtility创建编码方法是为了确保ASP.NET输出不会破坏HTML.
性能-之间的平均增量AntiXss.HtmlEncode(),并HttpUtility.HtmlEncode()为每笔交易0.1毫秒.
Anti-XSS 3.0版提供了一个测试工具,允许开发人员同时运行XSS验证和性能测试.
大多数XSS漏洞（实际上是任何类型的漏洞）都完全基于现有的安全性无法“预期”某些事情的事实。默认情况下，仅白名单方法更适合处理这些情况。
京公网安备 11010802040832号 | 京ICP备19059560号-6 