文章总结： 文章揭示Serverless架构中63%的企业存在高危函数配置风险，核心攻击面包括函数配置权限过大、依赖链投毒、事件源注入及环境变量明文密钥泄露。通过真实案例展示SSRF到凭证泄露再到横向移动的完整攻击链，提出IAM最小权限、代码输入校验、依赖扫描和监控告警四道防线。建议本周内审计IAM角色、迁移明文密钥至SecretsManager、开启函数URL认证、扫描依赖并启用CloudTrail数据事件记录。 综合评分： 85 文章分类： 实战经验,漏洞分析,云安全,红队,渗透测试

Serverless安全实战：Lambda函数的暗面你一定不知道

原创

安全值班室 安全值班室

安全值班室

2026年7月7日 09:00 北京

在小说阅读器读本章

去阅读

Palo Alto Networks Unit 42报告：采用Serverless架构的企业中，63%存在至少一个”严重”或”高危”的函数配置风险。更扎心的是——这63%中，超过一半的人并不知道自己的函数在裸奔。

Serverless不是”无服务器”，是”无服务器归你管，但有风险你得自己扛”。今天不扯概念，直接拆攻击面、看真实案例、上实操方案。

📌 攻击面四维度 函数代码 → IAM权限 → 依赖包 → 事件源配置。每一块都有坑。

一、Serverless攻击面：四个维度▎ 1.1 函数配置：权限过大的恶果2023年一个真实案例引发广泛关注：某SaaS公司的AWS Lambda函数用来处理用户上传的图片，函数的IAM角色有s3:PutObject权限——这合理，因为处理完要写回S3。但检查发现这个角色还有dynamodb:Scan权限（开发阶段遗留的调试权限）。攻击者通过一个图片处理参数注入，层层推进：

1. 利用未过滤的图片URL参数触发SSRF，访问AWS元数据端点
2. 获取临时凭证（Lambda执行角色的STS Token）
3. 用令牌调用DynamoDB Scan——700万条用户记录全部泄露

💡 教训 每个函数的IAM角色应该精确到具体的资源ARN，而不是通配符*。Lambda是”一个函数一个角色”的最佳实践推行者，但很多人仍然图方便用了一个全功能角色。精准权限在AWS IAM里就是一行配置的事，但省了这行代码的代价是700万条记录。

▎ 1.2 依赖链：函数代码的开源投毒Serverless函数通常体积小、依赖多。一个简单的Node.js Lambda可能拉100多个npm包，每个包都有潜在风险。2024年9月，研究人员在npm上发现了40多个专门针对AWS Lambda的恶意包——它们伪装成常见的工具库，一旦被导入Lambda函数，攻击者就能通过包中嵌入的”回调”代码窃取环境变量和临时凭证。更隐蔽的是“合法软件的供应链投毒”：2025年3月攻击者入侵了一个维护中的Serverless框架核心插件，在版本更新中植入了后门，所有使用该插件的Serverless应用在部署时会自动向攻击者的C2服务器发送环境变量。这个后门存活了17天才被发现，期间影响了超过5000个Serverless项目。

🛡️ 防守要点 • 锁定依赖版本号（package-lock.json/lockfile）并做完整性校验 • 用npm audit / Snyk / Trivy做依赖扫描，阻断高危包进入构建流程 • 函数部署前做SBOM生成，跟踪每个依赖的来源

▎ 1.3 事件源注入：最隐蔽的攻击面Serverless函数被动触发——S3上传、API Gateway请求、SQS消息、DynamoDB Streams。这些事件源里携带的数据，很多开发者直接当”可信输入”处理了。最经典的案例：SQS投毒。攻击者向一个公开的SQS队列发送了一条精心构造的消息，消息体里包含命令注入payload。

处理该消息的Lambda函数直接eval(message.body)。

更常见的场景是API Gateway + Lambda的组合：API Gateway把HTTP请求体直接传到Lambda，Lambda的event.body如果有SQL注入或命令注入漏洞，攻击者就能绕过WAF（因为WAF在API Gateway层可能没配，或者配置的规则不够细）。

⚠️ 必须做 所有输入都做校验和过滤——不管是来自API Gateway的HTTP请求、来自S3的Object事件、还是来自SQS的消息体。Serverless世界里，输入没有”可信”的。

▎ 1.4 环境变量：明文密钥的重灾区AWS Lambda Console里的环境变量默认是明文的。很多人把数据库密码、API密钥、云服务凭证直接写在环境变量里——只要你有GetFunctionConfiguration权限，就能通过CLI一次性拉出所有函数的变量：

aws lambda get-function-configuration --function-name my-function --query 'Environment.Variables'

