pprof调试信息泄露漏洞

去年年底，调洞某金融科技公司的试信运维团队在巡检时发现，一台对外服务的息泄Go语言网关机内存占用异常。登进去一查，露漏/debug/pprof/ 路径赫然暴露在公网，调洞任何人都能直接访问。试信更麻烦的息泄是，这个接口不仅没加认证，露漏连IP白名单都没配。调洞攻击者只要跑一条 go tool pprof 命令，试信就能把堆内存里的息泄用户Token、数据库连接串、露漏甚至加密密钥全拉下来。调洞

这不是试信孤例。pprof是息泄Go官方提供的性能分析工具，默认挂载在 net/http/pprof 包下，只要引入这个包并启动HTTP服务，/debug/pprof/ 及其子路径就会自动注册。很多开发者图省事，线上环境也保留着这套调试接口。问题在于，pprof暴露的信息远超“性能数据”范畴。

拿 /debug/pprof/heap 来说，它返回的是堆内存的采样快照。如果程序里存了明文密码、会话ID、API密钥，这些字符串会直接出现在profile文件里。用 go tool pprof -http=:8080 加载后，甚至能在源码视图中看到变量值。另一个接口 /debug/pprof/goroutine?debug=2 会打印所有goroutine的调用栈，如果栈帧里包含请求参数，同样会泄露。还有 /debug/pprof/cmdline，直接返回进程启动命令，里面可能带着数据库密码或密钥文件路径。

我见过一个真实案例。某电商后台的pprof没关，攻击者通过 /debug/pprof/trace?seconds=10 抓了10秒的执行追踪，从trace里还原出了订单查询的SQL语句和用户ID。接着用这些信息构造了越权请求，把别人的订单详情全拉了出来。整个过程中，攻击者没碰任何业务接口，只靠调试端口就完成了信息收集。

为什么这个问题反复出现？一是Go的默认行为太“贴心”，引入包就自动注册，很多人根本不知道。二是运维和开发脱节，开发在本地调试时开着pprof，上线时忘了关。三是有些团队觉得内网就安全，但内网横向移动的成本远比想象中低。我甚至见过K8s集群里，一个Pod的pprof端口被Service暴露到集群外，只因为Service的targetPort写错了。

怎么防？最直接的办法是别在线上引入 net/http/pprof。如果确实需要性能分析，可以自己写一个独立的HTTP服务，绑定在127.0.0.1或单独的运维端口，加上认证和IP白名单。另一个做法是用构建标签，比如 //go:build pprof，只在特定构建版本里启用。还有团队用反向代理拦掉 /debug/pprof/ 路径，返回404。但要注意，如果代理配置了路径重写，可能绕过拦截。

检查方法很简单。跑一条 curl -s http://target/debug/pprof/，如果返回HTML页面，说明接口开着。再试试 /debug/pprof/goroutine?debug=1，能看到goroutine数量就确认暴露了。修复后记得验证：curl -I 应该返回404或403。别只改代码不重启，有些框架会缓存路由。

pprof本身是好东西，性能调优离不开它。但把它当成“默认开启的调试后门”，就是给自己挖坑。线上环境的安全边界，往往就断在这些不起眼的默认配置上。