理解跨域资源共享（CORS）与潜在风险
在现代Web应用架构中，浏览器同源策略是保障用户安全的重要机制，它限制了网页脚本从不同源加载资源的能力。然而，为了满足日益复杂的业务需求，如前后端分离、API 调用等，跨域数据传输变得不可或缺。正是在这种背景下，跨域资源共享（CORS）机制应运而生。CORS 允许服务器在安全的前提下，放宽同源策略的限制，使得特定来源的网页能够请求跨域资源。
尽管CORS的设计初衷是为了提升Web的灵活性和功能性，但若服务器端配置不当，CORS 本身也可能成为攻击者利用的途径，导致严重的安全问题。这些配置错误可能暴露出应用程序的敏感数据，甚至允许攻击者劫持用户会话或执行未经授权的操作。对CORS漏洞的深入理解和防范，是当前Web安全领域不容忽视的一环。
CORS 漏洞的常见形态
CORS 漏洞的出现，通常源于服务器对“允许的来源”（`Access-Control-Allow-Origin`）头部处理不当，或者对“是否允许携带凭证”（`Access-Control-Allow-Credentials`）的处理过于宽松。以下是几种典型的误配置情况：
反射型源验证缺陷
当服务器端直接读取请求中的 `Origin` 头部，并将其未经严格验证地原样返回到 `Access-Control-Allow-Origin` 头部时，便构成了反射型源验证缺陷。这意味着，无论攻击者在 `Origin` 头部中发送什么内容，服务器都会认为这是一个被允许的源。攻击者可以构建一个恶意网页，通过 JavaScript 发起带有受害者凭证的跨域请求，并接收到服务器返回的敏感数据。
通配符 (*) 结合凭证许可
在某些情况下，服务器为了图方便，会将 `Access-Control-Allow-Origin` 设置为通配符 `*`，表示允许任何来源访问。单独使用 `*` 并不一定构成漏洞，但如果同时将 `Access-Control-Allow-Credentials` 设置为 `true`，问题就出现了。这意味着任何来源的请求都可以携带用户的身份凭证（如 Cookie、HTTP 认证信息），并从服务器获取响应。攻击者可以借此盗取用户数据，或以用户身份执行操作。
对 Null 源的宽松处理
在某些特定场景，如本地文件、沙盒化 iframe 或使用特定协议的请求，浏览器可能会发送 `Origin: null`。如果服务器将 `null` 视为一个合法的或被允许的源，那么恶意HTML文件或经过精心构造的请求就可以利用这一缺陷，绕过同源策略，访问受保护资源。
不严格的正则表达式匹配
一些服务器可能会使用正则表达式来验证 `Origin` 头部。如果正则表达式编写不严谨，例如允许子域名绕过验证，或者允许通过添加特定字符串来匹配合法域名，攻击者就能构造一个貌似合法的 `Origin` 头部，从而绕过服务器的CORS策略。
CORS 漏洞的利用途径
一旦发现CORS配置缺陷，攻击者便可以采取多种策略进行利用，常见的利用方法包括：
敏感数据窃取
这是CORS漏洞利用中较常见的攻击目标。攻击者构建一个恶意网页，诱导用户访问。该网页中的 JavaScript 代码会向存在CORS漏洞的目标网站发起跨域请求。由于目标网站的CORS配置允许攻击者网站的访问，并且可能允许携带用户凭证，目标网站会将响应数据（如用户个人信息、订单记录、API 密钥等）发送给攻击者的恶意网站，从而实现数据窃取。
会话劫持与账户控制
当 `Access-Control-Allow-Credentials` 被设置为 `true`，且 `Access-Control-Allow-Origin` 配置存在缺陷时，攻击者可以利用CORS漏洞来执行会话劫持。恶意网站可以发送带有受害者凭证（如会话Cookie）的请求到目标网站的敏感接口，例如修改密码、发送邮件或进行转账。如果这些请求成功执行，攻击者便可以在用户不知情的情况下控制其账户，造成经济损失或声誉损害。
内部网络扫描与信息收集
在某些特殊情况下，如果Web应用所在的服务器同时对外开放和对内部网络提供服务，且其CORS策略配置不当，攻击者可能通过构造特定的CORS请求，尝试探测内部网络的端口开放情况，甚至收集内部服务的信息。这种利用虽然不直接窃取数据，但为后续更复杂的攻击提供了情报支持。
实践中的利用工具与辅助方法
进行CORS漏洞的检测与利用，通常需要借助一系列工具和技术：
* **浏览器开发者工具：** 这是最直接的工具。通过检查网络请求的响应头，特别是 `Access-Control-Allow-Origin`、`Access-Control-Allow-Credentials` 以及 `Vary` 等头部，可以初步判断是否存在CORS配置问题。
* **网络代理工具：** 像 Burp Suite 或 OWASP ZAP 这样的Web代理工具，能够截取、修改并重放HTTP请求。攻击者可以利用它们来篡改 `Origin` 头部，观察服务器的响应行为，从而验证CORS配置的脆弱性。这些工具还提供自动化扫描功能，帮助发现潜在的CORS漏洞。
* **自定义脚本：** 对于复杂的CORS漏洞利用场景，或需要自动化验证时，编写Python、JavaScript 等脚本是效率高的方式。这些脚本可以模拟浏览器行为，发送带有特定 `Origin` 头的请求，并解析服务器响应，以验证漏洞是否存在，并进行概念验证（PoC）的编写。
* **JavaScript `fetch()` 或 `XMLHttpRequest` API：** 在实际的浏览器环境中，通过 `fetch()` 或 `XMLHttpRequest` 对象，可以方便地构造跨域请求，并观察其在浏览器控制台中的表现，例如是否被CORS策略阻止，或者成功获得响应。
规避CORS漏洞的策略
要防范CORS漏洞，核心在于对 `Access-Control-Allow-Origin` 和 `Access-Control-Allow-Credentials` 头部的严格管理：
1. **明确指定允许的来源：** 避免使用通配符 `*`，特别是当请求需要携带凭证时。应明确列出所有允许进行跨域访问的域名，并确保这些域名受到严格控制。
2. **严格验证 `Origin` 头部：** 如果服务器需要动态生成 `Access-Control-Allow-Origin`，务必对接收到的 `Origin` 头部进行严格的白名单验证。确保 `Origin` 头部中的域名与预设的允许域名列表中的一项完全匹配，而不是进行子串匹配或弱正则匹配。
3. **谨慎处理凭证：** 仅当跨域请求确实需要携带凭证时，才将 `Access-Control-Allow-Credentials` 设置为 `true`。同时，确保此时 `Access-Control-Allow-Origin` 绝不能是 `*`，而必须是明确指定的单一来源。
4. **避免反射型 Origin：** 永远不要将客户端请求中的 `Origin` 头部原样反射到 `Access-Control-Allow-Origin` 响应头中，除非你确定该 `Origin` 已经在白名单中。
5. **合理处理 Null 源：** 除非有明确的业务需求，否则不应允许 `Origin: null` 进行敏感的跨域访问。
6. **定期安全审计：** 对Web应用程序进行定期的安全审计和渗透测试，尤其关注CORS配置，及时发现并修复潜在的漏洞。
通过实施这些策略，开发者能够构建更为稳固的Web应用，有效抵御利用CORS配置错误发起的攻击，保障用户数据的安全与系统的完整性。
