token为什么能防止csrf_「Burpsuite练兵场」CSRF（二）

Burpsuite练兵场系列文章更新啦，今天的内容是延续上期关于CSRF的内容介绍，感兴趣的小伙伴千万别错过了呦！

上期回顾

「Burpsuite练兵场」CSRF(一)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

标签构造

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

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

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

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

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

知道了原理，实验就好操作了。同样登录账户，来到email change页面修改邮箱，并根据报文生成CSRF POC，我们通过 标签来指定 Referrer 策略，将如下代码插入到poc中，以达到去掉Referer头的效果。

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

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

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

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

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

这一实验中，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地址

这里可以尝试能否使用改变Referer源。

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

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

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

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

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

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

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

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

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

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

将POC保存到exploit server完成实验

总结

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

• 使用Token，注意需要保证Token的不可预测性以及会话关联性；
• 也可以利用文所描述的中double submit机制；
• 验证Referer头，注意不要使用简单验证；
• 不要忽略任何验证参数不存在的情况，以及任何不同的请求方式。

今天的文章分享，小伙伴们看懂了吗？