XSS漏洞

XSS漏洞（共3篇）

XSS漏洞 篇1

随着信息时代的发展, W ed服务逐渐被推广开来, 而W ed程序的安全性问题日渐显现, 其中最为常见的就是X SS攻击。在许多在脚本语言上输出的动态内容很容易导致W ed服务站点受到X SS攻击。一般通过在W ed页面中插入恶意代码, 用户在浏览受到恶意代码攻击的网页时在W ed页面中的恶意代码便会执行, 从而破坏和控制的恶意目的, 破坏程度远高于一般的网络蠕虫, 给网站和网络的运行造成巨大的损失和隐患。因此, 在网站中检测X SS漏洞是尤为必要的。

1 XSS攻击原理及过程

跨站脚本攻击 (X SS) 通过扫描网站中存在的漏洞, 尤其是网站未设置用户登入数据过滤等, 在用户访问的页面链接中插入恶意代码来窃取用户信息。在攻击的网站的过程中主要包括三个部分, 分别是网站、攻击者、受害者, 其中只有受害者会运行攻击者插入的恶意连接, 网站只是一个载体, 一般来说不会受到攻击和影响。

X SS攻击步骤如下:

1) 攻击者选定自己感兴趣的W ed站点, 但终有正常身份的用户才能访问该站点。2) 攻击者在感兴趣的W ed站点中寻找跨站脚本漏洞。3) 攻击者制作一个带有恶意代码的连接发送到该站点的潜在用户的邮箱、页面等中。4) 受害者点开该连接时便得到了该用户的cookie, 便可冒充该用户进行访问。

2 基于网络爬虫的XSS漏洞挖掘技术

基于网络爬虫的X SS漏洞挖掘技术核心模块主要包括以下三个部分, 分别是代码自动注入、漏洞检测等模块。

2.1 网络爬虫模块

在网络搜索引擎中最为核心的构件便是网络爬虫, 是一种自动下载程序。在网络爬虫运作的过程中不断的向服务器发送请求, 因此在数据传输中可进行编码压缩减少网络传送的数据。由此可见, 在对字符进行hash时, 应排除起始和末端的常见字符避免碰撞的发生。本研究在此概念中研究出一种新的算法———M-Interval-H ash, 可快速运算出U R L的hash值:M=筛选点常见字符后的长度, N是U R L中选取字符的间隔字符数。例如:N=6, 字符数则为72, 则M=24, 这代表字符间隔为24个字符。

2.2 代码自动注入模块

跨站脚本漏洞在挖掘中, 将代码注入来检测是否存在漏洞, 在跨站脚本中恶意代码一般是在PO ST请求或G ET请求中。因此, 在代码注入中需考虑这两种情况。在代码注入时测试每个注入点, 并在测试时以数据库代码顺序在数据库中取出记录, 直至数据库中没有记录。

2.3 漏洞检测模块

在代码自动注入后, 再对注入结果进行漏洞监测, 避免代码终有漏洞存在。本研究以匹配漏洞特征库来辨别跨站脚本漏洞是否成功。在漏洞特征库中得到跨站脚本注入漏洞的测试板, 从而对PO ST请求, G ET请求依从进行跨站脚本攻击。进而收取W eb服务器端返回的消息, 分析该消息时候存在漏洞特征库中的漏洞。如果存在便说明有X SS漏洞。测试脚本的质量影响着X SS的测试效果, 在此本研究采用O pen W eb A pplication Security Project所推荐的测试脚本。

3 XSS漏洞检测测试

3.1 本研究技术与其他基于爬虫的检测工具的检测效果

本研究为验证该技术的可行性, 对某些网站进行了扫描测试, 同时以X SSer1.5、A cunetix W V S Free Edition 6.5基于爬虫的检测工具的检测效果为对照。网站测试环境1为A pache 2.2.14+PH P;网站测试环境2为IIS 6.0+A SP, 由于在测试网站2中具有Form表单, 因此X SSer在表中未检测出X SS漏洞, 结果见表1。

3.2 本研究技术与其他基于爬虫的检测工具扫描耗时

通过对比本研究技术与A cunetix W V S 8和X SSer1.5的扫描耗时可见, 本研究技术检测工具扫描耗时比A cunetix W V S 8和X SSer1.5工具表现更佳, 见表2。

4 结束语

