Referer机制的核心作用与CSRF防御原理
HTTP Referer头由浏览器自动生成，用于标识请求的来源页面地址，帮助服务器进行流量分析、防盗链保护和安全验证。在CSRF防御中，服务器通过检查Referer值是否来自同一域名，来阻断外部恶意域名的伪造请求，其本质是依赖来源页面的可信性验证。
Referer验证的固有局限性及可绕过场景
该机制存在多重弱点：首先，Referer可能因用户隐私设置、浏览器安全策略（如HTTPS到HTTP的跳转）或书签访问而缺失，导致合法请求被误拒；其次，部分老旧浏览器或插件可能篡改Referer值，攻击者也可通过中间人攻击伪造头部；此外，若服务器仅宽松检查域名包含关系而非严格匹配，攻击者可能利用子域名或相似域名进行欺骗。
结合多层防御策略提升安全性
由于Referer验证的不可靠性，现代Web安全推荐采用组合策略：首要措施是使用CSRF Token，通过在会话中绑定随机令牌并验证其唯一性，从根本上杜绝伪造请求；其次可设置SameSite Cookie属性（如Strict或Lax），从浏览器层面限制跨站请求携带Cookie；对于敏感操作还可加入二次确认机制（如验证码）。通过Referer验证辅助、Token为核心、SameSite Cookie为屏障的多层防护，才能有效应对CSRF威胁。
| 防护机制 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Referer验证 | 实现简单，无需用户交互 | 可能被绕过或缺失 | 中等安全要求 |
| CSRF Token | 安全性高，难以绕过 | 需要前后端配合 | 高安全要求 |
| 组合使用 | 防御全面，互为补充 | 实现复杂度较高 | 关键业务操作 |
核心要点：Referer验证是CSRF防御的有效手段，但不应作为唯一防护措施。在实际应用中，建议与其他安全机制组合使用，构建纵深防御体系。
打开bp，打开自带的浏览器用dvwa靶场演示。low级别的scrf，随便输入密码和确认密码，开启抓包截获到get请求的信息发送到csrf poc
或者复制代码，新建一个文本文件放入代码并且改名为后缀为html，拖进去浏览器，也能改变密码
然后打开数据库发现dvwa的user表密码改变。
这都很容易破解，所以要引入token
SRF Token防御机制详解
核心原理
-
服务端生成：每次会话生成唯一、随机的Token字符串
-
客户端携带：Token通过隐藏表单字段或HTTP头传递
-
服务端验证：校验Token的有效性和匹配性
Token窃取与绕过技术
反射型XSS漏洞利用
攻击者通过XSS漏洞窃取用户的CSRF Token：
<!-- 利用XSS窃取Token的Payload --> <iframe src="../csrf" onload= "alert(frames[0].document.getElementsByName('user_token')[0].value)"> </iframe>
-
发现XSS漏洞：找到可执行脚本的注入点
-
窃取Token：通过DOM操作获取页面中的Token值
-
构造恶意请求：使用窃取的Token发起CSRF攻击
-
绕过防御：由于携带有效Token，请求通过验证
实战要点
| 防御层面 | 具体措施 | 注意事项 |
|---|---|---|
| Token生成 | 随机性、唯一性、时效性 | 每次会话更新，防止重放攻击 |
| Token传输 | HTTPS加密、HttpOnly Cookie | 防止中间人窃取 |
| Token验证 | 严格比对、及时销毁 | 验证后立即失效当前Token |
| 综合防护 | 结合Referer检查、SameSite Cookie | 纵深防御策略 |
但是用反射型xss也能破解令牌，注入
bash
<iframe src="../csrf"
onload=alert(frames[0].document.getElementsByName('user_token')[0].value)>有一个 <iframe>元素， src属性指向上级目录中的 csrf页面或资源。onload事件会在 iframe 加载完成后触发，执行其中的 JavaScript 代码。代码功能是尝试读取 iframe 内页面中第一个名为 user_token的表单元素的值，并通过 alert()弹窗显示。
所以token也能破解。
声明：本篇内容基于网络安全知识体系，所学用途皆不可用于法律之外的攻击与入侵
感谢大家的观看，小编呆呆羊在这里与大家共同学习共同成长。