他把SSRF写成CSRF，赏金从1.2万跌到150美元

「那篇报告本该拿1.2万美元，他只拿到150。」一位白帽子猎人告诉我这个故事时，我正在整理漏洞赏金的分类错误案例。同样的端点，同样的请求操控，两个字母的差别——S和C——让赏金缩水了80倍。

这不是孤例。我在HackerOne、Bugcrowd，以及自己的培训中反复看到：服务器端请求伪造（SSRF，Server-Side Request Forgery）和跨站请求伪造（CSRF，Cross-Site Request Forgery）被混为一谈。本文从HTTP请求层面拆解二者的本质区别——不是背定义，而是拿到一个请求就能立刻判断归属。

核心分野：谁在发起请求

区分SSRF和CSRF，关键看请求的发起者是谁。

SSRF：攻击者操控服务器，让服务器向内部或外部资源发起请求。受害者是服务器本身。

CSRF：攻击者诱骗已登录用户的浏览器，以用户身份向目标站点发起请求。受害者是用户。

这个区别直接决定了漏洞的攻击面、利用条件和赏金等级。SSRF能打到内网服务、云元数据端点，甚至触发供应链攻击；CSRF通常限于用户权限内的操作，除非配合其他漏洞链。

那位猎人的案例很典型。他发现的端点接收用户输入的URL，服务端未做校验便发起请求。这是经典的SSRF入口——服务器成了攻击者的代理。但他报告写成CSRF，程序方按「用户被诱骗点击恶意链接」的模型评估，给了低危评级。

两周后他看到别人的披露，才意识到服务端请求可以被重定向到169.254.169.254（云元数据服务地址），获取临时凭证。这是SSRF的标准利用路径，通常评级为严重（Critical）。

SSRF的运作机制：为什么它值严重级

SSRF的杀伤力来自服务器的特权位置。它通常位于内网边界，能访问防火墙后的资源，且自带可信身份。

攻击路径通常这样展开：找到接收URL或IP输入的功能点（图片下载、Webhook配置、PDF生成、文件导入）→ 输入指向内网或受限资源的地址 → 服务端发起请求 → 读取响应或观察副作用。

高价值目标包括：云元数据端点（AWS 169.254.169.254、Azure 169.254.169.254:80/metadata）、内部管理接口、Kubernetes API、数据库（如未认证的Redis、Elasticsearch）、以及通过Gopher/FTP等协议触发的二次攻击。

赏金程序给SSRF严重评级，通常基于以下影响维度：内网横向移动能力、云凭证泄露风险、数据泄露规模、以及是否无需用户交互即可利用。一个能读取AWS IAM凭证的SSRF，在AWS环境下几乎必然严重；如果只能打到内网一个404页面，可能降级为中危。

探测SSRF需要系统化的攻击面映射。关注这些功能特征：任意URL获取（图片代理、缩略图生成）、Webhook/回调配置、文件格式转换（PDF/Office）、XML解析器（XXE常伴随SSRF）、以及任何「用户输入→服务端发起网络请求」的链条。

协议走私是进阶技巧。某些解析器对http://evil.com@internal.service这种URL处理不当，把@后的部分当主机名；或者利用302重定向绕过前端校验，让服务端实际请求内网地址。DNS重绑定（DNS Rebinding）则是时间差攻击：第一次解析返回公网IP通过校验，TTL设极短，第二次解析返回内网IP，服务端缓存未更新时发起请求。

CSRF的运作机制：何时能拿到严重评级

CSRF的核心是「借用用户身份」。攻击者构造恶意页面，诱导已登录目标站点的用户访问，浏览器自动携带Cookie发起请求。站点无法区分这是用户主动操作还是被迫执行。

传统CSRF的利用条件较苛刻：需要用户处于登录状态、能预测请求参数（无不可预测的令牌）、以及社交工程诱导点击。这限制了其影响范围，多数程序给中危或低危评级。

但CSRF进入严重级的场景真实存在。关键变量是「操作本身的敏感性」和「利用的自动化程度」。

以下CSRF场景通常评级严重：修改账户绑定邮箱（无需确认即可接管账户）、关闭双因素认证、转账或支付操作（尤其无额外验证时）、以及配合存储型XSS实现的「自传播」攻击——用户访问即执行，执行后生成新的恶意链接。

现代Web的CSRF防御已较成熟：SameSite Cookie、CSRF Token、自定义Header校验、以及Referer检查。绕过这些防护需要更精细的技巧：JSON CSRF（利用Content-Type差异）、PUT/DELETE方法的表单提交（某些框架处理不当）、以及针对SameSite=Lax的定时攻击（利用POST跳转的窗口期）。

一个常被忽视的向量是「登录CSRF」。攻击者用自己的凭证登录受害者浏览器，将其绑定到攻击者账户。后续受害者在该会话下的所有操作（收藏、地址填写、甚至支付卡绑定）都关联到攻击者账户。这种漏洞因利用链较长常被低估，但在特定业务场景下影响深远。

对照速查：HTTP层面的即时判断

拿到一个疑似漏洞，用这三个维度快速归类：

请求发起者：SSRF是服务器→目标资源；CSRF是用户浏览器→目标站点。

身份凭证：SSRF携带服务端的内部身份（云实例角色、服务账户Token）；CSRF携带用户的会话Cookie。