跨站脚本漏洞在挖掘中, 将代码注入来检测是否存在漏洞, 在跨站脚本中恶意代码一般是在PO ST请求或G ET请求中。在代码注入时测试每个注入点, 并在测试时以数据库代码顺序在数据库中取出记录, 直至数据库中没有记录。本研究提出了一种基于网络爬虫的X SS漏洞挖掘技术, 并采用了一种新的算法———M-Interval-H ash, 在实践中发现该技术在应对X X S漏洞检测中具有显著效果。

参考文献

[1]文凯, 何小东.一种基于网络爬虫的跨站脚本漏洞检测方法[J].电脑编程技巧与维护, 2012.

[2]刘鑫, 孙名松, 唐亮.基于代理的XSS漏洞检测与收集系统的实现[J].哈尔滨理工大学学报, 2010.

XSS漏洞 篇2

XSS漏洞一般是基于WEB程序的输入输出问题，但最近80SEC开始发现了一系列以IE为内核的第三方浏览器的漏洞，在评估其中的XSS漏洞，我们发现了基于浏览器软件自身设计造成的XSS漏洞所暴发的威力有多么大! 通过类似的漏洞我测试了一个功能十足的浏览器木马，这个“木马”可以控制浏览器所有的行为，甚至包括读取本地任意文件和运行本地任意可执行文件，

关于XSS漏洞另一个攻击趋势

XSS漏洞 篇3

关键词：XSS漏洞,Web安全,存储型XSS漏洞,动态检测

0 引 言

近年来,随着Web应用程序的推广,Web安全问题也越来越被人们所重视。根据OWSAP近几年对Web安全漏洞的调查统计表明,跨站脚本XSS漏洞已经成为目前大多数网站共同面对的最常见的安全漏洞[1]。XSS漏洞主要有反射型(Reflected-XSS)漏洞、存储型(Stored-XSS)漏洞和DOM型XSS漏洞三种[2]。反射型XSS漏洞攻击的脚本通常包含在URL链接中,点击访问后就可以立即在浏览器上执行脚本攻击,测试阶段可以通过判断HTTP响应中是否包含恶意攻击脚本来确定是否存在漏洞;而存储型漏洞攻击的脚本是采用把攻击脚本存储进数据库的方式来达到持久攻击的目的,脚本并不会立即在用户的浏览器中执行,因而这种漏洞较难被发现。之前在MySpace等大型网站中相继爆发的XSS漏洞攻击都属于存储型漏洞攻击,给Web应用程序和用户都造成了重大损失。

目前可以用来预防检测XSS漏洞的方法主要有基于代理服务的防御和基于Web应用程序代码的检测。基于代理服务的防御方法是在客户端和服务器端之间安装代理服务系统,通过检测分析HTTP包来判断是否存在着可疑危险脚本[3,4,11]。这种方法不是从根源上遏制XSS攻击,而且配置部署复杂,一定程度上降低了用户的网络体验效果[5]。

基于Web应用程序代码的检测,是对Web应用程序中潜在的安全漏洞进行排查,通过修改完善代码的手段,达到从根源上减少漏洞遏制漏洞攻击的目的。目前广泛采用静态分析和动态分析两种方法:静态分析方法,如文献[6,7]通过审核应用程序的源代码查找输入验证缺陷,从而发现漏洞。这种方法对源码的透明性要求很高,源代码审核人员必须具备很强的攻击预防知识,软件开发人员很难达到这个要求。动态分析方法是采用模拟攻击的方式,通过与Web应用程序的互动,从而有效地执行测试攻击来检测XSS漏洞。目前基于动态分析技术提出的检测方法,如文献[8,9,12],在实施一系列的脚本攻击后,仅仅是通过检测应用程序的响应中是否存在注入的脚本来判断是否存在漏洞,因此适合检测这种立即就可以得到HTTP响应的反射型XSS漏洞攻击,但由于存储型XSS漏洞攻击的脚本并不会立即在HTTP响应中执行,因此这种检测方法并不能有效地判断Web应用程序是否真正存在存储型XSS漏洞。

针对动态分析方法在存储型XSS漏洞检测方面的不足与存储型XSS漏洞的特点,本文提出了一种有效的Stored-XSS漏洞动态检测方法,设计并实现了该检测模型。并在实际的场景下对该模型进行测试评估,实验证明该方法能对存储型XSS漏洞进行有效检测。

1 XSS漏洞攻击原理分析

现有XSS漏洞攻击分为三种基本类型:反射型漏洞攻击、存储型漏洞攻击以及基于DOM型的XSS漏洞攻击,其中基于DOM型的XSS漏洞攻击比较少见,这里不做分析。

