SSRF

服务端请求伪造会让服务器发出由攻击者选择或影响的请求。缩略图服务、导入器、Webhook 测试器或文档渲染器，可能到达请求用户无法直接访问的目标。服务器贡献的是自己的网络位置，以及这条具体抓取路径实际附带的凭据；取一个地址并不意味着进程可见的所有账号凭据都会自动加入请求。评估风险应从真实连接与认证方式开始。 先看清委托了什么权限 内部服务、回环管理端点和云元数据服务，在可达时都是重要目标。后果取决于认证、响应是否可见、允许的方法和网络策略。盲 SSRF 即使不返回目标正文，也可能触发动作或暴露时间信息。不能只凭功能名称给严重程度排位，而应确认它能联系什么，以及一次联系可以产生什么结果，尤其注意有副作用的内部接口。 在 EC2 上，实例附加了角色且相关访问被允许时，角色凭据可能通过元数据提供。角色名称列表与具体角色的凭据文档是不同请求。这些临时凭据代表该角色获得的权限，并不等于无限 AWS 访问，也不保证是实例上每个应用实际采用的凭据。目标没有角色、端点不可达或权限不足时，风险形态会不同，需要依照部署事实判断。 IMDSv2 要求先用 PUT 获取令牌，再在后续元数据请求中提供令牌。强制使用它可以挡住简单、没有认证头的单次 GET 路径，但不能解决能够控制必要方法和请求头的任意 SSRF。应结合最小权限角色与有效网络限制。元数据还可能通过 IPv4，以及启用并受支持时的 IPv6 到达；检查时不能只处理一种地址族。 解析、解析域名，并保留已检查的目标 允许列表应描述功能真正需要的目标。如果可以，接收资源标识而不是任意 URL。否则，应使用与 HTTP 客户端解释一致的解析器，限制协议、主机和端口。不需要的 userinfo 和歧义语法应拒绝，不能因为字符串某处出现了允许的域名，就认定目的地已经获准。解析函数有返回值，也不等于输入符合业务策略。 例如，位于 @ 前面的 trusted.example 是用户信息，不证明目标主机可信。旧式数字 IPv4 写法在不同解析器和解析库中可能有不同解释。IPv6 回环是 ::1，并不是 127.0.0.1，所以搜索一个固定字符串远远不够。一个运行时的解析结果，也不能直接成为另一个客户端行为的可移植保证。验证应围绕实际使用的组件版本建立。 解析允许的域名后，要按照预期网络策略检查返回的全部地址。只允许公网抓取时，应拒绝回环、私有、链路本地、多播以及其他禁止范围。地址库和登记规则会演进，因此要测试真正部署的版本。全球可路由也不代表目标是获准的、可信的或无害的服务；地址分类与业务允许列表解决的是不同问题，应同时保留。 坏掉的样子 先检查 DNS，再让客户端自行重新解析，会留下检查与使用之间的空隙。应通过受支持的传输机制固定经过验证的连接地址，同时保留原本的 TLS 主机名、证书校验和 HTTP authority。代理可能独立解析；因此须检查真实出口路径、重试与回退连接，不能假设一次本地预检控制了它们。固定地址也不能以关闭证书验证为代价。 ...