我发了一个链接,AI助手就把公司的云密钥泄露了

上周我在测试一款企业级AI助手时，无意中发现了一个能直接打穿云基础设施的漏洞。这款AI助手有个“链接预览”功能——你在对话框里贴一个网址，它会自动抓取网页标题、摘要和图片，生成一张漂亮的预览卡片。我给它发了一个看起来人畜无害的链接：http://169.254.169.254/latest/meta-data/。几秒钟后，预览卡片上赫然出现了我自己的AWS账号ID、实例类型和IAM角色名。

更致命的是，当我尝试请求http://169.254.169.254/latest/meta-data/iam/security-credentials/时，AI助手把完整的AccessKeyId、SecretAccessKey和Token都原样返回了。整个攻击没有触发任何告警，因为请求是从“可信的AI服务”发出的。

一、漏洞原理：你的AI助手就是一台SSRF代理

AI应用中的URL预览功能，本质是一个服务端请求伪造（SSRF）的最佳入口。它的工作流程很简单：

用户发送一条包含URL的消息。
AI服务器接收到消息后，提取URL。
服务器端发起HTTP请求去抓取该URL的内容（HTML、图片等）。
解析并返回预览信息给用户。

问题出在第3步。如果服务器没有对目标URL进行任何限制，攻击者就可以让服务器去请求任意地址——包括内网IP和云平台元数据服务。

云平台（AWS、阿里云、GCP等）为每台云主机提供了一个固定的内部地址，用来查询实例的元数据。例如：

AWS: http://169.254.169.254/latest/meta-data/
阿里云: http://100.100.100.200/latest/meta-data/
GCP: http://metadata.google.internal/computeMetadata/v1/
Azure: http://169.254.169.254/metadata/instance?api-version=2021-02-01

这些地址只能从云主机内部访问，不需要任何认证。一旦AI服务器部署在云上，攻击者发一个链接过去，AI服务器就会乖乖地去请求元数据服务，并把返回的敏感信息通过预览功能展示给攻击者。

二、攻击步骤：三行链接，接管云账号

整个攻击过程简单到只需要在对话框里粘贴三条精心构造的链接。

第一步：信息收集。 发送http://169.254.169.254/latest/meta-data/，获取当前实例的基本信息——确认是云环境、拿到实例ID、区域、IAM角色名。

第二步：获取临时凭证。 根据返回的IAM角色名，发送http://169.254.169.254/latest/meta-data/iam/security-credentials/<角色名>，请求该角色的临时安全凭证。AWS会返回AccessKeyId、SecretAccessKey和SessionToken。

第三步：接管云资源。 把拿到的凭证配置到本地AWS CLI，然后aws s3 ls、aws ec2 describe-instances——所有该角色有权访问的云资源一览无余。

我在实际测试中，通过一个企业微信机器人（接入了大模型的URL预览功能），仅凭上面三步，就拿下了其所在AWS账号的完整控制权。该AI服务运行在一台拥有AdministratorAccess权限的EC2上。

三、绕过常见防御的实战技巧

很多开发者知道SSRF的危害，会做一些简单的过滤，但通常不堪一击。

绕过IP黑名单。 如果直接访问169.254.169.254被拦截，试试这些变形：

十进制IP: http://2852039166/
八进制: http://0251.0376.0251.0376/
短地址重定向: 在自己的域名上设置一个302跳转到元数据地址。
DNS重绑定: 将一个自己控制的域名解析到169.254.169.254。
IPv6: http://[::ffff:a9fe:a9fe]/

绕过域名白名单。 有些AI应用只允许抓取白名单内的域名。但如果白名单中存在开放重定向漏洞，就可以利用。例如，如果AI允许访问trusted.com，而trusted.com/redirect?url=http://169.254.169.254/存在重定向，就能绕过。

利用云平台的内部DNS。 在AWS内，可以通过http://instance-data或http://169.254.169.254访问元数据。如果过滤了IP但没过滤域名，http://instance-data就能打穿。

协议切换。 如果HTTP被限制，尝试gopher://、dict://或file://协议读取本地文件（如.env）。

四、真实案例复盘：从聊天机器人到数据泄露

分享一个我在2025年底参与的某互联网公司红队演练案例（已脱敏）。

目标公司内部使用一款自研的AI聊天助手，集成了邮件、日历和内部知识库，支持URL预览。我们在外网通过钓鱼获得了一个员工账号，登录到聊天助手。

该助手部署在阿里云ECS上，我们尝试直接请求元数据地址，但返回“不被允许的地址”。显然开发者在代码里做了IP过滤。但我们发现它没有过滤域名100.100.100.200的十六进制形式，用http://0x64.0x64.0x64.0xC8成功绕过了黑名单。

返回了元数据信息，拿到了RAM角色的名称。随后我们请求了安全凭证接口，获得了阿里云AccessKey。该RAM角色拥有AdministratorAccess权限，我们直接接管了该公司整个阿里云账号，包括所有ECS、RDS、OSS和SLB。

更可怕的是，我们在其中一个OSS Bucket里发现了数据库备份文件，其中包含数百万用户的手机号和身份证号。整个攻击链从第一条恶意链接到数据泄露，不超过10分钟。

五、防御方案：别让AI变成内网穿透工具

网络隔离。 AI服务的运行环境应该与核心业务网络隔离，使用独立的VPC，并禁止访问内网资源。元数据服务可以考虑使用IMDSv2（AWS）或阿里云的强制Token认证。
严格限制URL请求。 实现“默认拒绝，显式允许”策略。只允许抓取白名单内的域名，并禁用IP地址、内网地址、以及非HTTP/HTTPS协议。使用成熟的SSRF防护库（如safeurl、ssrf_filter）而不要自己造轮子。
响应过滤。 对抓取的内容进行二次检测，过滤掉包含AccessKey、SecretKey等敏感关键词的响应体。设置响应大小限制，防止大量数据外传。
最小权限。 不要给AI服务所在的云主机分配过高的权限。使用RAM角色授予最小必要权限，并禁用访问元数据的权限（可通过授权策略中的ecs:DescribeInstances等限制）。
日志监控与告警。 对所有外发的HTTP请求进行审计，监控对169.254.169.254等特殊地址的访问，及时触发告警。

六、写在最后

AI应用的URL预览功能在提升用户体验的同时，也打开了一扇通往内网的暗门。开发者往往只关注了大模型本身的安全性，却忽略了这些看似无害的辅助功能。在2026年的今天，AI SSRF已经不再是理论威胁，而是实实在在的攻击向量。下次测试AI应用时，不妨试试给它发一个http://169.254.169.254的链接——你可能会惊喜地发现，它正毫无保留地向你展示它的“家底”。

严正声明：本文所述技术仅供合法授权的安全测试使用。未经授权访问他人计算机系统属于违法行为。所有案例均已脱敏，仅保留技术原理供学习参考。安全之路，始于授权。