【HW系列】—web常规漏洞（CSRF与SSRF）
文章目录
- CSRF漏洞分析
- 1. 简介
- 2. 成因
- 3. 危害
- 4. 防御措施
- SSRF漏洞分析
- 1. 简介
- 2. 成因
- 3. 危害
- 4. 防御措施
- 总结
合规声明：本文仅用于提升开发者安全意识，所有技术细节均遵循合法授权测试原则。
部分攻击示例已做抽象化处理，避免直接复现风险。
CSRF漏洞分析
1. 简介
CSRF（跨站请求伪造）是一种利用用户已登录的会话状态，诱导用户访问恶意页面或点击链接，伪造合法请求执行非授权操作的漏洞。攻击核心在于“信任浏览器的自动身份验证机制”，而非直接窃取用户凭据。例如，用户登录银行网站后访问攻击者构造的恶意页面，自动触发转账请求。
CSRF（跨站请求伪造）
场景：小明登录了某银行网站，此时浏览器保存了他的登录状态（Cookie）。随后，小明点击了一个看似无害的链接（比如“免费抽奖”），而这个链接实际隐藏了一个转账请求
结果：浏览器自动携带小明的Cookie访问银行网站，完成转账操作，但小明毫不知情。
通俗解释：
就像朋友用你的手机偷偷发了一条朋友圈（用你的身份操作），而你完全没察觉。
2. 成因
- 依赖Cookie/Session验证：服务端仅通过Cookie验证身份，未校验请求来源是否合法。
- 关键操作无二次验证：如转账、修改密码等敏感操作未要求验证码或二次确认。
- 请求参数可预测：攻击者能构造包含敏感参数的请求。
3. 危害
- 资金损失：攻击者伪造转账请求，用户账户资金被盗取。
- 隐私泄露：篡改用户资料或获取敏感信息（如邮箱、地址）。
- 权限提升：结合XSS漏洞劫持管理员会话，执行更高危操作。
- 供应链攻击：通过伪造请求传播恶意链接，形成蠕虫式扩散。
4. 防御措施
- Token验证：在表单或请求头中添加随机Token，服务端校验合法性。
- SameSite Cookie：设置Cookie属性为SameSite=Strict，限制跨域请求携带Cookie。
- Referer校验：验证请求来源域名是否合法（需注意隐私策略兼容性）。
- 关键操作二次验证：如短信验证码、生物识别等。
- 用户教育：避免点击不明链接，定期清理会话。
SSRF漏洞分析
1. 简介
SSRF（服务端请求伪造）是攻击者操控服务端发起任意网络请求，访问内网资源或第三方系统的漏洞。常见于功能如网页截图、URL解析等需服务端发起请求的场景。
SSRF（服务端请求伪造）
场景：某在线翻译网站允许用户输入URL翻译网页内容。攻击者输入一个内网地址。
结果：网站服务器代替攻击者访问了内网的管理后台，导致敏感信息泄露。
通俗解释：
就像你授权朋友使用家庭WiFi，他却利用这个权限偷偷翻看你的私人监控（服务器被操控访问内网资源）
正常状态:
SSRF:
2. 成因
由于服务端提供了从其他服务器应用获取数据的功能，但又没有对目标地址做严格过滤与限制，导致攻击者可以传入任意的地址来让后端服务器对其发起请求，并返回对该目标地址请求的数据。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。
3. 危害
- 窃取数据：攻击者可以伪造请求以访问服务器内部网络或云环境中的其他服务或资源，以窃取敏感数
据。
- 攻击第三方系统：攻击者可以伪造请求以攻击第三方系统，例如访问其他组织的敏感数据或执行拒绝
服务攻击。
- 内部端口扫描：攻击者可以伪造请求以扫描服务器内部端口和服务，以寻找其他可能的漏洞。
- 获取指纹信息：通过获取 web 应用可达服务器服务的指纹信息。
4. 防御措施
- 输入过滤：限制URL参数为公网地址，拦截私有IP和危险协议。
- 协议白名单：仅允许HTTP/HTTPS协议。
- 网络隔离：通过防火墙禁止服务端访问非必要内网资源。
- 日志监控：记录异常请求并触发告警。
- 云平台加固：限制元数据接口访问权限，使用临时凭证替代长期密钥。
总结
CSRF与SSRF均属请求伪造类漏洞，但攻击链差异显著：
- CSRF：防御核心是打破“信任浏览器请求”的机制，需结合Token、二次验证等。
- SSRF：需从协议、网络、权限多维度限制服务端请求行为。
建议定期渗透测试，结合自动化工具（如Burp Suite、OWASP ZAP）检测漏洞，并参考OWASP防护指南更新策略。
法律与道德声明
- 本文所述漏洞仅用于防御技术研究，严禁用于非法渗透测试
- 所有安全测试必须获得目标系统的书面授权
- 技术人员应遵守《网络安全法》及《数据安全法》相关规定
合规研究途径：
✅ 国家护网行动
✅ 企业授权渗透测试
✅ OWASP官方测试指南
