web漏洞挖掘指南 CSRF跨站请求伪造一、CSRF的漏洞原理以及攻击过程顾名思义，CSRF跨站请求伪造是一种伪造受害者的请求以达成某种目的的攻击手法，本质上我将其理解为攻击者像操控木偶一样让受害者做各种敏感操作，以你的名义修改个人信息、添加管理员、重置密码等。 CSRF的攻击过程（以重置密码操作为例）：攻击者编写自动提交密码重置请求的恶意html代码→确认受害者处于登陆状态时诱导其访问恶意页面→攻击页面自动提交表单要求发出密码重置请求，浏览器接收到后在用户不知情的情况下携带用户cookie→目标网站收到请求后响应成功，密码被修改。二、CSRF漏洞检测从CSRF漏洞的产生原理看，关键点在于攻击者是否能伪造出请求包，一般的web请求本质上来说都可以被复制，但是也有特殊情况导致无法伪造请求：网站不使用cookie进行身份验证，而是添加Authorization请求头来识别用户，比如basic认证、digest认证等。攻击者如果获取不到Authorization对应值，也就无法构造正确的请求包。敏感请求添加了难以猜解的字段。比如重置密码时需要验证的原密码，修改个人配置信息时需要输入的图形验证码，添加管理员时在url中加入的随机校验值：token、sign等。攻击者如果无法事先获取到这类校验值，请求就会失败。构造好请求包之后，下一步就是将写好的恶意页面发给受害者了，先测试将请求包中的refer头删除，如果请求失败了，这时可能还需要过一层refer的校验。referer是http请求头的一部分，当浏览器向web服务器发送请求的时候，一般会带上referer，告诉服务器我是从哪个页面链接过来的，服务器借此可以获得一些信息用于处理。当存在refer校验时，web服务器识别出请求并不是白名单域名发出的，请求就会失败。常见的refer绕过技巧（web服务器：kevil.com）：有时后端对请求类型判断不是很严格，导致post请求改写为get请求，这样直接引导受害者访问敏感功能接口的链接即可尝试拿下kevil.com的二级域名权限，将恶意页面传至二级域名后端逻辑判断是否存在kevil.com关键字时，注册一个kevil.com.evil.com的域名，或者新建一个kevil.com的目录，这样refer就变成http://evil.com/kevil.com/poc.html，还可以将kevil.com当作参数传入： http://evil.com/poc.html?a=kevil.com。如果是通过正则对refer进行校验，也可参照： https://joychou.org/web/url-whitelist-bypass.html 中提及的绕过方法进行测试。尝试无refer是否可以请求成功，利用ftp://,http://,https://,file://,javascript:,data:这个时候浏览器地址栏是file://开头的，如果这个HTML页面向任何http站点提交请求的话，这些请求的Referer都是空的，比如使用data协议： <html> <body> <iframe src="data:text/html;base64,PGZvcm0gbWV0aG9kPXBvc3QgYWN0aW9uPWh0dHA6Ly9hLmIuY29tL2Q+PGlucHV0IHR5cGU9dGV4dCBuYW1lPSdpZCcgdmFsdWU9JzEyMycvPjwvZm9ybT48c2NyaXB0PmRvY3VtZW50LmZvcm1zWzBdLnN1Ym1pdCgpOzwvc2NyaXB0Pg=="> </body> </html> 也可插入标签<meta name="referrer" content="never"> 结合*.kevil.com域名下的url跳转、xss等漏洞绕过refer 三、CSRF漏洞利用综上所述，不难看出，要触发csrf漏洞需要两个条件：构造攻击页面伪造出正确的请求、没有refer限制或者可以绕开refer限制。任何http请求都可以用来测试csrf漏洞，如果是SRC漏洞挖掘，无敏感操作的csrf是无危害的，过滤掉这些无危害的请求再做漏洞验证。市面上有很多csrf测试工具，如CSRFTester，CSRF Request Builder等，csrf的测试相对来说较为简单，建议还是手工验证。GET请求的CSRF直接诱导受害者访问敏感功能对应的接口地址即可，POST请求的CSRF需要通过表单来提交参数，先使用burp对抓取敏感功能的请求包→右键生成csrf攻击代码：复制好攻击代码，将其保存到http://evil.com/1.html，模拟受害者操作，双击打开html文件查看请求是否可以成功，如果不成功还需要进一步绕过refer限制： 3.为了更好的利用CSRF，还可以加入一段js来完成表单的自动提交：四、CSRF与其他漏洞的组合拳攻击为了尽量提高CSRF漏洞的危害，我们还可以配合其他漏洞进行利用，比如： - CSRF蠕虫。案例可参考： https://www.cnblogs.com/milantgh/p/3654308.html - 无后台权限时，利用csrf+后台文件上传漏洞获取服务器权限 - 鸡肋的self-xss+csrf，利用csrf引导受害者自己传入xss payload，从而盗取用户cookie - 越权支付+csrf，可以越权支付时，配合csrf让受害者给自己支付

[未知] 如果没有refer字段也能成功响应，说明请求是没有refer校验的。对GET请求有refer验证的请求举例：攻击者在恶意网站上放上这个请求对应的链接，诱导受害者访问，这时referer字段是恶意网站的，此时referer验证不通过则无法实现原请求。不用referer字段也能成功响应的请求说明请求本身并没有对refer做验证

web漏洞挖掘指南 -CSRF跨站请求伪造

42227

web漏洞挖掘指南

CSRF跨站请求伪造

