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

原文地址：https://www.cnblogs.com/itplay/p/10421087.html