跨站点请求伪造(也称为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