referer校验防csrf不可靠，因为referer头由客户端生成且可被恶意篡改或完全省略。攻击者可以通过构造特殊的请求（如通过javascript的fetch api发送无referer的请求）或利用第三方网站的重定向来绕过这一检查。因此，仅依赖referer进行csrf防护是不安全的，应结合使用token机制或其他更可靠的验证方法。
为什么Referer可以被轻易伪造？
Referer头是HTTP协议中用于标识请求来源的一个字段，但它并不是强制性的，也不是由服务器生成的。这意味着攻击者可以轻松地通过自定义HTTP请求来修改或省略这个字段。例如，在JavaScript中使用`fetch` API时，默认情况下不会自动添加Referer头，除非显式设置。此外，某些浏览器或网络环境可能会出于隐私保护的目的而移除Referer头，导致合法请求也被误判为非法。
const url = 'https://example.com/api/action';
const options = {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({ data: 'sensitive' })
};
fetch(url, options)
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));
上述代码展示了如何使用`fetch` API发起一个POST请求，但没有包含任何Referer头。这说明了攻击者可以轻松构造这样的请求来绕过基于Referer的CSRF防护。
哪些场景下Referer校验会失效？
除了Referer可以被伪造外，还有一些特定场景会导致Referer校验失效。例如，当用户从HTTPS页面跳转到HTTP页面时，浏览器通常会省略Referer头以保护隐私。同样地，如果用户通过书签、直接输入URL或通过邮件链接访问网站，也可能没有Referer头。这些情况都会使得基于Referer的CSRF防护机制无法正常工作。
// 模拟从HTTPS到HTTP跳转的场景
function simulateRedirect() {
const httpsPage = 'https://secure.example.com';
const httpPage = 'http://insecure.example.com';
// 假设这里有一个重定向逻辑
window.location.href = httpPage;
}
// 调用函数模拟跳转
simulateRedirect();
在这个例子中，当用户从HTTPS页面跳转到HTTP页面时，浏览器可能会省略Referer头，从而导致基于Referer的CSRF防护失效。
如何正确实现CSRF防护？
为了有效防止CSRF攻击，建议采用双重提交Cookie或SameSite Cookie属性等更为可靠的方法。双重提交Cookie要求客户端在每次请求中同时发送一个特定的Cookie和一个对应的Token，服务器端验证两者是否匹配。而SameSite Cookie属性则可以在浏览器层面限制Cookie的发送范围，从而减少CSRF攻击的风险。
