用户
搜索
  • TA的每日心情
    开心
    昨天 11:54
  • 签到天数: 69 天

    连续签到: 14 天

    [LV.6]常住居民II

    i春秋作家

    Rank: 7Rank: 7Rank: 7

    8

    主题

    31

    帖子

    1235

    魔法币
    收听
    0
    粉丝
    3
    注册时间
    2018-6-2

    i春秋签约作者

    发表于 2020-9-2 10:46:29 37613
    本帖最后由 dll_s 于 2020-9-2 10:46 编辑

    0x21 Burpsuite练兵场-CSRF(二)

    接上一篇,这一篇中的csrf利用稍微复杂了些

    实验一:Token关联到非会话cookie

    实验提示:应用程序 email change模块存在CSRF漏洞,启用了token防护,但是并未将csrf令牌防护整合到会话管理中

    实验要求:构造CSRF利用代码并上传到exploit server中

    img

    这里如果看了BP学院中的相关说明,就会明白它的原理,下面跟随实验进行讲解

    分别使用提供的两个账号进行登录,并使用email change功能,观察这两个请求报文

    img

    img

    可以发现,cookie中的seesion字段值发生了改变,但csrfKey字段以及csrf字段值均未变化

    这说明什么含义呢:session负责会话管理,根据不同账户刷新字段值;csrfKey以及csrf用于防范csrf攻击,可能是根据浏览器会话或者是IP地址更新值

    这从某种角度来说也是可以成功防范csrf攻击的,因为我们无法构造POC对Cookie中的csrfKey参数进行单独操纵

    但是在这个web应用中,还存在另一个利用点,在home页面的搜索框中存在注入点,让我们来观察一下请求流

    img

    可以看到,我们的输入触发了服务器的Set-cookie操作,将搜索参数LastSearchTerm=123附加到了Cookie中

    因此就可以构造输入,将csrfKey参数注入到受害者的访问会话中

    需要注入的内容
    test
    Set-Cookie: csrfKey=oTUybWBc3MlhcrCkNTqy8tPpJI62V6hg
    经过URL编码
    test%0D%0ASet-Cookie%3A%20csrfKey%3DoTUybWBc3MlhcrCkNTqy8tPpJI62V6hg

    同样,使用Burpsuite自动生成CSRF POC,然后修改javascript自动提交代码,通过图片方式构造有效POC

    <img src="https://ac391fd21f1b1d0a802d0871007400a9.web-security-academy.net/?search=test%0D%0ASet-Cookie%3A%20csrfKey%3DoTUybWBc3MlhcrCkNTqy8tPpJI62V6hg" onerror="document.forms[0].submit()">

    <img>标签会先请求src中的地址,成功注入csrfKey,之后由于图片地址不存在执行onerror中的js代码提交表单

    img

    将POC保存到exploit server中完成实验

    点击View exploit可以进行验证,观察流可以看到成功注入了csrfKey字段

    img

    实验二:利用Token双重提交防范CSRF

    实验提示:应用程序 email change模块存在CSRF漏洞,应用程序使用的"double submit"(双重提交)防护存在问题

    实验要求:构造CSRF利用代码并上传到exploit server中

    img

    这里提到了一个double submit防范方式,其具体原理为:web应用不维护已发出令牌的任何服务器端记录,而是在一个cookie和一个请求参数中复制每个令牌,在验证后续请求时,应用程序只需验证在请求参数中提交的令牌是否与在cookie中提交的值匹配,这样一来就避免了任何服务器端状态的需要,因此也是一种不错的实现方式

    然而在这个实验环境中之所以能够进行CSRF攻击,是因为与上一个实验一样,搜索框中存在注入点,我们可以注入想要的Cookie头中的csrf字段

    所以前面的操作流程大致相似,利用Burpsuite生成POC,不同点在于注入点的代码

    需要注入的内容
    test
    Set-Cookie: csrf=nN0hiejOg5KXMbn4N94PiDfzuzZbWnhN
    经过URL编码
    test%0ASet-Cookie%3A%20csrf%3DnN0hiejOg5KXMbn4N94PiDfzuzZbWnhN

    <img>标签构造

    <img src="https://ac771f4b1fc23bf1809447d500330029.web-security-academy.net/?search=test%0ASet-Cookie%3A%20csrf%3DnN0hiejOg5KXMbn4N94PiDfzuzZbWnhN" onerror="document.forms[0].submit()">

    img

    将POC保存到exploit server完成实验

    实验三:默认Referer头存在导致CSRF攻击

    实验提示:应用程序email change模块存在CSRF漏洞

    实验要求:构造CSRF利用代码并上传到exploit server中

    img

    什么叫做基于Referer头的防范呢,HTTP报文中的Referrer 头大家应该都熟悉,它会显示当前文档的来源文档的URL,所以程序可以通过判断该值是否为所要求的URL来防范csrf攻击。但是一些web程序会默认此头存在,以此导致如果我们删除了referer头,判断逻辑就会失效,csrf攻击仍然可以成功执行

    知道了原理,实验就好操作了

    同样登录账户,来到email change页面修改邮箱,并根据报文生成CSRF POC

    我们通过 <meta> 标签来指定 Referrer 策略,将如下代码插入到poc中,以达到去掉Referer头的效果

    <head>
    <meta name="referrer" content="no-referrer">
    </head>

    img

    将POC保存到exploit server完成实验

    关于插入代码的详细原理可以查看这篇文章:Referrer Policy 介绍

    实验四:Referer验证失效导致CSRF攻击

    实验提示:应用程序email change模块存在CSRF漏洞,虽然程序尝试检测并阻止跨站请求但仍然可以被绕过

    实验要求:构造CSRF利用代码并上传到exploit server中

    img

    这一实验中,web对Referer进行了验证,但是验证方式存在逻辑漏洞

    一些应用程序以一种可以绕过的简单方式验证Referer头。例如,如果应用程序只是验证Referer是否包含自己的域名,则攻击者可以将所需的值放在URL中的其他位置

    http://attacker-website.com/csrf-attack?vulnerablewebsite.com

    如果应用程序验证Referer中的域以预期值开始,则攻击者可以将其作为自己域的子域

    http://vulnerablewebsite.com.attacker-website.com/csrf-attack

    了解了验证机制问题,我们就可以着手进行突破了

    https://acbd1fa31ed4a32f804b0be500dc0085.web-security-academy.net   #这是正常email-change报文中有效的referer值
    https://ac851fb31fcd35a380b9005b01420064.web-security-academy.net   #这是我们的exploit server地址

    这里可以尝试能否使用<img>改变Referer源

    <img src="https://acbd1fa31ed4a32f804b0be500dc0085.web-security-academy.net/email" onerror="document.forms[0].submit()">

    验证可以发现Referer值仍然为我们的exploit server地址,更改失败

    这里就要用到一个新的技巧

    history.pushState(state, title[, url]) 用于插入一条历史记录

    history.pushState(state, title[, url])
    state:javascript对象,与pushState所创建的条目相关联,传入的值可以是任何可序列化对象
    title:大多数浏览器目前忽略这个参数,建议传递空字符串
    url:传递的值必须与当前url同域,可以使用相对于当前url的相对路径

    这一函数的作用其实在之前就已经可以初见端倪

    观察这个报文流,你是否会感觉很奇怪,为什么图中标黄的报文Referer值并不是/exploit路径

    img

    没错,原因就是因为我们利用POC插入了一条历史记录使得Referer值也随之更改

    img

    注意:这一函数是存在跨域限制的,即我们只能插入exploit server域的地址,所以我们的构造方式是这样

    history.pushState('', '', '/?acbd1fa31ed4a32f804b0be500dc0085.web-security-academy.net')

    通过将正确的Referer值附着到exploit server域后以此欺骗验证以实施成功的csrf攻击

    img

    将POC保存到exploit server完成实验

    总结


    CSRF的实验到这里就结束了,通过实验我们也基本可以总结出如何有效的防范此类攻击

    • 使用Token,注意需要保证Token的不可预测性以及会话关联性
    • 也可以利用文所描述的中double submit机制
    • 验证Referer头,注意不要使用简单验证
    • 不要忽略任何验证参数不存在的情况,以及任何不同的请求方式
    排版不错,阅读起来挺舒服的
    使用道具 举报 回复
    发表于 2020-9-2 17:56:46
    history.pushState这个操作很6
    使用道具 举报 回复
    使用道具 举报 回复
    发新帖
    您需要登录后才可以回帖 登录 | 立即注册