反射型XSS漏洞通常存在于这种情况下: 当用户输入文本信息并提交给服务器时,服务器不对文本信息做任何处理,而是将文本信息直接作为url的参数连同完整的url返回给用户的浏览器。当浏览器执行该url,该参数就直接显示输出在Web页面中,当该参数是恶意脚本时,恶意脚本就会立即在用户的浏览器中执行。攻击者可以利用该url构造一个带有恶意脚本参数的恶意url链接,并通过Email、BBS等诱骗手段诱使用户点击该恶意url链接,那么隐藏在url参数中的恶意脚本就会立即在用户的浏览器中执行,从而盗取用户的cookies等重要信息[5]。

与反射型XSS漏洞攻击不同,存储型XSS漏洞攻击是由于Web应用程序对用户的输入验证过滤失误,导致攻击者可以将包含有可执行恶意脚本的信息以正常信息的方式提交给服务器,并最终在Web应用程序的数据库中持久储存。这些恶意脚本并不能立即执行,只有当用户访问这些信息时,隐藏在信息里面的恶意脚本才会在用户的浏览器中加载执行。由于这些脚本是来自Web应用程序服务器,因此用户的浏览器允许这些脚本访问cookies,这样用户的敏感信息就会被攻击者盗取。同时这些恶意脚本如果不能在数据库中彻底清除,攻击将会一直存在,越来越多的用户将会受害。

如图1所示,存储型XSS漏洞攻击分为两个阶段,第一阶段是1到4步,首先黑客(A)在有存储型XSS漏洞的Web应用程序(VWA)中注册并将带有可执行恶意脚本的信息(Ma)提交给VWA,这样Ma就在VWA的数据库中储存,然后等待用户访问该信息;第二阶段是5到12步,用户登陆到VWA,点击请求访问Ma,VWA返回Ma的信息到用户的浏览器(V),V执行Ma中恶意脚本,用户的cookies信息被盗取并发送给恶意Web应用服务器(MWA)[5]。

2 Stored-XSS漏洞动态检测模型

本文提出的Stored-XSS漏洞动态检测模型主要采用动态分析方法,即模拟攻击者实施攻击测试,主要通过两个阶段实现:浏览和测试。浏览就是寻找攻击注入点的过程,测试就是通过不停地在这些注入点注入测试攻击向量寻找漏洞的过程。所以如何充分挖掘存储型XSS漏洞的攻击注入点以及如何有效地执行测试注入攻击以寻找漏洞是检测存储型XSS漏洞的关键。

从存储型XSS漏洞攻击原理分析可以看出,存储型XSS漏洞攻击的重点在于将恶意脚本以合法内容的形式提交给Web应用程序,这样就可以实现持久化攻击。而Web表单是Web应用程序向用户提供的添加新的内容并持久存储的主要方式,故Web表单理所当然地成为了实现存储型XSS漏洞攻击在Web应用程序中持久存储攻击的主要途径,也是存储型XSS漏洞攻击的可疑攻击点。同时在测试阶段,存储型XSS漏洞比反射型XSS漏洞更复杂。这是因为其攻击脚本是在数据库中存储并以正常信息的方式展现,并不能立即在浏览器中执行,只有点击访问到具体信息内容时,攻击脚本才会被触发执行。所以存储型XSS漏洞检测的测试阶段需要重新扫描测试攻击脚本被提交存储的Web页面,查找该Web页面中是否存在所测试的攻击脚本以判断是否存在存储型XSS漏洞。

基于上述对存储型XSS漏洞特点的分析,大致可以将存储型XSS漏洞检测分为以下4步:

(1) 扫描Web应用程序,找出所有包含Web表单信息的Web页面。

(2) 对每个包含Web表单信息的Web页面进行解析,筛选里面的Form表单信息,作为可疑攻击点。

(3) 对每个可疑攻击点,通过在Form表单中插入Stored-XSS漏洞检测攻击向量并提交给Web服务器的方式,实现存储型XSS漏洞攻击,达到将Stored-XSS漏洞检测攻击向量注入到Web应用程序的目的。

(4) 对每个HTTP请求响应后返回的Web页面信息解析,根据Stored-XSS漏洞检测攻击向量信息寻找存储型XSS漏洞。

