「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参数注入到受害者的访问会话中。
需要注入的内容
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代码提交表单。
将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，不同点在于注入点的代码。
需要注入的内容
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()">
将POC保存到exploit server完成实验。
实验三：默认Referer头存在导致CSRF攻击
实验提示：应用程序email change模块存在CSRF漏洞。
实验要求：构造CSRF利用代码并上传到exploit server中。
什么叫做基于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>
将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地址这里可以尝试能否使用<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路径。
没错，原因就是因为我们利用POC插入了一条历史记录使得Referer值也随之更改。
注意：这一函数是存在跨域限制的，即我们只能插入exploit server域的地址，所以我们的构造方式是这样。
history.pushState('', '', '/?acbd1fa31ed4a32f804b0be500dc0085.web-security-academy.net')通过将正确的Referer值附着到exploit server域后以此欺骗验证以实施成功的csrf攻击。
将POC保存到exploit server完成实验
总结
CSRF的实验到这里就结束了，通过实验我们也基本可以总结出如何有效的防范此类攻击：
- 使用Token，注意需要保证Token的不可预测性以及会话关联性；
- 也可以利用文所描述的中double submit机制；
- 验证Referer头，注意不要使用简单验证；
- 不要忽略任何验证参数不存在的情况，以及任何不同的请求方式。
今天的文章分享，小伙伴们看懂了吗？
