XSS跨站脚本攻击与防御

1.什么是 XSS ？

XSS (Cross Site Scripting)，即跨站脚本攻击，是一种常见于 Web 应用中的计算机安全漏洞。恶意攻击者往 Web 页面里嵌入恶意的客户端脚本，当用户浏览此网页时，脚本就会在用户的浏览器上执行，进而达到攻击者的目的。比如获取用户的 Cookie、导航到恶意网站、携带木马等。借助安全圈里面非常有名的一句话：*所有的输入都是有害的。*这句话把 XSS 漏洞的本质体现的淋漓尽致。大部分的 XSS 漏洞都是由于没有处理好用户的输入，导致恶意脚本在浏览器中执行。任何输入提交数据的地方都有可能存在 XSS。

2.XSS类型

xss类型主要被分为三类，分别是：反射型、存储型和DOM型。

2.1 反射型

反射型XSS也被称为非持久性XSS，是现在最容易出现的一种XSS漏洞。当用户访问一个带有XSS代码的URL请求时，服务器端接收数据后处理，然后把带有XSS代码的数据发送到浏览器，浏览器解析这段带有XSS代码的数据后，最终造成XSS漏洞。这个过程就像一次反射，故称为反射型XSS。

非持久型XSS漏洞实际上大多数攻击数据是包含在URL中的，类似这样的：
http://www.xxxxx.com/test.asp?hi=[code]。需要用户的浏览器访问到这个URL恶意代码才执行，攻击者一般会把URL发给用户让用户通过浏览器去访问。不过URL里面带有稀奇古怪的代码确实有点奇怪，为了掩人耳目，攻击者可以发一个看起来没问题的URL，再通过那个页面跳转到恶意的URL，甚至也可以让一个域名转向到恶意URL，把那个域名发给用户。

2.2 存储型

存储型XSS又被称为持久性XSS，存储型XSS是最危险的一种跨站脚本。允许用户存储数据的Web应用程序都可能会出现存储型XSS漏洞，当攻击者提交一段XSS代码后，被服务器端接收并存储，当攻击者再次访问某个页面时，这段XSS代码被程序读出来响应给浏览器，造成XSS跨站攻击，比如我在某个论坛发帖的时候，论坛没有对传入的HTML作处理，那么我就可以发一个帖子内容包含<script>[code]</script>的帖子,然后就守株待兔地等着来看帖子的人执行恶意脚本了。持久型XSS漏洞是把恶意脚本存储到了数据库，访问页面的时候完全没有预兆，这就是存储型XSS。

存储型XSS与反射型XSS、DOM型XSS相比，具有更高的隐蔽性，危害性也更大。它们之间最大的区别在于反射型XSS与DOM型XSS执行都必须依靠用户手动去触发，而存储型XSS却不需要。

2.3 DOM型

DOM的全称为Document Object Model，即文档对象模型，DOM通常用于代表HTML、XHTML和XML中的对象。使用DOM可以允许程序和脚本动态地访问和更新文档的内容、结构和样式。
通过JavaScript可以重构整个HTML页面，而要重构页面或者页面中的某个对象，JavaScript就需要知道HTML文档中所有元素的“位置”。而DOM为文档提供了结构化表示，并定义了如何通过脚本来访问文档结构。根据DOM规定，HTML文档中的每个成分都是一个节点。

DOM的规定如下：

整个文档是一个文档节点；
每个HTML标签是一个元素节点：
包含在HTML元素中的文本是文本节点；
每一个HTML属性是一个属性节点；
节点与节点之间都有等级关系。

HTML都是一个个节点，而这些节点组成了DOM的整体结构：节点树。

可以发现, DOM本身就代表文档的意思,而基于DOM型的XSS是不需要与服务器端交互的,它只发生在客户端处理数据阶段。

3 检测XSS

检测XSS一般分为两种方式，一种是手工检测，另一种是软件自动检测，各有利弊。使用手工检测时，检测结果精准，但对于一个较大的Web应用程序而言，手工检测显然是一件非常困难的事情。而使用软件全自动检测时，虽然方便，却存在误报，或是有些隐蔽的XSS无法检测出。

3.1 手工检测XSS

使用手工检测Web应用程序是否存在XSS漏洞时，最重要的是考虑哪里有输入、输入的数据在什么地方输出。
使用手工检测XSS时，一定要选择有特殊意义的字符，这样可以快速测试是否存在XSS。比如，测试某输入框是否存在XSS漏洞时，不要直接输入XSS跨站语句测试，应一步一步地进行，这样更有利于测试。

1.可得知输出位置

输入一些敏感字符，例如“<、>、”、’、0”等，在提交请求后查看HTML源代码，看这些输入的字符是否被转义。在输出这些敏感字符时，很有可能程序已经做了过滤，这样在寻找这些字符时就不太容易，这时可以输入“AAAAA>”&”字符串，然后在查找源代码的时候直接查找AAAAA或许比较方便。

