CSRF漏洞初解
1.什么是CSRF漏洞
CSRF（Cross-Site Request Forgery）漏洞是一种Web应用程序安全漏洞，也被称为"One-Click Attack"或"Session Riding"。它利用了Web应用程序对用户在其他网站上已经验证过的身份的信任，通过伪装请求来执行非授权的操作
可以通俗的理解为：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等
2.CSRF漏洞的原理和流程
CSRF攻击利用了Web应用程序对用户在该应用程序中已经建立的会话的信任。攻击者构造恶意网站或链接，诱使受害者在另一个网站上进行操作，例如点击一个链接或提交一个表单。如果受害者已经在目标网站上建立了有效的身份验证会话，那么他们的浏览器将自动包含相应的身份验证凭据（例如cookie）在请求中，当受害者点击恶意链接时，他们的浏览器会发送一个包含恶意操作请求的请求，例如更改密码、发布消息或执行其他敏感操作。由于浏览器会自动包含目标网站的身份验证凭据，目标网站会误认为请求是合法的，然后执行相应的操作
CSRF攻击攻击原理及过程如下：
- 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A
- 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A
- 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B
- 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A
- 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行
3.CSRF漏洞的分类
3.1 GET型
如果一个网站某个地方的功能，比如用户修改邮箱是通过GET请求进行修改的。如：/user.php?id=1&email=123@163.com ，这个链接的意思是用户id=1将邮箱修改为123@163.com。当我们把这个链接修改为 /user.php?id=1&email=abc@163.com ，然后通过各种手段发送给被攻击者，诱使被攻击者点击我们的链接，当用户刚好在访问这个网站，他同时又点击了这个链接，那么悲剧发生了。这个用户的邮箱被修改为 abc@163.com 了
3.2POST型
在普通用户的眼中，点击网页->打开试看视频->购买视频是一个很正常的一个流程。可是在攻击者的眼中可以算正常，但又不正常的，当然不正常的情况下，是在开发者安全意识不足所造成的。攻击者在购买处抓到购买时候网站处理购买(扣除)用户余额的地址。比如：/coures/user/handler/25332/buy.php 。通过提交表单，buy.php处理购买的信息，这里的25532为视频ID。那么攻击者现在构造一个链接，链接中包含以下内容
<form action=/coures/user/handler/25332/buy method=POST>
<input type="text" name="xx" value="xx" />
</form>
<script> document.forms[0].submit(); </script>
当用户访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作，自动购买了id为25332的视频，从而导致受害者余额扣除
4.CSRF漏洞挖掘
4.1缺少CSRF保护（Lack）
最简单的漏洞类型，没有任何针对CSRF的防护，也是挖掘中最常见的情形：关注每一个关键操作的请求包，若参数中没有CSRF令牌参数，篡改referer仍然返回正常，则大概率存在CSRF漏洞
4.2CSRF防护绕过（Bypass）
4.2.1Referer绕过
- 空referer绕过：其他协议（data：）或https跳http
- 包含referer：若只检查是否包含网址，只需在我们的网站上创建一个文件/文件夹即可，如https://www.yoursite.com/https://www.theirsite.com/
4.2.2CSRF-token绕过
-
删除令牌：删除cookie/参数中token，免服务器验证
-
令牌共享：创建两个帐户，替换token看是否可以互相共用；
-
篡改令牌值：有时系统只会检查CSRF令牌的长度；
-
解码CSRF令牌：尝试进行MD5或Base64编码
-
修改请求方法：post改为get
-
窃取token：重定向、XSS、web缓存欺骗、clickjacking等都可能导致token泄露
5.CSRF漏洞的防御
-
在表单提交时增加token验证：在表单中添加一个隐藏字段，该字段的值由服务器端生成并返回给前端。在表单提交时，将该字段的值一起提交给服务器端进行验证。如果提交的token与服务器端生成的token不一致，则拒绝请求处理。
-
使用HTTP严格传输安全（HSTS）：通过设置HSTS头部信息，强制浏览器使用HTTPS协议进行通信，确保传输的数据不被篡改或窃取。这样可以防止CSRF攻击中的数据篡改问题。
-
在后端验证请求来源：在后端处理请求时，验证请求的来源是否合法。可以通过检查HTTP请求头的Referer字段或使用自定义的请求头信息来判断请求是否来自同一网站。如果请求来源不合法，则拒绝处理该请求。
-
增加验证码验证环节：对于一些高风险的操作，可以在表单中增加验证码字段。用户在输入验证码后才能提交表单。这样可以防止攻击者利用CSRF漏洞伪造用户的身份进行非法操作。
-
定期更新token值：为了防止攻击者获取到token值后进行恶意操作，可以定期更新token值。这样即使攻击者获取到旧的token值，也无法进行有效的伪造请求。
token值：为了防止攻击者获取到token值后进行恶意操作，可以定期更新token值。这样即使攻击者获取到旧的token值，也无法进行有效的伪造请求。
