翻译

原文：https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses

- name: 翻译
  desc: 原文：https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses
  bgColor: '#F0DFB1'
  textColor: 'green'

绕过基于Referer的CSRF防御

除了使用 CSRF 令牌的防御之外，一些应用程序还尝试使用 HTTP Referer标头来防御 CSRF 攻击，原理是通过验证请求是否来自应用程序自己的域。这种方法通常不太有效，并且经常被绕过。

Referer标头

HTTP Referer 标头（在 HTTP 规范里无意中拼写错误）是一个可选的请求标头，其中包含链接到所请求资源的网页 URL。当用户触发 HTTP 请求时，该标头通常由浏览器自动添加，包括单击链接 或 提交表单时。有各种各样的方法，允许链接的页面保留或修改Referer标头的值，这通常是出于隐私原因。

1Referer验证取决于标头是否存在

一些应用程序在请求中包含Referer标头时对其进行验证，但如果省略标头，则跳过验证。

在这种情况下，攻击者可以精心打造其 CSRF 载荷，使受害用户的浏览器在生成的请求中剔除Referer标头。有多种方法可以实现这一点，但最简单的方法是在托管 CSRF 攻击的 HTML 页面中使用 META 标签：

<meta name="referrer" content="never">

实验室-从业者

CSRF-Referer验证取决于标头是否存在 >>

- name: 实验室-从业者
  desc: CSRF-Referer验证取决于标头是否存在 >>
  avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
  link: https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses/lab-referer-validation-depends-on-header-being-present
  bgColor: '#001350'
  textColor: '#4cc1ff'

2Referer验证可以被规避

某些应用程序 以一种可以被绕过的简单方式 来验证Referer标头。例如，如果应用程序验证Referer中的域是否以预期值开头，则攻击者可以将其作为自己的子域：

http://<受攻击的域>.com.<攻击者的域>.com/csrf-attack

同样，如果应用程序只是验证Referer是否包含自己的域名，则攻击者可以将所需的值放置在 URL 中的其他位置：

http://<攻击者的域>.com/csrf-attack?<受攻击的域>

笔记

尽管你可以使用 Burp 来识别此行为，但当你在浏览器中进行概念验证测试时，你经常会发现这种方法不再有效。为了降低敏感数据以这种方式泄露的风险，许多浏览器现在默认从Referer标头中删除查询字符串。

如果你想在其中显示查询字符串，则可以通过设置Referrer-Policy: unsafe-url标头来覆盖此行为（注意！在这种情况下，Referrer的拼写是正确的，只是为了确保你注意！）。这样可以确保发送完整的 URL，包括查询字符串。

实验室-从业者

CSRF-Referer验证中断 >>

- name: 实验室-从业者
  desc: CSRF-Referer验证中断 >>
  avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
  link: https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses/lab-referer-validation-broken
  bgColor: '#001350'
  textColor: '#4cc1ff'