CSRF攻击

什么是CSRF?

CSRF（Cross-Site Request Forgery）攻击并不直接盗取受害者的 cookie，而是利用受害者已登录的状态下，伪造一个请求，以达到攻击者的恶意目的。

简单的说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己以前认证过的站点并运行一些操作（如发邮件，发消息，甚至财产操作（如转账和购买商品））。因为浏览器之前认证过，所以被访问的站点会觉得这是真正的用户操作而去运行。

具体流程

1. 登录受信任站点A，并在本地生成Cookie。
2. 在不登出A的情况下，访问危急站点B。
3. 受害者已经登录了站点A，因此B发送请求时，浏览器会自动带上受害者的 cookie，就好像是受害者自己发送的请求一样。

因此本质是因为cookie保存了sessionID，后端通过这个进行用户验证，第三方网站直接利用了你的cookie就可以进行身份验证。

CSRF漏洞的挖掘

1、最简单的方法就是抓取一个正常请求的数据包，如果没有Referer字段和token，那么极有可能存在CSRF漏洞。

2、如果有Referer字段，但是去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。

CSRF漏洞的防御

1、验证码、增加二次确认

验证码被认为是对抗CSRF攻击最简洁而有效的防御方法。

CSRF攻击的过程，往往是在用户不知情的情况下构造了网络请求。而验证码，则强制用户必须与应用进行交互，才能完成最终请求。因此在通常情况下，验证码能够很好地遏制CSRF攻击。

总之就是要让用户知晓这个敏感操作的发生，确认是用户的行为。

2、请求头添加token验证

由于cookie会每次携带在请求上，因此访问第三方网站时，可能会被获取，攻击者在第三方网站上插入恶意代码，使用这个cookie来模拟受害者发送请求。

因此我们通过后端发送的token值进行验证，将token值存贮在local storage中（一般情况），在每次发送请求时，手动使用js把token放到请求头中，后端通过这个token来验证。

为什么有效果？

因为csrf攻击本质是利用自动携带cookie从第三方网站发送敏感请求，因此，他是拿不到token并且把它加在请求头上的。

3、添加samesite

CSRF 攻击都是从第三方站点发起的，要防止 CSRF 攻击，我们最好能实现从第三方站点发送请求时禁止 Cookie 的发送

HTTP 响应头中，通过 set-cookie 字段设置 Cookie 时，可以带上 SameSite 选项

SameSite 选项通常有 Strict、Lax 和 None 三个值。

Strict 最为严格。如果 SameSite 的值是 Strict，那么浏览器会完全禁止第三方 Cookie。也就是说只有你从 InfoQ 的站点去请求 InfoQ 的资源时，才会带上这些 Cookie。
Lax 相对宽松一点。在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。

但如果在第三方站点中使用 Post 方法，或者通过 img、iframe 等标签加载的 URL，这些场景都不会携带 Cookie。
None 的话，在任何情况下都会发送 Cookie 数据。

4、查看http中的referer和origin

另外一种防止 CSRF 攻击的策略，那就是在服务器端验证请求来源的站点，服务器的策略是优先判断 Origin，如果请求头中没有包含 Origin 属性，再根据实际情况判断是否使用 Referer 值。

1. Origin

• Origin字段用于表明请求的源信息。
• 它包含了协议（http或https）、域名和端口号。
• 主要用于跨域资源共享（CORS）和跨站请求伪造（CSRF）的防护。
• 在CORS中，浏览器会根据Origin字段判断是否允许跨域请求。
• 例如，Origin: https://www.example.com。

2. Referer

• Referer字段用于标识请求的来源页面URL。
• 它告诉服务器当前请求是从哪个页面跳转或是链接过来的。
• Referer字段可能会泄露用户的浏览历史。
• 例如，Referer: https://www.example.com/page1。

但是也不一定是绝对安全，因为安全的验证过度依赖了浏览器，某些版本的浏览器可以通过某些方法来修改origin和referer。