攻击入口：SSRF需要服务端存在「用户输入→发起网络请求」的功能；CSRF需要用户已登录且能访问恶意页面。

响应读取：SSRF通常能读取响应（盲SSRF除外），直接获取数据；CSRF通常无法读取响应（受同源策略限制），依赖副作用判断。

典型误报场景：一个端点既接收用户输入的URL，又需要用户Cookie认证。猎人容易混淆——这是SSRF还是CSRF？关键测试：用curl直接请求该端点，不带任何用户Cookie。如果服务端仍发起请求，是SSRF；如果返回401或重定向登录，则可能是CSRF（需进一步验证Token机制）。

另一个陷阱是「带外交互」类漏洞。某些功能让用户输入URL，服务端仅做异步回调（如Webhook验证），不返回响应。这可能是盲SSRF，需配合DNS日志或Burp Collaborator探测。若误判为CSRF，会完全错误估计攻击面和赏金等级。

报告写作：分类正确才能拿到对应赏金

漏洞分类错误是赏金损失的主因之一。程序方的安全工程师按你报告的分类启动评估流程——SSRF走基础设施风险模型，CSRF走用户交互风险模型。起点的偏差会导致整个评估框架错位。

写SSRF报告时，必须明确回答：服务端哪个功能发起了请求？输入点在哪里？能打到哪些内网资源或外部端点？是否读取到敏感响应？建议的修复方案是输入校验（URL白名单、禁用非必要协议）还是网络隔离（禁止服务端访问内网IP段）。

写CSRF报告时，核心是证明「用户无感知执行敏感操作」。提供完整的PoC：HTML页面代码、用户前置条件（登录状态、特定页面）、以及操作后的状态变更证据。如果涉及绕过现有防护（如SameSite=Lax下的POST利用），详细说明绕过逻辑。

那位150美元报告的教训：他没有验证「服务端是否主动发起请求」这一关键事实。如果他在报告中附上服务端访问内网IP的日志证据，程序方会立即识别为SSRF。缺乏这个证据，他的描述被归入「用户诱骗点击」的叙事框架。

赏金谈判中，分类争议是常见拉锯点。如果你认为程序方低估了严重程度，用具体影响说话：SSRF能访问的元数据端点版本（IMDSv1还是v2）、CSRF能触发的资金操作金额上限、以及同类漏洞的历史赏金数据。SecurityElites的工具库中的端口扫描和DNS查询工具，能在复测阶段帮你固化证据。

实战训练：三个练习构建直觉

区分SSRF和CSRF需要大量案例训练，直到形成模式识别的直觉。

练习一：浏览器端SSRF攻击面测绘。打开目标应用的开发者工具，监控Network面板。寻找以下请求特征：请求URL包含用户输入的参数、响应Content-Type为图片但URL指向外部域名、以及任何携带完整URL路径的API端点。对每个可疑端点，尝试替换为http://127.0.0.1、http://169.254.169.254、以及你的DNS日志域名，观察服务端行为差异。

练习二：CSRF目标分析思维。选取一个需要登录的Web应用，列出所有状态变更操作（POST/PUT/DELETE）。对每个操作，检查：是否缺少CSRF Token？SameSite Cookie属性是什么？是否有自定义Header校验？尝试构造最简PoC：一个纯HTML表单，action指向目标端点，method匹配操作类型，提交后观察是否能在新会话中复现状态变更。

练习三：浏览器高级CSRF。针对有防护的目标，测试边缘案例：Content-Type为text/plain的POST是否被接受（某些JSON端点允许）、PUT/DELETE是否可通过_method参数模拟（Ruby on Rails遗留模式）、以及SameSite=None的Cookie在跨站POST中的携带行为。记录每个测试的浏览器版本差异——Chrome和Firefox的默认策略并不完全一致。

这三个练习的共同点：从HTTP层面观察行为，而非依赖工具输出。Burp的扫描器会标记「疑似SSRF」，但无法判断内网可达范围；CSRF PoC生成器可能忽略Token的动态验证逻辑。手动验证是赏金猎人区分于自动化扫描的核心能力。

行业影响：为什么这个区分越来越值钱

云原生架构放大了SSRF的杀伤力。微服务间的内部调用、服务网格的Sidecar代理、以及无服务器函数的临时凭证，都依赖「服务端发起请求」的机制。一个容器内的SSRF，可能通过实例元数据获取整个集群的访问密钥。

与此同时，现代浏览器的安全策略在压缩传统CSRF的空间。SameSite=Lax成为默认、Partitioned Cookie的推进、以及逐步淘汰的第三方Cookie，都在提高CSRF的利用门槛。但这不意味着CSRF消失——它向更复杂的绕过技术演进，并在移动端WebView、旧版企业应用等边缘场景持续存在。

对赏金猎人而言，SSRF和CSRF的赏金差距可能继续拉大。云安全的主流化让SSRF成为基础设施漏洞的「通用入口」，而CSRF的赏金更依赖具体业务场景的风险评估。但两者都不会消失：只要服务端需要获取外部资源，就有SSRF土壤；只要浏览器自动携带Cookie，就有CSRF可能。

那位猎人的故事有个后续。他重新审计了同一程序的其他端点，三个月内提交了四份正确的SSRF报告，总赏金超过3万美元。150美元的教训，最终成了最划算的安全教育投资。

现在检查你待提交的草稿——有没有哪个「CSRF」其实该叫「SSRF」？