Lab: CSRF with broken Referer validation：带有损坏的 Referer 验证的 CSRF

可以绕过Referer的验证
一些应用程序Referer以一种可以绕过的幼稚方式验证标头。例如，如果应用程序验证中的域以Referer预期值开头，则攻击者可以将其作为自己域的子域：
http://vulnerable-website.com.attacker-website.com/csrf-attack

同样，如果应用程序只是验证Referer包含自己的域名，则攻击者可以将所需的值放在 URL 的其他位置：
http://attacker-website.com/csrf-attack?vulnerable-website.com

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

您可以通过确保包含您的漏洞利用的响应具有Referrer-Policy: unsafe-url标头集来覆盖此行为（请注意，Referrer在这种情况下拼写正确，只是为了确保您注意！）。这确保将发送完整的 URL，包括查询字符串。

本实验室的电子邮件更改功能易受 CSRF 攻击。它尝试检测和阻止跨域请求，但可以绕过检测机制。

要解决该实验，请使用您的漏洞利用服务器托管一个 HTML 页面，该页面使用CSRF 攻击来更改查看者的电子邮件地址。

您可以使用以下凭据登录自己的帐户： wiener:peter

内容:

• 使用您的浏览器通过 Burp Suite 代理流量，登录您的帐户，提交“更新电子邮件”表单，然后在您的代理历史记录中找到生成的请求。
• 将请求发送到 Burp Repeater。请注意，如果您更改 Referer HTTP 标头中的域，请求将被拒绝。
• 复制您的实验室实例的原始域并将其以查询字符串的形式附加到 Referer 标头中。结果应该是这样的：
• Referer: https://arbitrary-incorrect-domain.net?your-lab-id.web-security-academy.net
• 发送请求并观察它现在已被接受。该网站似乎接受任何 Referer 标头，只要它在字符串中的某处包含预期的域即可。
• 按照CSRF 漏洞解决方案中的描述创建一个 CSRF 概念验证，没有防御实验室，并将其托管在漏洞利用服务器上。编辑 JavaScript，使history.pushState()函数的第三个参数包含一个带有您的实验室实例 URL 的查询字符串，如下所示： 这将导致生成的请求中的 Referer 标头在查询字符串中包含目标站点的 URL，就像我们测试过的一样早些时候。
• history.pushState("", "", "/?your-lab-id.web-security-academy.net")

• 如果您存储漏洞并通过单击“查看漏洞”进行测试，您可能会再次遇到“无效的Referer header”错误。这是因为作为安全措施，许多浏览器现在默认从 Referer 标头中删除查询字符串。要覆盖此行为并确保请求中包含完整 URL，请返回漏洞利用服务器并将以下标头添加到“Head”部分： 请注意，与普通的 Referer 标头不同，必须拼写单词“referrer”在这种情况下正确。
• Referrer-Policy: unsafe-url
• 存储漏洞，然后单击“交付给受害者”以解决实验室问题。