Asp.net安全架构之1：xss（跨站脚本）
原理跨站脚本（Cross site script，简称xss）是一种“HTML注入”，由于攻击的脚本多数时候是跨域的，所以称之为“跨域脚本”。
我们常常听到“注入”（Injection），如SQL注入，那么到底“注入”是什么？注入本质上就是把输入的数据变成可执行的程序语句。SQL注入是如此，XSS也如此，只不过XSS一般注入的是恶意的脚本代码，这些脚本代码可以用来获取合法用户的数据，如Cookie信息。
其原理如下图所示：
XSS从攻击原理上，分为三类：
1：反射型XSS
将用户输入“反射”回浏览器，即将用户的输入变成HTML传输回客户端。如：
Response.Write(“<script>alert(/xss/);</script>”)
就是一个典型的反射型XSS。
2：存储性XSS
存储性XSS本质上也是一种反射型XSS，但是它把攻击脚本放置在服务器端，一旦被注入，可被多人多次利用。如，发表博文，就可以引入存储性的XSS。
3：DOM BASED XSS
如果用户的输入被用于修改原有HTML的DOM内容，就会引入这一类攻击。
最典型的是输入的内容用于作为某个节点的innerHTML，如果不对输入作验证，则会被注入攻击代码。
如下的一段脚本注入后，就会获取用户的Cookie
<script language=”javascript”>
var cockieInfo =window.cockie;
//send cockieInfo to luminji
</javascript>
实际案例
使用Fiddler，查看到某系统添加公共信息有一处Post，我们伪造如下的请求：
POST xxx.com/AddPublicInfo HTTP/1.1
Accept: */*
Accept-Language: zh-cn
Content-Type: application/json; charset=utf-8
Accept-Encoding: gzip, deflate
Host: 192.168.80.136
Content-Length: 187
Cookie: ASP.NET_SessionId=qk1qvprjrikp2peveg2ini45; LanguageKey=zh_cn; LoginId=dean;
{"type":"ExtBulletin","title":"1111asdf11","content":"22sdfs22<script>alert(/xss/);</script>","validPeriod":"1","beginDate":"","endDate":"","language":"None","linkFile":"0","fileName":""}
然后，刷新公共信息页面，发现注入代码成功。如果该站点同时存在会话劫持方法的漏洞，则将注入脚本改称获取cookie，攻击者就可以伪造任意访问了本信息的用户来登录系统。
通过该例子我们也可以看到，对于XSS的防范，所有的处理应该是在服务器端的，因为客户端的验证，如使用JS来验证输入是完全可以通过伪造请求被绕过的。所以在安全架构方面对于JS脚本的定位为：JS仅用于改善用户体验。
应对策略
1. 在服务器段限制输入格式,输入类型，输入长度以及输入字符
要注意避免使用一些有潜在危险的html标签，这些标签很容易嵌入一些恶意网页代码。如<img> <iframe><script><frameset><embed><object>< style>等。
注意，不要仅仅在客户端使用js代码加以验证。因为客户端的js脚本可以被绕过。
2. 格式化输出。将输入的内容通过HttpUtility.HtmlEncode处理，这样就不能直接看出输出的内容。
3：对于asp.net站点，可以确保：
<configuration>
<system.web>
<pages validateRequest="true" />
</system.web>
</configuration>
注意，默认情况下为true。
4：IE本身也有机制阻止跨站脚本
存在跨站脚本威胁，如果使用的IE8，则这个请求会被拦截，提示“Internet Explorer 已对此页面进行了修改，以帮助阻止跨站脚本。单击此处，获取详细信息...”。
这个错误是由于 IE8 的跨站脚本(Cross-site scripting, XSS)防护阻止了跨站发送的请求。
以下是如何配置它：点击 IE8 的“工具”-“Internet 选项”，进入“安全”选项卡，打开“Internet”下方的“自定义级别”，在“安全设置”对话框中找到“启用 XSS 筛选器”，改为“禁用”即可。 注意，“启用”是默认配置。
当然，浏览器本身的这种机制是不可靠的。
具体措施
n 查找所有code behind中的”.Text”
通过文件查找出所有的为文本赋值的代码行；
n 为赋值Encode
对上一步骤查找出来的赋值，首先Encode。
n 查找所有的WCF方法中返回字符串的
通过文件查找”.svc”，找到全部的WCF方法，筛选出返回string的方法
n 处理字符串再返回
对上一步骤查找出来的返回的string，先找到序列化方法，然后对实体的可能被用于输出为html的属性，首先Encode
以上统计纳入到如下表格：
|
序号 |
文件 |
代码行 |
处理完成否 |
|
|
|
|
|
n 查找所有的文本输入控件
通过文件查找前台所有的””text””,”’text’”,”type=text”,”textarea”,”textbox”字样，筛选出含文本输入的控件，这些控件包括：
<input type="text" />
<textarea></textarea>
<asp:TextBox runat="server"></asp:TextBox>
n 查找所有带参数的URL
通过文件查找所有的”aspx?”,”html?”,”htm?”,”.svc”（随系统的文件后缀方案而定），筛选出所有带参数的URL。
n 查找所有的ajax
通过文件查找前台中所有的”ajax”，筛选出所有的ajax输入。
n 查找所有cookie
通过文件查找所有的”cookie”，找出所有设置cookie的地方。
n 查找所有session
通过文件查找所有的” session”，找出所有设置session的地方。
n 处理以上查找的结果
分别将其对应的输出查找出来，然后汇集为如下的表格：
n 查找遗漏
为了防止遗漏，需要直接查找输出，通过文件查找所有的”Response.Write”（后台）,” innerHTML”（前台）,”document.write”（前台）。将遗漏更新到上面的表格中。
注意，实际上，如果将应用程序变量和数据库内容赋值给前台控件，通过这种方式还是不能找到遗漏的，只能依赖于前面的输入的查找来一定程度上避免这种情况。
n 根据以下表格中的处理方法来处理上面统计出来的表格中的代码行，为输出Encode
为了防范XSS攻击，我们可以使用Anti-Cross Site Scripting Library（查看http://msdn.microsoft.com/en-us/library/aa973813.aspx，不过当前版本已经到了4.2.1，下载地址为：http://www.microsoft.com/en-us/download/details.aspx?id=28589）
该Library提供如下的几个函数，分别对不同的应用场景作出处理：
n 确保配置web.config中的validateRequest="true"
n 确保Cookie的httponly
通过文件查找所有的”cookie”，找出所有设置cookie的地方，为用于认证的cookie设置如下的格式：
Set-Cookie: cookieName=cookieValue;httponly
参考:
http://msdn.microsoft.com/en-us/library/ff649310.aspx
http://msdn.microsoft.co
补充：综合编程 , 安全编程 ,
