1. 从一次真实攻击事件说起
去年某金融平台发生了一起用户资金被盗事件：攻击者诱导受害者点击了一个"抽奖活动"链接，受害者登录后，攻击者利用受害者已认证的会话，在后台完成了转账操作。整个过程受害者毫无察觉，直到收到银行短信才意识到出了问题。这就是典型的CSRF（跨站请求伪造）攻击。
而在另一起事件中，某企业内网服务器被入侵，调查发现攻击者通过一个存在SSRF（服务端请求伪造）漏洞的Web应用，以服务器为跳板访问了内网敏感系统。这两个安全漏洞看似不同，实则都利用了"请求伪造"这一核心攻击手法。
2. CSRF漏洞深度解析
2.1 漏洞原理与攻击流程
CSRF攻击的本质是：攻击者诱骗已认证的用户在不知情的情况下提交恶意请求。其核心利用三个条件：
- 用户已登录目标网站（存在有效会话）
- 网站未对敏感操作实施二次验证
- 攻击者能预测或获取请求参数
典型攻击步骤：
- 用户登录bank.com，会话cookie有效
- 用户访问攻击者构造的恶意页面，内含：
<img src="http://bank.com/transfer?to=hacker&amount=10000" width="0" height="0">- 浏览器自动携带cookie发送请求，完成转账
2.2 实战检测方法
使用Burp Suite测试的完整流程：
- 拦截正常修改密码请求（假设为POST /change-pwd）
- 右键请求 → Engagement tools → Generate CSRF PoC
- 调整HTML表单，移除随机token等防护参数
- 保存为HTML文件，用已登录账户的浏览器打开
- 观察密码是否被修改而不需要重新认证
关键验证点：
- 请求是否仅依赖会话cookie
- 敏感操作是否有不可预测参数（如CSRF token）
- 请求头是否检查Referer/Origin
2.3 防御方案对比
| 防御方案 | 实现方式 | 优点 | 缺点 |
|---|---|---|---|
| CSRF Token | 表单添加随机token，服务端校验 | 安全性高 | 需前后端配合 |
| SameSite Cookie | 设置Cookie的SameSite属性 | 浏览器原生支持 | 旧浏览器兼容性问题 |
| 二次验证 | 敏感操作需重新输入密码/验证码 | 用户体验差 | 安全性最高 |
| Referer检查 | 验证请求来源域名 | 实现简单 | 可能被绕过 |
最佳实践：关键操作应采用CSRF Token + SameSite Strict双重防护，金融级操作增加二次验证。
3. SSRF漏洞攻防全解
3.1 漏洞成因与危害
SSRF允许攻击者通过服务器发起任意网络请求，典型利用场景：
- 访问内网服务（如Redis、Jenkins）
- 云服务器元数据泄露（如AWS的169.254.169.254）
- 端口扫描内网资产
- 作为跳板实施进一步攻击
某真实案例攻击链：
存在SSRF的Web应用 → 访问云元数据 → 获取临时密钥 → 接管云服务器 → 横向移动内网 → 数据泄露3.2 常见触发点检测
容易存在SSRF的功能点：
- URL预览/转码服务
- 文件导入（如Excel读取外部链接）
- Webhook回调配置
- 社交媒体链接解析
- 文档转换服务（PDF生成等）
测试payload示例：
http://127.0.0.1:8080/admin file:///etc/passwd http://169.254.169.254/latest/meta-data/3.3 高级绕过技巧
当存在基础防护时，可尝试：
- 使用不同IP表示法：127.0.0.1 → 2130706433
- 利用重定向：http://evil.com/redirect.php
- 协议混淆：xip.io、DNS重绑定
- 特殊字符：http://localhost@evil.com
4. 联合防御体系构建
4.1 代码层防护
CSRF防护示例（Spring Security）：
@Configuration public class SecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()); } }SSRF防护示例（Java URL过滤）：
public static boolean isSafeURL(String url) { try { URI uri = new URI(url); if (!"https".equals(uri.getScheme())) return false; if (uri.getHost().endsWith(".internal.com")) return false; return !isPrivateIP(uri.getHost()); } catch (Exception e) { return false; } }4.2 架构层防护
推荐的安全增强措施：
- 网络隔离：关键内网服务禁止外网访问
- 出口过滤：限制服务器出站连接白名单
- 云安全：禁用实例元数据公开访问
- WAF规则：拦截恶意SSRF特征请求
5. 实战案例分析
5.1 DVWA CSRF漏洞利用
DVWA（Damn Vulnerable Web App）的低安全级别下：
- 修改密码页面无CSRF防护
- 构造恶意链接：
http://dvwa/vulnerabilities/csrf/?password_new=hack&password_conf=hack&Change=Change- 诱使管理员点击后，密码被修改
修复方案：添加随机token校验
$token = bin2hex(random_bytes(32)); $_SESSION['token'] = $token; if ($_POST['token'] !== $_SESSION['token']) { die("CSRF token validation failed"); }5.2 CTF SSRF题目突破
某CTF题目要求通过SSRF获取flag：
- 发现图片加载接口存在SSRF：
/api/load?url=http://example.com/image.jpg- 尝试访问内网服务：
/api/load?url=http://127.0.0.1:8080/flag.txt- 被过滤后使用进制绕过：
/api/load?url=http://0177.0.0.1:8080/flag.txt6. 企业级防护建议
根据OWASP Top 10 2021要求：
- CSRF防护清单：
- 所有状态修改请求使用POST
- 关键操作添加re-authentication
- 实施SameSite Cookie策略
- 定期进行渗透测试
- SSRF防护清单：
- 实施严格的URL白名单校验
- 禁用不需要的URL协议（如file://）
- 监控异常出站流量
- 定期更新依赖库（如libcurl）
我在金融系统安全审计中发现：超过60%的CSRF漏洞源于历史遗留系统未更新防护措施，而SSRF漏洞多发生在新兴的云原生应用中。建议企业建立漏洞生命周期管理机制，新系统上线前必须通过自动化扫描+人工验证双保险。