根据上述分析, Stored-XSS漏洞动态检测模型四个模块组成,模型的系统结构图如图2所示。 其中Crawler模块负责分析Web 站点,寻找包含Form表单的Web页面的url信息;FormParser模块负责通过url解析Web页面,提取Form表单信息;ScriptInject模块负责通过以向Web应用程序提交Form表单的方式向web页面注入Stored-XSS漏洞检测攻击向量;Testing模块负责通过注入成功的Stored-XSS漏洞检测攻击向量信息寻找Stored-XSS漏洞。

3 模型的设计与实现

Stored-XSS漏洞动态检测模型由攻击向量数据库(AttackDB)、Crawler模块、FormParser模块、ScriptInject模块、Testing模块紧密配合,实现整个漏洞查找定位的全过程。

3.1 AttackDB设计

攻击向量数据库的设计分为两部分,一部分用于存储Stored-XSS漏洞检测攻击向量,每条记录由向量ID、向量内容以及向量类型组成,用于注入测试攻击;而另一部分用于存储ScriptInject模块实际注入成功的Stored-XSS漏洞检测攻击向量,每条记录由向量ID、注入点名称以及注入点所在Web页面信息组成,用于准确定位漏洞点。

用于注入的Stored-XSS漏洞检测攻击向量主要有以下三类:

(1) 类型一:直接将脚本作为value值(例:<script>alert(“xss”)</script>)。

(2) 类型二:将脚本作为html元素的属性值嵌入到html元素中作为value值(例:<img src=’<script>alert(“xss”)</script>’ />)。

(3) 类型三:将脚本作为触发事件嵌入到html元素中作为value值(例:<img onclick=’javascript:alert(“xss”);’ />)。

在实际网站中,由于大家对XSS漏洞越来越重视,网站通常都会采用一些过滤机制来对输入的数据进行处理来预防常见的XSS漏洞攻击。为了保证注入脚本能有效地注入到网站中,还需要对攻击向量做一定的变形处理,以保证最终注入的脚本能有效地执行。本文采用编码、大小写混编、插入空白字符串等常用处理方法对三种类型的攻击向量变形处理得到大量攻击向量,攻击向量集参考文献[10]。

3.2 Crawler模块

Crawler模块用于获取目标Web应用程序所有包含有Form表单信息的Web页面。输入参数为网站的首页地址,通过广度优先算法,遍历该网站的所有页面,寻找带有Form表单的Web页面,将找到的Web页面的url信息作为参数传给FormParser模块做下一步的解析操作。

3.3 FormParser模块

FormParser模块通过解析Web页面获取Form表单的具体信息。输入参数为Crawler模块扫描出来的Web页面的url信息,需要解析的表单信息主要包括:(1)Form表单属性:Form表单的name、action、method属性内容,这些属性提供了表单被提交后的处理信息。(2)Form表单选项:Form表单中的input、textarea、select三种常见的表单选项,其中text、password、和textarea类型的控件是存储型XSS漏洞的攻击点,ScriptInject模块将在这些攻击点中注入Stored-XSS漏洞检测攻击向量。FormParser模块将解析出来的完整Form表单信息传给ScriptInject模块,用于将脚本插入到表单中一起提交给Web服务器。

3.4 ScriptInject模块

ScriptInject模块是模拟攻击者注入攻击的过程,即将带有恶意脚本的信息注入到Web应用程序中。这是整个模型的核心,Stored-XSS漏洞检测攻击向量能否成功注入直接决定了该注入点是否存在Stored-XSS漏洞。

在实际过程中,客户端与服务器端的交互是采用HTTP请求的方式将信息上传至服务器,ScriptInject模块需要完成的是在这个交互过程中将Stored-XSS漏洞检测攻击向量插入到正常表单信息中并上传至服务器。在具体的实现过程中,本文采用构造带有Stored-XSS漏洞检测攻击向量的HTTP请求来实现自动注入攻击。

由于在实际中多以post方式来提交用户输入信息,这里以构造post请求(get请求类似)为例来说明该模块的工作流程:

(1) 从FormParser模块获取表单信息以及表单所在的页面的url信息。

(2) 提取Form表单属性构造正确的url信息,作为页面请求的对象。

(3) 根据Form表单的选项,构造post请求的参数,表单选项的name属性作为参数名,再给每个参数动态传值。其中text、password、textarea这三种类型的控件是脚本注入的注入点,在构造的过程中,要从AttackDB中分别选取Stored-XSS漏洞检测攻击向量作为参数值。在实际中,一个Form表单中可能存在着多个text、password、textarea控件,因而有多个注入点。为了便于准确寻找定位Stored-XSS漏洞,对于每个注入点指定不同的标识。例如在第一注入点采用“testxss1<script>alert(“xss”)</script>testxss1”,在第二个注入点采用“testxss2<script>alert(“xss”)</script>testxss2”,这样就可以通过标识符来辨别漏洞是存在于哪个注入点。

