Microsoft 防跨站点脚本库AntiXSS Library v4.2.1

AntiXSS 库目前处于版本 4.2.1,下载地址:http://www.microsoft.com/download/en/details.aspx?id=28589。它经历了一次非常棒的重新编写过程,并且就安全性而言,它提供了比 ASP.NET 附带的编码器更好的 HTML 编码器。 并不是说 Server.HtmlEncode 有什么问题,只是它侧重于兼容性而不是安全性。 AntiXSS 使用不同的方法进行编码。 有关详细信息,请访问 msdn.microsoft.com/security/aa973814。Jon Galloway 在 http://weblogs.asp.net/jgalloway/archive/2011/04/28/using-antixss-4-1-beta-as-the-default-encoder-in-asp-net.aspx 中发布了有关此内容的精彩文章。

This release addresses a vulnerability in the HTML Sanitizer, MS12-007 http://technet.microsoft.com/en-us/security/bulletin/ms12-007 and adds full support for .NET 4.0 as well as restoring support for .NET 2.0.
The sanitizer has been changed to remove all CSS it encounters, this new behaviour means that if you were keeping CSS formatting from HTML that is no longer going to be the case.
In addition to the change necessary to correct the vulnerability there are a few new features;

  • Minimum Requirements.
You can now, once again, use the encoder libraries with .NET 2.0. The installer will create directories for each framework version supported, .NET 2.0, .NET 3.5 and .NET 4.0 which contain an optimized version of the encoders for that platform.
  • Invalid Unicode no longer throws an exception.
Invalid Unicode characters are now replaced with the Unicode replacement character, U+FFFD (�). Previously, when encoding strings through HtmlEncode, HtmlAttributeEncode, XmlEncode, XmlAttributeEncode or CssEncode invalid Unicode characters would be detected and an exception thrown.
  • UrlPathEncode added.
The encoding library now has UrlPathEncode which will encode a string for use as the path part of a URL.
  • .NET 4.0 encoder support.
There’s finally an official way to swap AntiXSS into the framework. If you are using .NET 4.0 ensure you are using the .NET 4.0 version of the encoding library and then edit your web.config and add the encoderType attribute to the httpRuntime element; i.e.

<httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary"/>

 

保护您的 ASP.NET 应用程序

SRE with Antixss Module

跨站脚本攻击(XSS)已经不是什么新鲜的话题了,甚至很多大公司也为此吃尽苦头。最简单直接的防范方法,就是不允许任何html标签输入,对用户输入进行编码(htmlencode)。 但是如果想用户输入支持一些格式,怎么办?一种办法就是很多论坛采用的BB Code的方法。使用特定的标签代替一些格式。比如:[B]表示粗体,等等。但是,BB Code这种形式并不被广泛接受,它的表现力实在太差了,而且并不是标准格式。 为了让用户的输入更具表现力,涌现了大量的Html编辑器控件,著名的有FCKEditor,FreeTextBox,Rich TextBox,Cute Editor,TinyMCE等等。比如,博客园的后台发随笔就支持Cute Editor和TinyMCE,我个人比较喜欢Cute Editor,功能强大,性能不错,而且容易定制。 使用这些Html编辑器控件的潜在危险,是用户可能会输入一些危险字符,注入到网站中,形成XSS攻击。一个最简单的输入就是: alert('xss') 如何防止呢?大致思路有三种: 1. 正则表达式的白名单过滤机制。 2. 正则表达式的黑名单替换机制。 3. 通过DOM对象过滤白名单和黑名单的标签。 其实我用的很简单,就是AntiXss.GetSafeHtmlFragment(html)方法,这个方法会替换掉html里的危险字符。比如: var html = "aaaaaaaaajavascriptalert('a')Test"; string safeHtml = AntiXss.GetSafeHtmlFragment(html); Console.WriteLine(safeHtml); 上面的危险内容被成功替换,返回的内容是: aaaaaaaaajavascript alert('a') Test 嗯,非常安全。然后,又有一个疑问了,是应该将用户的输入过滤之后写入数据呢?还是在输出界面显示的时候进行过滤?其实,通常来讲,在输出界面显示的时候进行过滤就够了,将用户输入过滤后写入数据不是很必要,因为即使这样也无法保证数据中没有危险的数据。当然,上个双保险也没有什么不好的。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值