Web 安全必备知识：深入理解 SSRF、CSRF 和 CORS

在现代 Web 领域，安全不仅仅是一个功能，它是基础。随着应用程序变得越来越互联，理解跨域和跨服务器处理请求的微妙之处对于任何开发者来说都至关重要。

今天，我们将深入探讨每个 Web 开发者都应该掌握的三个核心概念：SSRF、CSRF 和 CORS。虽然它们听起来像字母缩写汤，但它们代表了 Web 应用程序安全的前线。

1. SSRF (服务端请求伪造)

SSRF 是一种漏洞，攻击者可以通过它迫使服务端应用程序向攻击者选择的任意域名发起 HTTP 请求。

工作原理

想象一个 Web 应用程序接收一个 URL 作为输入（例如，用于获取个人资料图片或预览链接），然后从服务器向该 URL 发起请求。如果应用程序没有正确验证该 URL，攻击者就可以提供内部 IP 地址或回环地址（127.0.0.1）。

作为代理的服务器可能会从不向公共互联网开放的内部服务中获取敏感数据，例如：

• 云元数据： 在 AWS/GCP 上访问 169.254.169.254 以获取 IAM 凭据。
• 内部管理面板： 访问 Jenkins 或 Kubernetes 控制面板等内部工具。
• 端口扫描： 发现内部网络中运行的其他服务。

防御措施

• 白名单： 仅允许向预定义的信任域名列表发起请求。
• 输入验证： 确保 URL 使用允许的协议（例如仅限 https://），且不指向内部 IP 范围。
• 网络隔离： 确保 Web 服务器对内部资源的访问受到限制。

2. CSRF (跨站请求伪造)

CSRF 是一种攻击，它诱导受害者的浏览器在受害者当前已登录的另一个网站上执行非预期的操作。

工作原理

这种攻击利用了浏览器在每次向域名发送请求时都会自动包含环境凭据（如会话 Cookie）的事实。

1. 用户登录 bank.com。
2. 用户在另一个标签页中访问恶意网站 evil.com。
3. evil.com 包含一个隐藏表单，向 bank.com/transfer?amount=1000&to=attacker 提交 POST 请求。
4. 浏览器将请求连同用户的 bank.com 会话 Cookie 一起发送。
5. bank.com 识别出有效的会话并处理转账。

防御措施

• 抗 CSRF 令牌： 在每个改变状态的请求中包含一个唯一的、秘密且不可预测的令牌。服务器在处理前验证该令牌。
• SameSite Cookie： 将 Cookie 的 SameSite 属性设置为 Strict 或 Lax，以防止它们在跨站请求中被发送。
• 自定义请求头： 对于 AJAX 请求，要求使用无法通过标准 HTML 表单设置的自定义请求头（如 X-Requested-With）。

3. CORS (跨源资源共享)

与 SSRF 和 CSRF 不同，CORS 本身不是漏洞，而是一种安全机制。它是服务器告诉浏览器的一种方式：“允许这个特定的外部源访问我的资源。”

为什么存在

默认情况下，浏览器强制执行 同源策略 (SOP)，该策略防止一个站点的脚本读取另一个站点的数据。这可以防止 evil.com 读取你在 gmail.com 上的邮件。

CORS 允许服务器安全地放宽这一策略。当 Web 应用发起跨源请求时，浏览器会发送一个 Origin 请求头。服务器响应 Access-Control-Allow-Origin。

常见配置错误

• 通配符源 (*)： 允许所有源。虽然对于公共 API 是可以的，但如果与 Access-Control-Allow-Credentials: true 结合使用则非常危险。
• 反射源： 根据 Origin 请求头动态设置允许的源而无需验证。这实际上完全绕过了 SOP。

最佳实践

• 明确指定： 仅允许需要访问的特定域名。
• 尽可能避免凭据： 如果你的 API 不需要 Cookie 或授权头，请不要允许它们。
• 使用安全中间件： 使用经过充分测试的库来处理 CORS 配置，而不是手动管理请求头。

总结对比

理解 Web 安全的这三大支柱对于构建健壮的现代应用程序至关重要。通过实施深度防御策略，你可以同时保护服务器的内部基础设施和用户的私有数据。

保持安全，祝你编程愉快！