admin 管理员组文章数量: 1086019
2024年2月7日发(作者:亚马逊雨林知乎)
跨站攻击
1 基本概念
1.1 背景
概述:恶意攻击者往Web页面里插入恶意html代码,当用户浏览该页之时,嵌入其中Web里面的html代码会被执行,从而达到恶意攻击用户的特殊目的。
事件:国外的MYSPACHE站点曾经发生过这样一个事件,一个叫samy的人利用XSS漏洞写了世界上第一只跨站脚本蠕虫,20小时内就传染了一百万个用户,最后导致MySpace站瘫痪。
1.2 定义
跨站攻击,即Cross Site Script Execution(为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS)是指攻击者利用网站程序对用户输入过滤不足,输入可以显示在页面上对其他用户造成影响的HTML代码,从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。
简而言之,跨站攻击的模式是指攻击者不与受害者直接发生联系,而通过网络作为中介完成攻击。
业界对跨站攻击的定义如下:“跨站攻击是指入侵者在远程WEB页面的HTML代码中插入具有恶意目的的数据,用户认为该页面是可信赖的,但是当浏览器下载该页面,嵌入其中的脚本将被解释执行。”由于HTML语言允许使用脚本进行简单交互,入侵者便通过技术手段在某个页面里插入一个恶意HTML代码,例如记录论坛保存的用户信息(Cookie),由于Cookie保存了完整的用户名和密码资料,用户就会遭受安全损失。如这句简单的Javascript脚本就能轻易获取用户信息:alert(),它会
弹出一个包含用户信息的消息框。入侵者运用脚本就能把用户信息发送到他们自己的记录页面中,稍做分析便获取了用户的敏感信息。
对于跨站脚本攻击,黑客界共识是:跨站脚本攻击是新型的“缓冲区溢出攻击”,而JavaScript是新型“ShellCode”。
1.3 跨站攻击发生在什么时候?
- 数据通过一个不可信的源,大多数时是一个页面请求,进入网站应用。
- 数据未经验证是否含有恶意内容,就包含在动态内容中发送给网站用户。
发送到浏览器的恶意内容通常以一段Javascript脚本的形式存在,但也可能是HTML、VBScript、ActiveX、Flash或者任何其他可能被浏览器执行的代码。基于XSS的攻击是多样化没有限制的,常见的有传输私密数据,像cookies或其他会话信息,对攻击者而言,重定向或引诱受害者到由攻击者所控制的页面,或者伪装成可信赖网站,直接在用户机器上执行恶意操作。
1.4 跨站脚本漏洞的出现场景
•输出在HTML页面
•输出在HTML属性中
•输出在JavaScript代码中
•基于DOM
1.5 跨站攻击基本原理
用户提交的变量没有经过完整过滤Html字符或者根本就没有经过过滤就放到了数据库中,一个恶意用户提交的Html代码被其它浏览该网站的用户访问,通过这些Html代码也就间接控制了浏览者的浏览器,就可以做很多的事情,如:窃取敏感信息、引导访问者的浏览器去访问恶意网站等。
1.6 跨站攻击的危害
Cross-Site Scripting(XSS)是一类注入问题,恶意脚本被注入到健康的、可信任的网站。当一个攻击者通过一个网站应用程序,以浏览器端脚本的形式,给另一端的用户发送恶意代码时,XSS攻击就发生了。攻击者使用XSS发送恶意脚本给一个不持怀疑态度的用户,用户端的浏览器没法知道脚本可不可信,从而执行该Javascript脚本。因为浏览器认为该脚本来自于一个可信赖的网站,导致恶意脚本可以访问任何cookies信息、会话令牌、或者其他由浏览器保存的但由那个网站使用的敏感信息,甚至可以修改当前网页内容。
1、盗取各类用户帐号,如机器登录帐号、用户网银帐号、各类管理员帐号
2、控制企业数据,包括读取、篡改、添加、删除企业敏感数据的能力
3、盗窃企业重要的具有商业价值的资料
4、非法转账
5、强制发送电子邮件
6、网站挂马
7、控制受害者机器向其它网站发起攻击
1.7 跨站攻击的分类
跨站攻击基本可以分为以下几类:
1、持久型XSS,又称存储型XSS。
2、非持久型XSS,又称反射型XSS。
3、DOM-XSS,DOM(文档对象模型)。
持久型的XSS较第二、第三种XSS攻击的危害较大。
1、持久型XSS——最直接的危害类型
持久型XSS(Persistent)又叫做存储XSS(Stored XSS)或I-型XSS,它是指通过提交恶意数据到存储器(比如数据库、文本文件等),Web应用程序输出的时候是从存储器中读出恶意数据输出到页面的一类跨站脚本漏洞。注入的脚本被永久的存储在了目标服务器中,比如数据库、论坛帖子、访问日志、留言评论等,除非数据库被重置或者恶意语句被人工删除。受害者向服务器请求获取存储的信息时,就获得了这些恶意脚本。
持久型XSS多出现在Web邮箱、BBS、社区等从数据库读出数据的正常页面(比如BBS的某篇帖子中可能就含有恶意代码),由于不需要浏览器提交攻击参数,所以其危害往往大于非持久型XSS。存储型XSS脚本攻击最为常见的场景就是在博客或新闻发布系统中,黑客将包含有恶意代码的数据信息直接写入文章或文章评论中,所有浏览文章或评论的用户,都会在他们客户端浏览器环境中执行插入的恶意代码。
存储型XSS脚本攻击是指Web应用程序会将用户输入的数据信息保存在服务端的数据库或其他文件形式中,网页进行数据查询展示时,会从数据库中获取数据内容,并将数据内容在网页中进行输出展示,因此存储型XSS具有较强的稳定性。
攻击过程如下:
Bob拥有一个Web站点,该站点允许用户发布信息/浏览已发布的信息。
Charly注意到Bob的站点具有类型C的XSS漏洞。
Charly发布一个热点信息,吸引其它用户纷纷阅读。
Bob或者是任何的其他人如Alice浏览该信息,其会话cookies或者其它信息将被Charly盗走。
2、非持久型XSS——反射型跨站脚本漏洞,最普遍的类型。
非持久型XSS(Non-persistent)又叫做反射XSS(Reflect XSS)或II-型XSS,它是指那些浏览器每次都要在参数中提交恶意数据才能触发的跨站脚本漏洞。
注入脚本从网站服务器被反弹回来,比如错误消息、搜索结果、或者任何其他响应(这些响应完全或部分包含了用户在浏览器输入的内容)。
该类型只是简单地将用户输入的数据直接或未经过完善的安全过滤就在浏览器中进行输出,导致输出的数据中存在可被浏览器执行的代码数据。由于此种类型的跨站代码存在于URL中,所以黑客通常需要通过诱骗或加密变形等方式,比如通过邮件或聊天软件,将存在恶意代码的链接发给用户,只有用户点击以后才能使得攻击成功实施。当用户被引诱点击恶意链接,提交一个特别构造的表单、或浏览一个恶意站点,注入脚本传送到了脆弱站点并反射给用户的浏览器,浏览器认为该链接来自一个可信的服务器就执行了它。主要用来窃取cookie。
一般来说,凡是通过URL传入恶意数据的都是非持久型XSS。
攻击过程如下:
Alice经常浏览某个网站,此网站为Bob所拥有。Bob的站点运行Alice使用用户名/密码进行登录,并存储敏感信息(比如银行帐户信息)。
Charly发现Bob的站点包含反射性的XSS漏洞。
Charly编写一个利用漏洞的URL,并将其冒充为来自Bob的邮件发送给Alice。
Alice在登录到Bob的站点后,浏览Charly提供的URL。
嵌入到URL中的恶意脚本在Alice的浏览器中执行,就像它直接来自Bob的服务器一样。此脚本盗窃敏感信息(授权、信用卡、帐号信息等)然后在Alice完全不知情的情况下将这些信息发送到Charly的Web站点。
3、DOM-XSS——客户端脚本处理逻辑导致的安全问题
DOM是Document Object Model(文档对象模型)的缩写。据W3C DOM规范(/DOM/),DOM是一种与浏览器、平台、语言无关的接口,使得你可以访问页面其他的标准组件。
简单理解,我们把DOM认为是JavaScript输出的页面,基于DOM的跨站脚本漏洞就是出现在JavaScript代码中的漏洞。
DOM型XSS又称0-型xss。攻击者提交的恶意数据并未显式的包含在web服务器的响应页面中,但会被页面中的JavaScript脚本以变量的形式来访问到,导致浏览器在渲染页面执行JavaScript脚本的过程中,通过DOM操作执行了变量所代表的恶意脚本。这种也被归类为‘client-side xss’。前两类xss攻击中,服务器的响应页面中显式的包含了恶意内容,被归类为‘server-side xss’。
以下是一段存在DOM类型跨站脚本漏洞的代码:
< script>
();
< /script>
在JavaScript中是指URL中?之后的内容,是将内容输出到页面。于是,又是一个直接输出到页面的跨站脚本漏洞。好,来构造攻击URL:
localhost/?
但是查看网页源代码,源代码却没变。
这就是DOM,在浏览器的解析中改变页面结构。这种特性检测DOM的跨站脚本漏洞带来了一点麻烦,因为它不能通过页面源代码来判断漏洞,给自动化漏洞检测带来了挑战。
基于DOM的XSS跨站脚本攻击是通过修改页面DOM节点数据信息而形成的XSS跨站脚本攻击。不同于反射型XSS和存储型XSS,基于DOM的XSS跨站脚本攻击往往需要针对具体的javascript DOM代码进行分析,并根据实际情况进行XSS跨站脚本攻击的利用。
1.8 跨站攻击的方式
跨站攻击是一种较为简单的攻击模式,在使用中,通常可以划分为以下两种攻击方式。
1、 内跨站(来自自身的攻击):主要指的是利用程序自身的漏洞,构造跨站语句,如:dvbbs的存在的跨站漏洞。
2、 外跨站(来自外部的攻击):主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点,我们自己构造一个有跨站漏洞的网页放在自己的服务器上,然后构造跨站语句,通过结合其它技术,如社会工程学等,欺骗目标服务器的管理员打开。这一类攻击的威胁相对较低,至少ajax 要发起跨站调用是非常困难的(你可能需要hack浏览器)。
2 跨站攻击的应用
2.1 基本应用
1. 网络钓鱼,包括盗取各类用户账号;
2. 窃取用户cookies资料,从而获取用户隐私信息,或利用用户身份进一步对网站执行操作,如进行不当的投票活动等;
3. 劫持用户(浏览器)会话,从而执行任意操作,例如进行非法转账、强制发表日志、发送电子邮件等;
4. 强制弹出广告页面、刷流量等;
5. 网页挂马;
6. 进行恶意操作,例如任意篡改页面信息、删除文章等;
7. 进行大量的客户端攻击,如DDoS攻击(分布式拒绝服务攻击)攻击;
8. 获取客户端信息,例如用户的浏览历史、真实IP、开放端口等;
9. 控制受害者机器向其他网站发起攻击;
10. 结合其他漏洞,如CSRF漏洞,实施进一步作恶;
11. 提升用户权限,包括进一步渗透网站;
12. 传播跨站脚本蠕虫等;
13. 利用植入Flash,通过crossdomain权限设置进一步获取更高权限;或者利用Java等得到类似的操作。
……
2.2 XSS攻击实例
为了搜集用户信息,攻击者通常会在有漏洞的程序中插入 JavaScript、VBScript、 ActiveX或Flash以欺骗用户。一旦得手,他们可以盗取用户帐户,修改用户设置,盗取/污染cookie,做虚假广告等。每天都有大量的XSS攻击的恶意代码出现。
(一)跨站脚本攻击三部曲
注入。所有HTML注入范例只是注入一个JavaScript弹出式的警告框:alert(1)。
2.做坏事。如果您觉得警告框还不够刺激,当受害者点击了一个被注入了HTML代码的页面链接时攻击者能作的各种的恶意事情。
3.诱捕受害者。
(二)跨站脚本攻击事件
“微博病毒”攻击事件
回顾:
2011年6月28日晚,新浪微博出现了一次比较大的XSS攻击事件。大量用户自动发送诸如:“郭美美事件的一些未注意到的细节”,“建党大业中穿帮的地方”,“让女人心动的100句诗歌”,“3D肉团团高清普通话版种子”,“这是传说中的神仙眷侣啊”,“惊爆!范冰冰艳照真流出了”等等微博和私信,并自动关注一位名为hellosamy的用户。
事件的经过线索如下:
20:14,开始有大量带V的认证用户中招转发蠕虫
20:30,某网站中的病毒页面无法访问
20:32,新浪微博中hellosamy用户无法访问
21:02,新浪漏洞修补完毕
“微博病毒”攻击事件分析
一、事件经过:
6月28日20时14分左右开始,新浪微博出现了一次比较大的XSS攻击事件。大量用户自动发送诸如:“郭美美事件的一些未注意到的细节”,“建党大业中穿帮的地方”,“让女人心动的100句诗歌”,“3D肉团团高清普通话版种子”,“这是传说中的神仙眷侣啊”,“惊爆!范冰冰艳照真
流出了”“ 可以监听别人手机的软件”等微博和私信,并自动关注一位名为hellosamy的用户。
很多微博用户在短时间内收到 N多条私信,链接都是:
/pub/star/g/xyyyd">
会影响到新浪微博的评论、翻页等基本功能。涉及攻击包括加关注、发微博、发私信等功能。
事件的效果:
以及
事件的经过线索如下:
20:14,开始有大量带V的认证用户中招转发蠕虫
20:30,中的病毒页面无法访问
20:32,新浪微博中hellosamy用户无法访问
21:02,新浪漏洞修补完毕
影响有多大:32961(hellosamy在帐号被封前的好友数量)。
新浪声称:基本定位了这次攻击的原因,微博广场页面 /pub/star
有XSS漏洞,被植入了恶意JS脚本。初步发现 Chrome 和 Safari 都没中招。IE、Firefox未能幸免。
二、采用了什么样的攻击方法
1、利用了新浪微博存在的XSS漏洞;
XSS分两种:
一种是「永久」的,常见的情况是输入框中的问题不进行过滤(strip tags),导致script这种危险标签会被显示出来,别人访问这个页面,脚本会被执行。这种非常严重,类似于今年人人网受到的XSS攻击,当时人人网整个站内信系统崩溃。
第二种是「反射」的,就像这次新浪微博,原因是某些网页的JS编写不是很规范,导致网址可以嵌入一个脚本执行。一般认为这种危险系数较低,但是由于社交网络的特性,导致本身不高的危险,通过关系网被放大。
2、使用有道提供的短域名服务(这些网址目前已经“无害”);
例如,通过/PxZHoxn,将链接指向:
/pub/star/g/xyyyd">
3、当新浪登陆用户不小心访问到相关网页时,由于处于登录状态,会运行这个js脚本做几件事情:
a.发微博(让更多的人看到这些消息,自然也就有更多人受害);
b.加关注,加uid为2201270010的用户关注——这应该就是大家提到的hellosamy了;
c.发私信,给好友发私信传播这些链接;
分析如下:
脚本 /images/(但目前已被清空)
XSS代码:/pub/star/g/xyyyd">
三、本次蠕虫事件中的代码下载
代码截图如下:
2.3 其他实例应用
•
劫持访问
劫持访问就是在恶意脚本中插入诸如的代码,那么页面就会跳转到百度首页。劫持访问在持久型和非持久型XSS中都比较常被利用。持久型XSS中劫持访问的危害不用说大家都清楚,但有人会问非持久型XSS中劫持访问有什么作用呢?很简单,试想下像,这样的域名下出现非持久型XSS,那么在发送钓鱼链接时就可以通过等域名进行跳转,一般人一看到之类的域名警惕性会下降,也就更容易上当了。
•
盗用cookie实现无密码登录
具体原理上文已经提到,这里做一个具体演示。由于盗取的cookie需要传回给攻击者,因此往往需要一个服务器来接收盗取的cookie,这也就是xss平台的作用了。网上的xss平台很多,但动手搭建一个也不难,建议有条件的自己搭建。
首先登录平台后台获取到js脚本地址为127.0.0.1/XSS/template/,所以我们需要做的是把这段代码植入指定页面。
(这里以DVWA渗透测试平台为例)
我们发现网页对于message长度有限制。审查元素看一下。
发现最大长度有限制,但这仅仅是前端的限制,直接双击修改成更大的数字即可。再次尝试,没问题,我们已经将脚本植入完毕。
然后就是坐等别的用户访问这个界面。
这时,另一个用户gordonb登录并访问了留言界面,那么他的cookie就会被窃取。我们可以从xss平台的后台获取到。
拿到cookie之后要登录他的帐号就好办了。
打开登录界面,调出火狐的firebug插件,调至cookie选项卡(注意,如果你的firebug插件没有cookie选项卡,请再安装firecookie插件即可看到)
然后依次点击cookies-create cookie,随后再弹出的界面中填入两个xss平台获取到的cookie,如图
这里注意要把我箭头所指的地方勾上,这是设置cookie有效期的地方,不然会在设置完下一秒cookie就失效。
完成之后再次刷新页面,发现已经不是之前的登录界面了,而是登录后的界面。至此,一个从cookie窃取到利用的过程就已完成。
•
配合csrf攻击完成恶意请求
先简单解释以下csrf攻击。Csrf攻击就是在未经你许可的情况下用你的名义发送恶意请求(比如修改密码,银行转账等),下面演示一个用xss配合csrf修改用户密码的例子。
首先对修改用户密码的界面进行抓包。
发现没有对原密码进行校验。于是一股邪恶的力量油然而生:要是在xss的恶意脚本中自动提交get请求修改密码的话。。。
说干就干,具体插入语句如下。
有人会问,这不是引用脚本吗?其实不然,本质上这还是发起了一起get请求,因此可以直接使用。与上例一样,插入到message中,再坐等上钩。等下一个用户访问该界面时,密码就会被改为123456。
我们再看下访问该页面时的抓包情况,发现每次访问该页面都发送了更改密码的请求
效果看数据库(密码md5加密)
访问了该页面的用户密码都被更改了。
3 跨站攻击的防范
3.1 防范方法
跨站攻击相对于其他网络攻击而言显得更隐蔽,也更难防范。有时问题并不出在用户身上,而是由于网站的问题。即使安装了防火墙,也对跨站攻击无能为力,因此防范跨站攻击需要程序员方面和个人用户两方面入手,以下就可以防范大部分的跨站攻击。
程序员:
1. 过滤特殊字符
对网站程序过滤特殊字符,这是防范跨站脚本攻击最为有效和彻底的方法。在不影响网站程序正常运行的前提下,可在网站程序的表单输入过滤掉"javascript"、"*********%22%3E%3Cscript%3Ealert()%3C%2Fscript%3E为了保证注入的数据被提交,通常需要暂时禁用浏览器的js代码执行、或在本地代理的http编辑器中修改请求的原始数据。
但是提交后,可能被网站应用程序过滤,比如script被替换成了空格或者空串,这就是一个潜在的过滤信号,当然有很多规避过滤的技术。
4、利用存储的注入代码
存储的恶意代码可以被高级js利用框架利用,比如beef、xss-proxy、backframe。
一个典型的beef利用场景涉及:
- 注入一段js钩子代码,可以与攻击者的浏览器利用框架通信
- 等待网站用户访问漏洞页面
- 通过beef控制台控制网站用户的浏览器
beef可以访问用户的cookies、屏幕截图、剪贴板、以及发起更复杂的xss攻击。如果这个漏洞页面会被拥有不同权限的用户访问,那么这个攻击是相当有效的。
5、文件上传
如果网站应用允许文件上传,需要检测下是否可以上传html内容。如果html或txt文件被允许,那么xss负载就可以被注入。
渗透测试人员应该验证是否这个上传点允许设置任意的MIME类型。这个设计缺陷允许浏览器的MIME误处理攻击。比如,看起来无害的JPG和GIF文件包含xss负载,可能在被浏览器载入的时候得到执行。这个是可能的,当本应设置MIME为image/gif时却设置为text/html。
这种情况下,文件被客户端浏览器创建为HTML。
伪造POST请求:
Content-Disposition: form-data; name="uploadfile1";
filename="C:Documents and "
Content-Type: text/html
4.2 反射型XSS测试
4.2.1 概述
反射型注入攻击发生在用户打开一个恶意构造的链接或第三方网页,攻击字符串包含在构造的url中或者是http参数中,web应用没有适当的处理并返回给受害者。
反射型的攻击负载通过单一的请求和响应被传递和执行。如果一个网站存在xss缺陷,它会将请求中附带的参数不经验证的回传给客户端。
这种攻击最常见的做法分两步:设计,攻击者创建和测试构造的恶意链接;社会工程学,确信受害者会通过浏览器加载这个url并最终执行。
通常,攻击代码使用js编写,但其他语言比如action script、vb script等也会用到。攻击者可以安装键盘记录器、窃取cookies、粘贴板、改变页面内容(比如下载链接)。
预防xss漏洞的主要难点之一是合适的字符编码。一些情况下,web服务器不能过滤某些字符编码,比如可以过滤‘
-/?user=
-
标签属性值
value="INPUT_FROM_USER">
-
" onfocus="alert()
不同的语法或编码
">
"%3cscript%3ealert()%3c/script%3e
-
绕过正则过滤
模式串 $re = "/
- HTTP parameter pollution
//Testing_for_HTTP_Parameter_pollution_(OTG-INPVAL-004)
http参数污染,查询字符串或表单提交的参数中某个同名参数出现了多次,apache等web服务器解析协议参数时的方式各异,网站应用程序的各个组件所使用的参数值不一致。
4.3 DOM型XSS测试
4.3.1 概述
DOM型跨站脚本事实上是浏览器端的动态内容所引起的xss bug。典型的,比如js,获取用户输入并用它做了一些不安全的事情导致注入代码被执行。
DOM,全称为Document Object Model,是一种结构化的格式,被用来表达浏览器中的文档。DOM允许动态脚本,比如js,来引用文档中的组件,比如表单字段、或会话令牌。DOM也被浏览器来实现安全策略,比如同源策略限制跨域DOM操作。当动态内容,比如js函数被一个构造的请求修改,dom元素可以被攻击者控制,从而形成xss漏洞。
4.3.2 如何测试
不是所有的xss bug都需要攻击者去控制从服务器返回的动态页面,但是泛滥的愚蠢的js编码会导致同样的结果。
与其他类型的xss漏洞(服务器未清理用户提交的参数,回传给用户浏览器端并得到执行)相比,dom-xss 可以控制代码的执行流程。
大多数情况下,dom-xss可以在服务端不知情的情况下执行。比如:
攻击者追加#到页面的url后面,当执行时会弹窗。这个例子中,追加的代码不会被发送到服务端,因为#后面的字符串根本没有被浏览器当做查询字符串的一部分,而是作为一个锚标记,因而无需和服务器取得联系。
dom-xss的攻击后果和其他更知名的xss攻击一样广泛,cookies获取、更进一步的恶意脚本注入,所以应该被划分到同样的严重等级。
一、黑盒测试
dom-xss的黑盒测试是不必要的,因为前端的源码总是可见的,浏览器需要从服务端那获取并执行。
二、灰盒测试
js应用程序和其他的应用程序有显著的区别,因为他们是由服务端动态产生的,为了理解什么代码正在被执行,测试者需要爬行站点来判定正在被执行的脚本和哪些地方是接收用户输入的。许多站点依赖大量的库函数,伸展开后有成百上千行代码并且不是内部开发的。这种情况下,自顶向下的测试常常是唯一可行的选择,因为许多底层的函数从没用到过,从中分析哪些是弱点耗费太多时间。对于自顶向下测试,是否能识别哪些地方接收用户输入同样至关重要。
用户输入来源有两种形式:
- 服务端动态写入,不允许直接的xss
- 客户端脚本对象中获取的变量
下面是服务端插入数据到js脚本中的两个例子:
var data = "
var result = someFunction("
下面是从客户端js对象中获取输入的两个例子:
var data = on;
var result = someFunction(r);
对于js代码来说,两种获取输入的方式基本没有差异,重要的是当从服务端获取输入时,服务端能对数据应用任何的排列组合,而js对象中获取的输入却很好理解。所以,如果上例中的js函数是弱点的话,前例中的漏洞利用依赖服务端的过滤,后例中的利用依赖于浏览器对r对象的编码。
另外,js脚本也常常会在script标签外部执行,过去许多的攻击向量都导致了xss攻击已经证实了这一点。所以,在爬行站点时,留意诸如‘事件处理器’、‘带有expression属性的css语句块’等这些地方的代码是很重要的。自动化测试在识别和验证dom-xss漏洞时是很弱的,因为他仅仅是发送特定的负载并尝试审查服务器响应的页面。这个可能在一些简单的例子中工作得比较好,比如那些参数被反射回给用户的情况:
但是下面不自然的例子无法被检测到:
基于这样的原因,自动化测试通常无法检测dom-xss漏洞,除非测试工具能对客户端脚本执行额外的分析。
人工测试应该进行,检查某些代码区域,那些区域中的参数对攻击者而言是有用的。比如,代码被动态写到页面、dom树被修改、甚至脚本被直接执行。
("You are using an unknown browser.");
版权声明:本文标题:XSS完整版论文 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://roclinux.cn/p/1707283245a513607.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论