fanf安全漏洞全程视频

2023年11月，安全某头部电商平台的漏洞后台运维人员发现fanp安全网关的日志里出现了一段异常的十六进制流量。这段流量绕过了WAF的全程常规规则，直接触达了订单数据库的视频只读副本。三天后，安全攻击者用同样的漏洞路径拖走了270万条用户收货信息。整个过程被内部流量镜像完整记录，全程后来流出的视频视频就是从这个镜像里截取的。

视频开头很枯燥。安全黑底白字的漏洞终端窗口，光标闪了十几秒。全程然后是视频一串curl命令，目标IP指向fanp的安全API网关。操作者没有用任何扫描器，漏洞手动构造了HTTP/2的全程伪头字段，把:path设成了/api/v1/order/export?format=json&limit=50000。正常请求会被网关的鉴权中间件拦截，但视频里这个请求的Authorization头是空的。

关键点在这里。fanp网关的鉴权逻辑有个默认放行规则：当请求头里包含X-Internal-Call: true时，中间件直接跳过token校验。这个头本来是给内部服务间调用用的，但网关没有校验来源IP。攻击者显然知道这一点。视频里能看到他先发了一个OPTIONS请求探测，响应头里Access-Control-Allow-Origin居然是*，还允许了X-Internal-Call这个自定义头。跨域配置和内部调用鉴权这两层防线，同时失效了。

接下来更离谱。订单导出接口本身有速率限制，每分钟最多3次。但视频里攻击者把请求分散到了12个不同的边缘节点IP上，每个节点只发一次。fanp的限流是单节点计数，没有全局聚合。这12个请求几乎同时到达，每个都返回了200，每个都带回了5000条记录。六万条数据就这么出去了。操作者甚至没写自动化脚本，就是手动改了curl的--resolve参数，把同一个域名解析到不同边缘IP。

视频第4分22秒，攻击者开始处理返回的JSON。他用jq过滤出手机号和地址字段，直接管道给了一个Python脚本做去重。脚本里有一行注释写着“fanp_gateway_bypass_2023”。这个命名习惯后来成了溯源的关键线索——同一时期还有两个金融和物流平台被同样的手法打穿，日志里都出现了这个字符串。

我反复看了三遍这段视频。最让人后背发凉的不是漏洞本身，而是攻击者的节奏。他每发一个请求，都会等2到3秒，看一眼响应码，再发下一个。这种耐心说明他对fanp的架构非常熟悉，知道哪些节点有缓存、哪些没有。视频里有个细节：第7分钟他停了一会儿，终端里敲了个dig +short api.fanp-edge.com，返回了16个IP。他挑了其中12个，跳过了带“sh”和“bj”前缀的节点。后来证实那两个节点部署了新版鉴权模块，但只覆盖了30%的流量。

漏洞的修复过程也录在了视频后半段。运维团队先是在网关层加了一个硬编码的IP白名单，只允许10.0.0.0/8的地址带X-Internal-Call头。但攻击者换了个手法，用X-Forwarded-For: 10.1.2.3伪造内网来源，又绕过去了。第二次修复才改掉鉴权中间件的逻辑，把“检查头存在”改成“检查头存在且来源IP在VPC内”。这中间隔了将近6个小时，视频里能看到攻击者在这段时间又拖了两次数据，只是量小了很多。

最后说一个视频里没拍到的细节。fanp的API网关文档里，X-Internal-Call这个头压根没出现在公开文档中。它只存在于内部Confluence的一个“服务间通信规范”页面里，访问权限是“研发全员可见”。这意味着攻击者要么有内部文档的访问权，要么就是从某个离职员工的GitHub仓库里翻到了配置模板。视频结尾，操作者关掉终端前，屏幕上闪过一行history | grep fanp，返回了47条记录。他笑了笑，敲了history -c。

这段视频后来被传到某安全论坛的“漏洞披露”板块，标题就叫“fanp安全漏洞全程视频”。帖子存活了19分钟就被删除，但下载量已经过了两千。我拿到的是别人转存的版本，文件哈希对得上。现在fanp的网关已经改了三版，那个X-Internal-Call头彻底废弃了。可每次看到有人用curl手动测接口，我还是会想起视频里那个光标闪烁的十几秒——那是一个系统最安静、也最危险的时刻。