CSRF漏洞笔记

跨站点请求伪造（也称为CSRF）是一个Web安全漏洞，攻击者可以利用该漏洞诱使用户执行他们不打算执行的操作。
它允许攻击者部分规避同源策略。

漏洞利用需要具备的三个条件

• 一个可以利用的功能，如修改密码等
• 基于Cookie的会话处理。没有其他机制可以跟踪会话或验证用户请求。
• 没有不可预测的请求参数

几种CSRF利用方式

常规利用

burpsuite抓去请求后，使用CSRF poc生成即可

CSRF令牌的验证取决于请求方法

只有在POST方法的情况下才验证token，但正好也支持GET请求，使用GET请求发送CSRF即可

CSRF令牌的验证取决于令牌是否存在

如果令牌存在，某些应用程序会正确验证令牌，但是如果省略令牌，则跳过验证。

这种情况下，直接删除掉CSRF的token参数即可。

CSRF令牌未绑定到用户会话

某些应用程序无法验证令牌与发出请求的用户属于同一会话。
然而，应用程序维护已发出的全局令牌池，并接受该池中显示的所有令牌。

在这种情况下，攻击者可以使用自己的帐户登录到应用程序，获取有效令牌，然后在其CSRF攻击中将该令牌提供给受害用户。

CSRF令牌绑定到非会话cookie

在上述漏洞的一种变体中，某些应用程序确实将CSRF令牌绑定到cookie，但没有绑定到用于跟踪会话的cookie。
当应用程序使用两种不同的框架（未集成在一起）时，很容易发生这种情况：一种用于会话处理，另一种用于CSRF保护。

防御

使用CSRF token机制

• 会话令牌不可预测
• 绑定用户会话
• 严格进行验证

在cookie属性中使用samesite

• Strict：完全静止第三方Cookie，跨站点时，任何情况下都不会发送cookie。换言之，只有当前网页的URL与请求目标一致，才会带上Cookie。

  Set-Cookie: CookieName=CookieValue; SameSite=Strict;
  

  这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub 链接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去总是未登陆状态。

• Lax：大多数情况下也是不发送第三方Cookie，但是导航到目标网站的GET 请求除外。

请求类型	示例	正常情况	Lax
链接	<a href="..."></a>	发送 Cookie	发送 Cookie
预加载	<link rel="prerender" href="..."/>	发送 Cookie	发送 Cookie
GET 表单	<form method="GET" action="...">	发送 Cookie	发送 Cookie
POST 表单	<form method="POST" action="...">	发送 Cookie	不发送
iframe	<iframe src="..."></iframe>	发送 Cookie	不发送
AJAX	$.get("...")	发送 Cookie	不发送
Image	<img src="...">	发送 Cookie	不发送

设置了Strict或Lax以后，基本就杜绝了 CSRF 攻击。值得一提的是，有一些web应用程序确实还使用GET请求实施敏感操作。又或者使用的是POST，但切换成GET方法也可以正常通信。所以建议samesite和CSRFtoken结合的方式来防御CSRF

• None：Chrome 计划将Lax变为默认设置。这时，网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。

  下面的设置无效。

  Set-Cookie: widget_session=abc123; SameSite=None
  

  下面的设置有效。

  Set-Cookie: widget_session=abc123; SameSite=None; Secure