CSRF

CSRF（Cross-Site Request Forgery）漏洞是一种Web应用程序安全漏洞，它利用了用户在已登录的Web应用程序上的身份验证状态。攻击者通过欺骗用户使其执行非预期的操作，从而利用用户的权限发起恶意请求。

无任何防护网站CSRF攻击：

1. 先抓取到那个你要实现的功能的那个数据包（比如说你要让网站莫名出现一个管理员，那你就要把正常创建管理员的那个请求数据包整个给copy下来，然后把包放在自己的电脑上，等待触发，只要一触发不就代表又在发送创建管理员账号的请求了吗）
2. 数据包可以在信息收集的过程中，去找到网站的相同源码。然后自己搭建一个相同的网站，把功能数据包抓取下来。可能性不大
3. 可以用BP工具把那个数据包包装成html页面，只要访问这个html页面既是发送了此请求
4. 全部匹配就是严谨的对比，匹配对比就属于不严谨的对比

全部匹配的严谨过滤绕过思路：

1. 如果是全部匹配的严谨过滤可以配合xss和文件上传来进行攻击，不是会判断来源于哪个域名下来判断操作合理吗，因为是html文件，上传或许是可以的；那么我把这个请求数据包上传到对方自己的服务器下面，进行访问。那就是可以绕过全部匹配的，因为这请求源本身就来自于对方自己的域名下
2. 目标代码可能存在如果referer值为空，则直接返回true；因为有些正常操作就是直接访问本身就没有来源，在本地上的正常的操作就没有来源这一值
3. :让数据包没有referer头

不严谨的匹配绕过思路：

更改referer头的值，不严谨就是说只要referer头里的值，存在既定好的那个地址就可以通过，那我们可以在伪造的数据包里的referer头里直接添加网站的路径地址即可。

防范CSRF攻击的方法：

1. 检测Referer字段是否同源，遵循同源策略，确保只有同一来源的请求才能访问敏感操作。这有助于防止来自其他域的恶意请求。 （$_SERVER[‘HTTP_REFERER’]）获取referer头

   • 判断Referer字段的值存在两种可能，第一种是全部匹配，就要要更既定好的字符一模一样才行；第二种就是匹配对比，只要referer的值有既定的那串字符存在就好。

2. 如果设置了token，csrf攻击事先保存的那个数据包里的token，和受害人发送的那次数据包里的token会不匹配的，就可以防御csrf攻击了。

   • Tokne验证可能存在三个问题：复用，删除，置空；怎么去测试目标网站是否有这三个token验证问题的存在呢？

     1. 删除问题就在我们请求的数据包里把token这个连头带值直接删除，如果能成功响应，那就是存在此问题；
     2. 置空就是把token头留下，但值删除如果能正常响应那就是有置空问题；
     3. 复用的问题，就是你两次发送数据包都用一样的token值如果能正常响应，那就是有token校验问题。

3. 使用HTTP头部： 设置HTTP头部中的SameSite属性，限制第三方站点对Cookie的访问，从而降低CSRF攻击的风险。

4. 双重身份验证： 引入双重身份验证，即使攻击者能够发起一些操作，但仍需要额外的身份验证步骤。

5. Token不是放在请求参数中，而是放在了cookie中，这样攻击的请求同样会带上这个token（浏览器会将cookie自动带上），就达不到防攻击的作用了

如果存在CSRF漏洞的话能做什么：

1. 更改用户密码： 通过构造特定的CSRF请求，攻击者可能能够更改用户的密码，将其锁定出帐户。
2. 执行资金转移：攻击者可能尝试发起未经授权的资金转移。
3. 更改用户设置： 攻击者可以修改用户的个人设置、权限或偏好，导致不良影响。
4. 发起恶意操作： 例如，攻击者可能在用户不知情的情况下发起恶意操作，比如发布不当内容、删除数据等。

CSRF漏洞挖掘：

1. 抓取一个正常请求的数据包，如果没有Referer字段和token，那么极有可能存在CSRF漏洞
2. 如果有Referer字段，但是去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。
3. 分析目标应用程序： 仔细了解目标应用程序的功能和交互。特别关注那些对用户状态敏感的操作，比如修改密码、发起支付等。
4. 检查请求参数： 查看应用程序中的请求，注意是否有明显的CSRF防护机制，如同源检查（SameSite Cookie属性）、Token等。
5. CSRF PoC： 创建一个CSRF攻击的PoC，验证攻击是否成功。这可以通过手动执行攻击或使用自动化工具来实现。
6. 自动化工具： 使用专门的漏洞扫描工具，如Burp Suite，来扫描应用程序，检测潜在的CSRF漏洞。

‍