(4) 执行post方法,向页面提交带脚本信息的post请求。

(5) 获取服务器响应的状态码,根据状态码判断请求状态。状态码为200说明post请求成功,请求处理的页面即为本页面,存储该页面的url信息;状态码为301、302、303、307说明post请求成功,但是处理页面为另外一个新的页面,这时需要获取Response的Header信息,提取下一个跳转的url信息(即新的处理页面的url信息)。url的信息连同Stored-XSS漏洞检测攻击向量信息一起存入AttackDB,传给Testing模块做测试。状态码为400说明请求失败,这可能是由于Form表单对输入的限制导致,这时需要重新从AttackDB选择攻击向量再重复上面的过程。

3.5 Testing模块

Testing模块的目的是寻找定位Stored-XSS漏洞。这个过程需要像Crawler模块一样再度解析Web页面,此次需要解析的页面是AttackDB中存储的Web页面,该页面是信息处理的页面。通过扫描该页面查找是否存在着ScriptInject模块中注入的Stored-XSS漏洞检测攻击向量,如果找到则说明存在着一个存储型XSS漏洞,并根据Stored-XSS漏洞检测攻击向量所在的注入点信息定位漏洞。

4 测试与结果分析

为了检测Stored-XSS漏洞动态检测模型的有效性,验证本文提出的方法是否可行,本文在现实条件下分别对三种不同语言实现的网站做了测试。

4.1 测试结果

4.1.1 测试项目一:用于测试搭建的同学留言录

网站特点:网站采用Jsp+Servlet+MySQL,主要向用户提供留言版功能。

实验结果:

(a) 漏洞I:在add.jsp页面的name=”userurl”的控件中注入攻击向量时,在处理页面index.jsp中能成功找到注入的攻击向量。

(b) 漏洞II:在add.jsp页面的name=” content”的控件中注入攻击向量时,在处理页面index.jsp中能成功找到注入的攻击向量。漏洞检测的具体信息以及检测率的统计结果如表1所示。

结果分析:从表1可以看出,漏洞I针对类型一的攻击向量检测成功率较高,高达61.1%。说明网站在该处针对类型一的攻击向量的输入验证不够,造成恶意脚本可以直接提交给服务器;而漏洞II针对类型三的攻击向量检测成功率较高,高达69.6%。说明网站在该处针对类型三的攻击向量的输入验证不够。

漏洞成因分析:网站在设计的过程中,在漏洞I处仅仅做了简单的输入长度限制,并未对输入信息做任何处理,这样就导致了符合长度的可执行脚本可以直接作为正常信息被提交给服务器。在漏洞II处,放宽了长度限制却做了一些简单的预防XSS攻击过滤处理,但是对于第三种类型的攻击向量的过滤不足,导致大量的第三种类型的攻击向量注入成功。

4.1.2 测试项目二:期刊杂志网站

网站特点:采用.NET框架,向用户提供在线阅读功能的同时提供BBS留言跟帖等功能。

实验结果:

(a) 漏洞I:在regist.aspx?id=reg页面的name=”address”的控件中注入攻击向量时,在处理页面userInfo.aspx中能成功找到注入的攻击向量。

(b) 漏洞II:在message.aspx页面的name=”title”的控件中注入攻击向量时,在处理页面messagesInfo.aspx中能成功找到注入的攻击向量。

(c) 漏洞III:在message.aspx页面的name=”content”的控件中注入攻击向量时,在处理页面messageInfo.aspx中能成功找到注入的攻击向量。

(d) 漏洞IV:在article.aspx?articleid=1页面的name=”content”的控件中注入攻击向量时,在处理页面article.aspx?articleid=1中能成功找到注入的攻击向量。漏洞检测的具体信息以及检测率的统计结果如表2所示。

结果分析:从表2可以看出,漏洞I和漏洞II针对类型一的攻击向量检测成功率较高,漏洞III和漏洞IV对于三种类型的攻击向量的检测成功率都较高,都达到了50%以上。实验结果说明该网站在预防XSS漏洞攻击的处理上存在很大缺陷,这很可能是由于网站在开发的过程中就对XSS漏洞安全的疏忽,导致编码中遗留了很多XSS漏洞安全隐患,一旦被黑客发现并利用,将会造成灾难性的后果。