2.无法得知输出位置

非常多的Web应用程序源代码是不对外公开的，这时在测试XSS时就有可能无法得知输入数据到底在何处显示，比如，测试某留言本是否存在XSS，那么在留言之后，可能需要经过管理员的审核才能显示，这时无法得知输入的数据在后台管理页面处于何种状态，例如：
在<div>标签中： <div>XSS Test </div>
在<input>标签中：<input type=\"text\"name=\"content\"value=\"XSS Test\">
对于这种情况，通常会采用输入“”/>XSS Test”来测试。

3.2 全自动检测

APPSCAN、AWVS、Burp Suite等软件，都可以有效地检测XSS跨站漏洞，但这类大型漏扫工具除检测XSS外，还会检测SQL注射、文件包含、应用程序错误等漏洞。虽然这类大型漏扫可以配置只检测XSS，但却不如专业的XSS检测工具效率高。
专业的XSS扫描工具有很多，像有名的XSSER、XSSF都是不错的选择。也有安全爱好者制作了扫描XSS漏洞的Web服务。
在检测的时候一定要工具与手工并进，才能更好地检测XSS。比如，在扫描XSS时，很多扫描器一般都无法检测非常规的XSS漏洞，为什么?例如，在提交留言时可能需要短信验证、验证码填写等，工具是无法做到的。

4 XSS高级利用

XSS不仅仅是弹出一个框那么简单，在某些情况下，XSS不弱于SQL注射。下面列举几个常见的危害。

盗取用户Cookie
修改网页内容
网站挂马
利用网站重定向
XSS蠕虫

5 XSS攻击

5.1.绕过XSS-Filter，利用<>标签注入Html/JavaScript代码；

5.2.利用HTML标签的属性值进行xss攻击。例如：<img src="javascript:alert(‘xss’)"/>；（当然并不是所有的Web浏览器都支持Javascript伪协议，所以此类XSS攻击具有一定的局限性）

5.3. 空格、回车和Tab。如果XSS Filter仅仅将敏感的输入字符列入黑名单，比如javascript，用户可以利用空格、回车和Tab键来绕过过滤，例如：<img src=“javas cript:alert(/xss/);”/>；

5.4. 利用事件来执行跨站脚本。例如：<img src="#" “alert(1)"/>，当src错误的视乎就会执行onerror事件；

5.5. 利用CSS跨站。例如：Body {backgrund-image: url(“javascript:alert(‘xss’)”)}；

5.6. 扰乱过滤规则。例如：<IMG SRC=“javaSCript: alert(/xss/);”/>；

5.7.利用字符编码，透过这种技巧，不仅能让XSS代码绕过服务端的过滤，还能更好地隐藏Shellcode；（JS支持unicode、eacapes、十六进制、十进制等编码形式）

5.8.拆分跨站法，将xss攻击的代码拆分开来，适用于应用程序没有过滤 XSS关键字符（如<、>）却对输入字符长度有限制的情况下；

6 修复XSS跨站漏洞

从上面的介绍可知，XSS 漏洞是由于对用户提交的数据没有经过严格的过滤处理造成的，所以防御的原则就是不相信用户输入的数据，对输入进行过滤，对输出进行编码。

6.1 输入与输出

输入过滤，对用户提交的数据进行有效性验证，仅接受指定长度范围内并符合我们期望格式的的内容提交，阻止或者忽略除此外的其他任何数据。比如：电话号码必须是数字和中划线组成，而且要设定长度上限。过滤一些些常见的敏感字符，例如：< > ‘ “ & # \ javascript expression "onclick=" "onfocus"；过滤或移除特殊的Html标签，例如: <script>, <iframe> , &lt；for <, &gt； for >, &quot for；过滤JavaScript 事件的标签，例如 "onclick=", "onfocus" 等等。

输出编码，当需要将一个字符串输出到Web网页时，同时又不确定这个字符串中是否包括XSS特殊字符（如< > &‘”等），为了确保输出内容的完整性和正确性，可以使用编码（HTML Encode）进行处理。

6.2 HttpOnly

HttpOnly是微软公司的Internet Explorer 6 SP1引入的一项新特性。这个特性为Cookie提供了一个新的属性，用以阻止客户端脚本访问Cookie。至今已成为了一个标准，几乎所有的浏览器都会支持HttpOnly

许多 XSS 攻击的目的就是为了获取用户的 cookie，将重要的 cookie 标记为 http only，这样的话当浏览器向服务端发起请求时就会带上 cookie 字段，但是在脚本中却不能访问 cookie，这样就避免了 XSS 攻击利用 js 的 document.cookie获取 Cookie。