使用CSRF 常见的防御措施是不是就万事大吉了-防御措施绕过机制

什么是CSRF 令牌？

CSRF 令牌是由服务器端应用程序生成并与客户端共享的唯一、秘密且不可预测的值。在发出请求以执行敏感操作（例如提交表单）时，客户端必须包含正确的 CSRF 令牌。否则，服务器将拒绝执行请求的操作。

CSRF 令牌验证中的常见缺陷

1、CSRF 令牌未绑定到用户会话

某些应用程序不验证令牌是否与发出请求的用户属于同一会话。相反，应用程序维护它已颁发的令牌的全局池，并接受此池中显示的任何令牌。攻击者可以使用自己的帐户登录应用程序，获取有效的令牌，然后将该令牌提供给 CSRF 攻击中的受害者用户。

2、CSRF 令牌与非会话 Cookie 绑定

某些应用程序确实将 CSRF 令牌绑定到 Cookie，但不绑定到用于跟踪会话的同一 Cookie。当应用程序使用两个不同的框架时，这很容易发生，一个用于会话处理，另一个用于 CSRF 保护，如果网站包含任何允许攻击者在受害者浏览器中设置 cookie 的行为，则可能发生攻击。攻击者可以使用自己的帐户登录应用程序，获取有效的令牌和关联的 cookie，利用 cookie 设置行为将其 cookie 放入受害者的浏览器中，并在 CSRF 攻击中将其令牌提供给受害者。

3、CSRF 令牌只是在 cookie 中复制

某些应用程序不维护已颁发令牌的任何服务器端记录，而是在 Cookie 和请求参数中复制每个令牌。验证后续请求时，应用程序只需验证 request 参数中提交的令牌是否与 Cookie 中提交的值匹配。这有时被称为针对 CSRF 的 “双重提交” 防御，之所以被提倡，是因为它易于实现并且避免了对任何服务器端状态的需要。如果网站包含任何 cookie 设置功能，攻击者可以再次执行 CSRF 攻击。在这里，攻击者不需要获取自己的有效令牌。他们只需发明一个令牌（如果正在检查，则可能采用所需的格式），利用 cookie 设置行为将他们的 cookie 放入受害者的浏览器中，并将他们的令牌提供给 CSRF 攻击中的受害者。

4、CSRF 令牌的验证取决于令牌的存在

某些应用程序会在令牌存在时正确验证令牌，但如果省略令牌，则会跳过验证。攻击者可以删除包含令牌的整个参数（不仅仅是其值）以绕过验证并进行 CSRF 攻击。

5、CSRF 令牌的验证请求方法的切换缺陷

某些应用程序在请求使用 POST 方法时正确验证令牌，但在使用 GET 方法时跳过验证。切换到 GET 方法来绕过验证并进行 CSRF 攻击

SameSite 是一种浏览器安全机制，用于确定何时将网站的 Cookie 包含在来自其他网站的请求中。SameSite Cookie 限制提供针对各种跨站点攻击的部分保护，包括 CSRF、跨站点泄漏和某些 CORS 漏洞。

既然是sameSit，就要确认什么情况下是相同站点，在确定请求是否为同一站点时，会考虑顶级域名、二级域名、子域名和所采用的协议。如http://app.example.com和 https://app.example.com会认为是不同的站点。

在我们讲同站点时，可能会想到同源的概念，站点和源是不同的概念，一个站点包含多个域名（有子域名，有不同的端口）而源仅包含一个，相同的协议、域名和端口才能算一个源。

SameSite使浏览器和网站能够限制哪些跨站点请求应包含特定 Cookie。主流浏览器支持 SameSite 的三种限制级别：严格、宽松、没有。

在SameSite严格模式下，浏览器不会在任何跨站点请求中发送 Cookie；也就是说如果请求的目标站点与浏览器地址栏中当前显示的站点不匹配，则它将不包含 Cookie。

在SameSite宽松模式下，限制浏览器将在跨站点请求中发送 Cookie。但是要使用GET 请求方法而不能使用POST 请求。且该请求是用户进行顶级导航，即通过点击链接、在地址栏输入URL或者通过书签访问某个网站等行为。

在SameSite=None模式下，禁用 SameSite 限制。浏览器会向站点发送带有 Cookie 的所有请求中，即使是由完全不相关的第三方网站触发的请求也会发送cookie。但是有些时候需要SameSite=None模式，因为当一个 Cookie 被设计为在第三方上下文中使用，并且这个 Cookie 不包含敏感信息或不授予持有者访问敏感数据或功能的权限时None是合理的。例如跟踪cookie进行广告推广、数据统计、社交分享登录等。

那是不是有了SameSite就不用担心CSRF攻击了？答案是否定的

当页面加载时，表单会自动提交，发送一个GET请求到https://example.com/api/data ，并附带所有相关的Cookie（如果有的话）。由于GET请求被允许携带Cookie，即使目标站点的Cookie设置了SameSite=Lax（宽松）属性，浏览器也会发送这些Cookie

HTTP Referer 标头（在 HTTP 规范中无意中拼写错误）是一个可选的请求标头，其中包含链接到所请求资源的网页的 URL。它通常由浏览器在用户触发 HTTP 请求时自动添加，包括通过单击链接或提交表单。存在多种方法，允许链接页面保留或修改 Referer 标头的值。这样做通常是出于隐私原因。当 Referer 标头出现在请求中时，某些应用程序会对其进行验证，但如果省略标头，则会跳过验证。攻击者可以构建导致用户的浏览器在结果请求中删除 Referer 标头。有多种方法可以实现这一点，但最简单的是在 HTML 页面中使用 META 标签。

利用子域绕过验证和域名嵌入URL参数的方法绕过Referer 标头验证，

利用子域绕过验证是应用程序验证Referer中的域以预期值开头，攻击者可以将其作为自己域的子域。如目标网站是https://example.com.攻击者可以创建一个子域：https://example.com.att.com.

域名嵌入URL参数应用程序只是验证Referer是否包含自己的域名，攻击者可以将所需的值放在URL中的其他位置：https://att.com/att?example.com。