一、CSRF的漏洞原理以及攻击过程

顾名思义，CSRF跨站请求伪造是一种伪造受害者的请求以达成某种目的的攻击手法，本质上我将其理解为攻击者像操控木偶一样让受害者做各种敏感操作，以你的名义修改个人信息、添加管理员、重置密码等。
CSRF的攻击过程（以重置密码操作为例）：攻击者编写自动提交密码重置请求的恶意html代码→确认受害者处于登陆状态时诱导其访问恶意页面→攻击页面自动提交表单要求发出密码重置请求，浏览器接收到后在用户不知情的情况下携带用户cookie→目标网站收到请求后响应成功，密码被修改。

二、CSRF漏洞检测

从CSRF漏洞的产生原理看，关键点在于攻击者是否能伪造出请求包，一般的web请求本质上来说都可以被复制，但是也有特殊情况导致无法伪造请求：
- 网站不使用cookie进行身份验证，而是添加Authorization请求头来识别用户，比如basic认证、digest认证等。攻击者如果获取不到Authorization对应值，也就无法构造正确的请求包。
- 敏感请求添加了难以猜解的字段。比如重置密码时需要验证的原密码，修改个人配置信息时需要输入的图形验证码，添加管理员时在url中加入的随机校验值：token、sign等。攻击者如果无法事先获取到这类校验值，请求就会失败。
构造好请求包之后，下一步就是将写好的恶意页面发给受害者了，先测试将请求包中的refer头删除，如果请求失败了，这时可能还需要过一层refer的校验。referer是http请求头的一部分，当浏览器向web服务器发送请求的时候，一般会带上referer，告诉服务器我是从哪个页面链接过来的，服务器借此可以获得一些信息用于处理。当存在refer校验时，web服务器识别出请求并不是白名单域名发出的，请求就会失败。常见的refer绕过技巧（web服务器：kevil.com）：
- 有时后端对请求类型判断不是很严格，导致post请求改写为get请求，这样直接引导受害者访问敏感功能接口的链接即可
- 尝试拿下kevil.com的二级域名权限，将恶意页面传至二级域名
- 后端逻辑判断是否存在kevil.com关键字时，注册一个kevil.com.evil.com的域名，或者新建一个kevil.com的目录，这样refer就变成http://evil.com/kevil.com/poc.html，还可以将kevil.com当作参数传入：http://evil.com/poc.html?a=kevil.com。如果是通过正则对refer进行校验，也可参照：https://joychou.org/web/url-whitelist-bypass.html 中提及的绕过方法进行测试。
- 尝试无refer是否可以请求成功，利用ftp://,http://,https://,file://,javascript:,data:这个时候浏览器地址栏是file://开头的，如果这个HTML页面向任何http站点提交请求的话，这些请求的Referer都是空的，比如使用data协议：
```
        <html>
            <body>
               <iframe src="data:text/html;base64,PGZvcm0gbWV0aG9kPXBvc3QgYWN0aW9uPWh0dHA6Ly9hLmIuY29tL2Q+PGlucHV0IHR5cGU9dGV4dCBuYW1lPSdpZCcgdmFsdWU9JzEyMycvPjwvZm9ybT48c2NyaXB0PmRvY3VtZW50LmZvcm1zWzBdLnN1Ym1pdCgpOzwvc2NyaXB0Pg==">
            </body> 
        </html>
```
  也可插入标签<meta name="referrer" content="never">
- 结合*.kevil.com域名下的url跳转、xss等漏洞绕过refer

三、CSRF漏洞利用

综上所述，不难看出，要触发csrf漏洞需要两个条件：构造攻击页面伪造出正确的请求、没有refer限制或者可以绕开refer限制。任何http请求都可以用来测试csrf漏洞，如果是SRC漏洞挖掘，无敏感操作的csrf是无危害的，过滤掉这些无危害的请求再做漏洞验证。市面上有很多csrf测试工具，如CSRFTester，CSRF Request Builder等，csrf的测试相对来说较为简单，建议还是手工验证。GET请求的CSRF直接诱导受害者访问敏感功能对应的接口地址即可，POST请求的CSRF需要通过表单来提交参数，先使用burp对抓取敏感功能的请求包→右键生成csrf攻击代码：
复制好攻击代码，将其保存到http://evil.com/1.html，模拟受害者操作，双击打开html文件查看请求是否可以成功，如果不成功还需要进一步绕过refer限制：

3.为了更好的利用CSRF，还可以加入一段js来完成表单的自动提交：

四、CSRF与其他漏洞的组合拳攻击

为了尽量提高CSRF漏洞的危害，我们还可以配合其他漏洞进行利用，比如：
- CSRF蠕虫。案例可参考：https://www.cnblogs.com/milantgh/p/3654308.html
- 无后台权限时，利用csrf+后台文件上传漏洞获取服务器权限
- 鸡肋的self-xss+csrf，利用csrf引导受害者自己传入xss payload，从而盗取用户cookie
- 越权支付+csrf，可以越权支付时，配合csrf让受害者给自己支付

47148

师傅请教下一个问题，post请求改写为get请求绕过referer的校验，是不是因为攻击者发送了恶意的url给对方访问之后抓到的数据包中没有referer字段那么如果对方是基于对referer的校验是不是起不到作用也就可以可以绕过校验呢

42227

杰仔这个要看后端的校验逻辑。你上面这个请求不带refer响应成功的话，有可能是后端根本不校验refer，也有可能是当后端识别不到referer字段时跳过验证逻辑，也就是说绕过校验了。