SSRF

任何「从用户那里拿一个 URL、再由服务端去抓」的功能，都是在用服务器的身份、网络位置与凭据去跑这次抓取。缩略图生成、Webhook 测试、数据导入、PDF 渲染——只要目标来自请求，攻击者就不再是「自己去访问你的内网」，而是让你的服务器替他访问。 它比大多数注入类漏洞更值得优先处理，原因在可达性。服务器坐在边界之内：它能打开回环上的管理面板、能连 RFC 1918 网段里的服务、也能碰到云厂商提供实例凭据的那个 link-local 地址。攻击者与这张内网之间唯一的阻隔，就是那段决定「哪些 URL 可接受」的代码——而那段代码通常是一次字符串比较。 这次抓取带着服务器的权限 最经典的目标是实例元数据服务。在 AWS 上它监听 169.254.169.254，而 GET /latest/meta-data/iam/security-credentials/ 会返回实例所挂 IAM 角色的名字，紧接着就是该角色的临时凭据。实例的每一次 AWS API 调用用的都是这份凭据，所以一次打到元数据端点的 SSRF 不只是读到一个配置文件——它交出的是这台实例的云身份。OWASP 对内部 REST 接口、以及对那些「本来就只打算在内网可达」因而根本不带认证的 HTTP 数据库接口，记录的是同一种形态。 实验把两半都测了。对着一个本地替身，它用 127.0.0.1 的十六进制写法去打一个只检查 URL 字符串的校验，结果是 ALLOWED，抓取返回了一份凭据文档。接着它测加固：一台只开 v2 的实例对裸 GET 回 401，只有当请求带上 X-aws-ec2-metadata-token 时才放出元数据，而这个值攻击者必须先用 PUT /latest/api/token 拿到。一次只读一个 URL 的单发 SSRF 走不完这套握手。 ...