4.1.3 测试项目三:QQ空间

实验结果:并未发现潜在的Stored-XSS漏洞。

结果分析:并未发现任何Stored-XSS漏洞的原因可能是:(a) 随着之前在MySpace、新浪微薄等大型网站中相继爆发的XSS漏洞攻击,XSS漏洞越来越受重视,QQ空间这类大型网站都对常见的XSS漏洞攻击做了预防处理。(b) 我们采用的Stored-XSS漏洞检测攻击向量是常见的XSS漏洞攻击向量,攻击向量有限,对于未知的XSS漏洞攻击的检测存在一定局限性。基于上述原因,这个结果是符合预期效果的。

4.2 测试总结分析

总结上述实验结果表明,大部分存储型XSS漏洞的存在都是由于没有对输入做有效的验证处理导致,而根源在于Web开发过程中编码的不规范以及对Web安全的忽视。上述实验可以证明,本文提出的存储型XSS漏洞检测方法能有效地检测网站中潜在的存储型XSS漏洞。如果将该方法应用于开发过程中,辅助开发人员测试检测网站中潜在的存储型XSS漏洞,并针对漏洞点修改完善代码,将有利于从根源处减少XSS漏洞遏制XSS漏洞攻击。

5 结 语

本文通过对XSS漏洞的深入研究和现有XSS漏洞预防检测技术的分析,针对存储型XSS漏洞的特征,设计并实现了Stored-XSS漏洞动态检测模型,是对现有技术不能有效检测存储型XSS漏洞的扩充。实验证明,该方法可以有效地检测出常见的存储型XSS漏洞,用于辅助开发人员发掘在编程过程中容易疏忽的存储型XSS漏洞安全隐患,从根源处防患存储型XSS,对于加强整个Web应用程序的安全起着重要作用。

后期我们将对攻击向量做更深一步的研究,使得我们的攻击向量能适应未来可能出现的更为复杂的存储型XSS攻击。同时我们将加入反射型XSS的检测,扩大检测的覆盖面,在这方面我们将在如何提高检测效率,减少误报率等方面突破,最终形成一套有效的全面的XSS漏洞动态检测方法。

参考文献

[1]Owasp.Top 10-2010[EB/OL].http://www.owasp.org.cn/owasp-project/download/2010_OWASP_Top_10/view.

[2]Owasp[EB/OL].https://www.owasp.org/index.php/Cross-site_Scripting_(XSS).

[3]Engin Kirda,Christopher Kruegegl,Giovanni Vigna,et al.Noxes:Aclient-side solution for mitigating cross-site scripting attacks[C]//Pro-ceedings of the 21st ACM Symposium on Applied Computing,2006:330-337.

[4]Omar Ismail,Masashi Etoh,Youki Kadobayashi.A Proposal and Im-plementation of Automatic Detection/Collection System for Cross-SiteScripting Vulnerability[C]//18th International Conference on Ad-vanced Information Networking and Applications(AINA 2004),2004,1:145-151.

[5]Joaquin Garcia-Alfaro,Guillermo Navarro-Arribas.A Survey on Cross-Site Scripting[S].Attacks.arXiv:0905.4850v1[cs.CR]29May 2009.

[6]Gary Wasserman,Su Zhendong.Static detection of cross-site scriptingvulnerabilities[C]//Proceedings of the 30th international conferenceon Software engineering.ACM New York,NY,USA,2008:171-180.

[7]Nenad Jovanovic,Christopher Kruegel,Engin Kirda.A static analysistool for detecting web application vulnerabilities[C]//2006 IEEESymposium on Security and Privacy,2006:6.

[8]Acunetix.Web application security[EB/OL].2010.http://www.clusif.asso.fr/fr/production/ouvrages/pdf/CLUSIF-2010-Web-appli-cation-security.pdf.

[9]Stefan Kals,Engin Kirda,Christopher Kruegel.A Web VulnerabilityScanner[C]//Proceedings of the 15th international conference onWorld Wide Web,2006:247-256.

[10]Snake R.Xss(cross site scripting)cheat sheet[EB/OL].http://ha.ckers.org/xss.html.

[11]王夏莉,张玉清.一种基于行为的XSS客户端防范方法[J].中国科学院研究生院学报,2011,28(5):668-675.