CSRF代表跨站请求伪造。它使攻击者可以通过电子邮件或其他方式设计可操纵的请求，从而在您当前通过身份验证的网站中进行状态更改操作。 CSRF的目的不是读取敏感数据，而是为攻击者的利益编写或更改您的数据。
CSRF的一个示例场景
例如，您登录到网上银行网站https://mybank.com。在您的网上银行应用程序中进行资金转帐的请求网址如下所示：
https://mybank.com/transferFunds.do?beneficiary=Siva&amount=500攻击者想将您的钱存入他的帐户。因此，他制作了具有以下HTML内容的电子邮件，
当您打开此电子邮件时，将通过浏览器拨打电话，您将在该浏览器中登录到网上银行帐户，以将资金转入攻击者的帐户。因此，只需打开电子邮件，由于您已经登录到银行网站，因此将从您的帐户中扣除。该图像可能看起来不完整，并显示替代文本，但攻击者成功实现了他预期的效果，即在您的银行网站上进行了状态更改的借记帐户操作。
由于攻击者可以设计并向您发送在浏览器上执行的请求，因此攻击者无法读取特定于您帐户的数据。 CSRF的主要目的是执行写操作。
常规CSRF保护机制
由于CSRF是一个严重的漏洞，因此到目前为止已经尝试了多种保护机制。
- POST方法而不是GET的用法：有一个误解，认为只有GET方法才容易受到CSRF攻击。可以向用户发送JavaScript控制的HTML表单链接，该链接在打开时自动使用POST方法使用JavaScript提交到目标网站。因此，该方法不能有效地防御CSRF攻击。
- 反– CSRF令牌：对于网站生成的每个链接，该网站还将在请求参数或请求标头中附加一个反CSRF令牌。这应该是一个强大的加密哈希，攻击者必须无法预测或篡改。该站点还在其响应cookie中设置了该哈希。仅当包含CSRF令牌的参数与CSRF cookie匹配时，请求才可以继续进行。否则，请求将失败。该CSRF cookie可能会在每个会话中生成一次，也可能在每个请求中生成一次，并且必须立即失效。精心设计并向您发送请求的攻击者不知道当前会话/请求的CSRF cookie是什么。因此，所有具有CSRF Cookie保护的状态更改操作都会破坏CSRF攻击尝试。
SameSite属性
对于与任何网站关联的每个cookie，可以设置一个名为SameSite的属性。这样做是为了保护网站免受CSRF攻击。在不使用单独的cookie来保护网站免受CSRF攻击的情况下，可以将SameSite属性设置为网站的会话cookie，以指示是否仅当链接来自同一网站时才发送授权用户进入网站的cookie。 ，第三方网站等)。此属性控制此Cookie的传递行为。
使用SameSite Cookie解决CSRF问题
由于这是所有网站的常见问题，并且每个网站都必须保持一种机制来生成，传递和使CSRF令牌无效，因此Chrome现在引入了SameSite Cookie，该Cookie的主要目的是保护CSRF。
几乎所有站点都使用基于Cookie的用户身份验证机制。用户使用其凭据登录网站后，该网站将在浏览器会话中设置cookie。这用于响应用户对该特定站点的进一步请求，而不必再次登录。该cookie称为会话cookie。在会话cookie的SameSite属性中使用以下值之一，网站可以保护自己免受CSRF攻击。
域上设置的所有cookie都可以具有与它关联的SameSite cookie属性值。 SameSite Cookie可以采用以下值之一，
SameSite : strict使用SameSite设置的Cookie：strict将禁用将cookie发送到所有第三方网站的功能。仅当域与设置cookie的路径相同时，才会发送cookie。
SameSite : none使用SameSite设置的Cookie：无将禁用基于SameSite的保护。该网站可能使用其自己的CSRF保护机制。
SameSite : Lax使用SameSite设置的Cookie：宽松将仅允许将cookie发送给顶级导航。当您不添加SameSite属性时，Lax被视为默认行为。
因此，如果您使用SameSite：Strict设置会话cookie，则即使没有专用的CSRF cookie，从第三方网站到您的网站生成的链接中也不会包含会话cookie。因此，不可能对它们执行CSRF攻击。
由于所有现代浏览器都在考虑实现此行为以保护其用户免受CSRF攻击，因此这种情况正变得越来越普遍。