我在Excel里埋了个链接,服务器乖乖替我访问了内网—

我在Excel里埋了个链接,服务器乖乖替我访问了内网——2026年文件导入SSRF新花样

最近的一次红队项目中，目标是一个提供“智能报表分析”的SaaS平台。用户上传Excel或CSV文件，平台会用AI自动识别表格内容、生成可视化图表。我上传了一份看似普通的销售数据表，但偷偷在一个单元格里藏了一个公式：=HYPERLINK("http://169.254.169.254/latest/meta-data/")。几分钟后，报表生成完毕，图表旁边还贴心地显示了“链接预览”——赫然正是目标服务器所在的云环境元数据。

文件导入功能引发的SSRF并不新鲜，但2026年AI加持下的自动解析，让这类漏洞变得更加隐蔽且危害巨大。今天我复盘这次完整的攻击链，从表格构造到拿下云控制台，全程干货。

一、漏洞根源：服务端为什么会访问我表格里的链接？

传统的文件导入SSRF多发生在一些“链接预览”功能中，比如导入书签、RSS订阅等。但这次面对的是一个“数据分析”平台，它的核心功能是识别表格里的数值并生成图表，为什么还会去请求外部URL？

关键就在“AI智能解析”这个功能。为了提升用户体验，平台在导入文件后，不仅识别数值，还会自动提取单元格中的URL，并发起请求获取网页标题、favicon等信息，用于生成“富文本预览”。这就像是Excel里的=HYPERLINK功能被服务端原样执行了——只不过执行环境从你的笔记本变成了云端服务器，而且网络权限直通内网。

更致命的是，开发团队为了兼容各种格式，使用了Apache POI、Python openpyxl等多个库来解析Excel，而这些库对单元格内容的处理方式存在差异。当单元格内容以http://开头时，后端会无条件地发起一个HTTP GET请求，既不检查目标IP是否属于内网，也不限制协议。这简直就是给攻击者留的一扇暗门。

二、构造恶意表格：从HYPERLINK到WEBSERVICE

我准备了两种利用方式，分别针对Excel和CSV格式。

Excel方式：=HYPERLINK函数

新建一个Excel文件，在A1单元格输入商品名称，B1单元格输入详情链接，看起来就像正常的商品数据表。然后在B2单元格输入公式：

=HYPERLINK("http://169.254.169.254/latest/meta-data/")

再随意填充几行正常数据作为伪装。保存为.xlsx上传。

CSV方式：直接写入URL

CSV没有函数，但可以更粗暴地在某个字段里直接写入URL。比如：

订单号,金额,备注1001,299,http://169.254.169.254/latest/meta-data/

后端解析CSV时，如果遇到以http://开头的字符串，同样可能发起请求。

上传后不到半分钟，平台生成的报表里，那个链接预览卡片就出现了：标题显示为iam/security-credentials/，这正是AWS元数据服务的目录结构。我心跳加速——SSRF打穿了。

三、从SSRF到云凭证窃取：一步一步深入

既然能访问元数据根目录，就能进一步读取具体角色名和临时凭证。

枚举角色名
再次上传包含链接http://169.254.169.254/latest/meta-data/iam/security-credentials/的表格，预览卡片显示了一个角色名ai-analysis-role。
获取临时密钥
第三次上传，链接指向http://169.254.169.254/latest/meta-data/iam/security-credentials/ai-analysis-role。返回的页面内容包含了AccessKeyId、SecretAccessKey和Token，有效期为6小时。
接管云权限
在本地配置AWS CLI，使用窃取的凭证，执行aws sts get-caller-identity确认身份，随后aws s3 ls列出所有S3存储桶。里面存放着该平台所有用户上传的原始表格和分析结果，其中不乏企业财务报表、用户个人信息等敏感数据。

整个过程，我只上传了三个几KB的Excel文件，全程没有触发任何WAF或IDS告警。因为流量看起来就是正常的文件上传和报表生成，HTTP请求也是从合法的应用服务器发出，一切“合乎情理”。

四、这种漏洞为什么到现在还层出不穷？

业务需求压倒安全考量：产品经理要求“自动识别链接并生成预览”，开发就照做了，很少人会想到应该加个白名单或禁用内网访问。
新旧库混用的解析差异：处理Excel的库五花八门，有的把=HYPERLINK当作普通文本，有的却会计算并返回链接值。攻击者可以利用这种差异，构造一个在安全扫描时看起来无害、实际执行时却触发请求的表格。
内网防护缺失：很多云环境没有启用IMDSv2（强制Token认证），或者服务器绑定了过高的IAM角色权限，导致一旦SSRF就能直接拿到高权限凭证。
AI功能引入新攻击面：2026年大量SaaS产品集成AI，比如“智能摘要”“链接预览”“自动化数据分析”，这些功能都需要服务端访问用户提供的URL，无形中放大了SSRF的威力。

五、如何防护？

服务端禁止访问内网：在发起任何用户指定的URL请求前，必须先解析域名并检查IP是否属于私有地址、环回地址或元数据服务地址。可使用iptables或安全组限制出站流量。
禁用危险的Excel函数：如果业务不需要，应在解析时忽略=HYPERLINK、=WEBSERVICE、=IMPORTDATA等能发起外部请求的函数。
启用云平台高级防护：比如AWS的IMDSv2，要求请求元数据时携带Token，即使有SSRF也无法直接获取凭证。
最小权限原则：运行文件解析服务的服务器，应使用限制最大的IAM角色，避免赋予S3、RDS等资源的访问权限。
监控异常出站连接：对服务器向169.254.169.254等特殊地址的请求设置告警，及时发现SSRF尝试。

六、结语

文件导入是一个被严重低估的攻击面。尤其是当AI能力被不断加入，服务端“越俎代庖”替用户访问链接的场景越来越多。下次你在SRC中遇到能上传Excel、CSV甚至Markdown的功能，别忘了在表格里塞几个内网链接试试。说不定一份平平无奇的报表，就成了你进入内网的通行证。

严正声明
本文所述技术仅用于合法授权的安全测试，所有案例均已脱敏并修复。未经授权利用此类漏洞入侵计算机系统属于违法行为，与作者无关。请遵守法律法规，守护网络安全。