CSRF漏洞很容易被发现和利用。 乍一看，很多网站在这方面看起来很顺利。 gxdsb在检查对敏感操作的要求时经常实施CSRF保护。 它可以是请求主体中的CSRF token，也可以是referer字段检测，还可以是特殊的HTTP头字段或cookie字段。
但是，这并不意味着CSRF的防御不能迂回。 今天我们讨论绕过CSRF防御措施的技术。
不管引入了什么CSRF防御措施，所有CSRF都可以尝试两件事：劫持和更改请求方式。
点击劫持在同一个功能端点上利用点击劫持可以绕过所有的CSRF防御。 从技术上讲，请求确实来自合法站点，因此如果具有易受攻击端点的页面容易受到点击劫持攻击，则所有CSRF保护都没有效果，攻击者可以任意执行CSRF攻击。
更改请求方法的另一种方法是更改请求方法。 如果以POST方式发送了要伪造的敏感请求，则尝试将其转换为GET请求。 如果在操作时通过GET方法发送，请尝试将其转换为POST方法。 APP应用程序可能仍在执行操作，并且通常没有保护机制。
例如，您可以要求：
post/change _ password postbody : new _ password=qwerty是
GET /change_password？ new_password=qwerty CSRF token的防御措施旁路通过以下方式保护CSRF token，因为某些站点使用了CSRF token并未验证相应的请求操作
删除token参数或发送空token都可以在不发送token的情况下成功请求数据，这是因为这种逻辑错误在APP应用中很常见。 当token存在或token参数不为空时，APP应用程序可能会检查token的有效性。 在这种情况下，如果一个请求中不包含token或者token的值为空，也可以绕过CSRF的防御。
例如，合法要求如下
post/change _ password postbody : new _ password=qwerty csrf _ Tok=871 caef 0757 a4 AC 9691 ace B9 a ad8b 65 b执行这些请求
post/change _ password postbody : new _ password=qwerty或类似的：
post/change _ password postbody : new _ password=qwerty csrf _ Tok=使用另一个session的csrf token APP应用程序将检查token是否合法有时不检查token是否属于当前用户。在这种情况下，用payload硬编码合法有效的token就可以了。
如果某个受害者的token是871 caef 0757 a4 AC 9691 ace B9 a ad8b 65 b，而自己的token是YOUR_TOKEN，那么自己的token就很容易得到，而受害者的token就不容易得到。 试图通过payload提供自己的token绕过CSRF防御。
也就是说，本来应该发送以下要求。
post/change _ password postbody : new _ password=qwerty csrf _ Tok=871 caef 0757 a4 AC 9691 ace B9 a ad8b 65 b，但改为发送此请求
post/change _ password postbody : new _ password=qwerty csrf _ Tok=your _ token session固定是站点作为csrf的防御措施的双提交cookie 该请求必须包含cookie，其值为随机token值，表示请求参数中也有随机token值的字段值。 如果值相同，则请求是合法的。 这种防御形式非常常见。
如果双重提交cookie用于防御，则此APP应用可能没有在服务器端保存有效的token。 因此，无法指定token是否合法。 此外，也可能很少检查cookie的token值和参数的token值是否相同。 这意味着发送假token也可以有效地实施CSRF攻击。
这次攻击有两个步骤。 第一步，使用session固定技术验证受害者的浏览器是否使用了包含假token的提供的session，第二步是对参数使用同一token执行此CSRF攻击。
固定会话。 这是一次可以控制受害者饼干储存的攻击
执行以下请求以实施CSRF攻击
post/change _ password cookie : csrf _ Tok=fake _ token； 如果postbody : new _ password=qwerty csrf _ Tok=fake _ token referer字段中的csrf防御旁路attack.com是控制域名，则bank.com为虽然此网站没有使用CSRF token，但我检查了referer字段。 我该怎么办？
删除referer字段与发送空token值相同，有时只需删除referer字段即可绕过CSRF防御。 可以在有漏洞的页面中添加以下类型的元标记：
metaname=" referrer " content=" no-referrer " APP应用程序仅在提交后才能进行验证。 在这种情况下，可以绕过CSRF防御。
绕过正则表达式如果referer检查基于白名单，请尝试绕过验证URL的正则表达式。 例如，尝试在referer的URL中将受害者域名放在辅助域名区域或URL目录区域中。
如果站点在referer字段中检查bank.com字段，则“bank.com.attacker.com”或“attakcer.com/bank.com”将跳过此检查