✅ 正确做法 用AWS Secrets Manager或Parameter Store（SecureString），在Lambda代码中用SDK运行时读取，而不是直接在环境变量里硬编码明文密钥。

二、真实案例：两条Lambda函数的沦陷史2024年7月，安全研究员披露了一起完整的Serverless攻击链复盘。过程还原：

▶ 第一阶段：SSRF打Lambda内网 — 攻击者发现一个公网API（API Gateway + Lambda）的data参数会拼接到一个第三方URL里。传入http://169.254.169.254/latest/meta-data/iam/security-credentials/，Lambda直接把请求结果返回了。 ▶ 第二阶段：凭证泄露 — Lambda的元数据端点返回了临时凭证（AccessKeyId、SecretAccessKey、Token），攻击者拿到凭证后配置了AWS CLI。 ▶ 第三阶段：横向移动 — 该函数角色能lambda:InvokeFunction其他12个函数（全给*通配了），还能s3:GetObject所有bucket。攻击者遍历调用所有Lambda，发现其中一个函数里明文存了RDS数据库密码。 ▶ 第四阶段：数据库沦陷 — 拿到密码后攻击者通过Lambda内网IP做横向连接。最终200万条用户信息被窃取。

⚠️ 关键发现 这个案例里每一个环节都不是0day，全是配置问题和代码漏洞的组合链。把任何一个环节堵住，攻击链就断了。

三、防守实操：四道防线▎ 3.1 IAM最小权限（第一道线）每个Lambda一个专属执行角色。规则是：不给任何”可能以后会用”的权限。Action和Resource都不要用通配符：

# ❌ 错误：给太多
{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

# ✅ 正确：精确到bucket和prefix
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-bucket/uploads/*"
}

▎ 3.2 代码安全（第二道线）Lambda函数代码不要直接处理用户输入。输入校验库要上，正则、白名单、输入长度限制全部要。特别是从API Gateway过来的HTTP请求——不要相信event.body里的任何字段。用WAF关联API Gateway做第一层过滤。2025年AWS WAF新增的JA3指纹规则集可以检测已知恶意工具发送的请求特征。▎ 3.3 依赖与镜像安全（第三道线）

• 用Amazon ECR镜像扫描或Trivy做漏洞扫描，阻断高危镜像部署 • 启用Amazon Inspector自动扫描Lambda函数依赖（2025年已原生支持） • 启用签名验证（Sigstore/Cosign），只部署签名的Lambda镜像

▎ 3.4 监控与告警（第四道线）

# CloudWatch告警规则要点：
# 1. Lambda错误率突增 > 阈值 → 可能被异常数据投毒
# 2. 从元数据端点(169.254.169.254)的调用 → SSRF告警
# 3. 函数执行时间远超基线 → 可疑行为（数据外带）
# 4. 一个函数的IAM角色被跨区域调用 → 凭证泄露

四、一周内能做的五件事别想着一次性把所有Serverless函数的安全做完美。下面这五件事，本周就能搞定：

1️⃣ 审计IAM角色 — aws iam list-roles | grep lambda导出所有Lambda执行角色，检查有没有Resource:”*”或Action:”*” 2️⃣ 禁用明文环境变量 — 检查Console里的Lambda环境变量是否有明文密码，立即迁移到Secrets Manager 3️⃣ 开启函数URL的IAM认证 — 如果函数直接暴露了Function URL，确认开启了AWS_IAM认证模式 4️⃣ 扫描依赖 — 用npm audit / pip audit / Trivy扫描每个函数的依赖清单 5️⃣ 打开CloudTrail的Lambda数据事件 — 记录Invoke操作的来源，方便溯源

Serverless的悖论很明显：开发效率极高，安全认知极低。63%有高危风险的核心原因不是工具不行，是有太多人把”Serverless”理解成了”安全不用管”。权限最小化、依赖扫描、输入校验——这些在传统服务器上就在做的事，换到Serverless上一样要做。你不需要两周内给所有Lambda配上WAF和GuardDuty。从审计IAM角色和迁移明文密钥开始，这两件事一天就能做完，但能挡住一半以上的攻击路径。

觉得有用？点个在看支持一下

📌 值班员说 63%的Serverless架构存在高危风险，但更可怕的是这63%中有一半以上的人毫不知情。你的Lambda函数可能正在用明文环境变量存着RDS密码、用的依赖包里有人偷偷埋了后门、IAM角色还挂着S3读写通配符。今天就做一件事——打开Lambda控制台，检查你的函数里有几个IAM角色用的是”Resource:*”。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全值班室 安全值班室 安全值班室《Serverless安全实战：Lambda函数的暗面你一定不知道》