帮助我们了解您发现的漏洞

上周三凌晨两点，帮助我收到一条短信：“你那个登录接口，发现手机号后四位能直接改成别人的漏洞。”发信人是帮助位独立开发者，他没用任何扫描器，发现只是漏洞手动试了十几次请求。这种漏洞报告比自动化工具生成的帮助千篇一律的表格有价值得多——它带着具体路径、复现步骤，发现甚至附上了他抓包时截的漏洞图，图里时间戳和请求头都清晰可见。帮助

很多人以为报漏洞就是发现截个图丢过来。真不是漏洞。我见过最离谱的帮助一份报告写着“你们网站有安全问题”，然后没了。发现连哪个域名、漏洞哪个参数、怎么触发的都不说。这种报告除了让人焦虑，毫无用处。反过来，上周那个手机号篡改的问题，我拿到后十五分钟就定位到了代码——因为对方写了：“用A账号登录，抓包把`user_id`从123换成124，再请求`/api/getProfile`，就能看到B用户的手机号。”你看，路径、参数、预期结果，全齐了。

那什么样的漏洞报告算合格？先别管格式。你只需要回答三个问题：在哪、怎么碰、碰完会怎样。比如“在`https://example.com/search?q=`这个接口，把`q`参数换成``，页面会弹窗”。这就够了。别写“可能存在XSS风险”——“可能”两个字会让修复的人多花半小时去猜。

我碰到过一位安全研究员，他报了个越权查看订单的漏洞。报告里附了一段curl命令，还特意注明“需要先登录普通账号，拿到token后替换URL里的订单ID”。更细的是，他试了三个不同ID，发现只有尾号为奇数的订单能越权访问。这个细节帮我们缩小了排查范围——最后发现是缓存键生成逻辑写错了，只对奇数ID做了错误的分片。如果他只写“能越权”，我们得翻遍整个订单服务。

有些报告喜欢用“高危”“严重”这种词。说实话，等级我自己会判断。你不如告诉我：这个漏洞能不能直接拿到数据库权限？需不需要用户交互？影响一个用户还是全部用户？上周有个报告说“可导致信息泄露”，我一看，只是用户名枚举——攻击者能判断某个邮箱是否注册过。这算低危，但报告里没写清楚，我差点按中危处理。后来对方补了一句：“只能区分注册与否，拿不到密码或手机号。”这就明确了。

截图很重要，但别只截结果。把请求包和响应包都截上，Burp Suite的界面最好带上时间戳和Host头。有人只截一个弹窗，我问“怎么触发的”，他说“忘了”。那只能重新试。还有，别用手机拍屏幕——模糊得看不清参数名。直接截图，或者贴文本。文本比图片更好，我能直接复制去复现。

如果你不确定某个行为算不算漏洞，先别报。自己想想：这个操作会不会让我看到不该看的数据？会不会让我以别人的身份做事？会不会让服务器崩溃？如果答案是“好像会”，那就再试一次，把步骤记下来。我见过有人把“退出登录后按后退键还能看到页面”当成漏洞报上来——那只是浏览器缓存，不是服务端问题。浪费彼此时间。

最后说个真事。有位白帽子发现我们某个API在传入超长参数时会返回500错误，他没直接报“拒绝服务漏洞”，而是写：“传10万个字符返回500，传1万个正常。怀疑是数据库字段长度没校验，建议加个长度限制。”我们改了之后，他又试了一次，确认返回400而不是500，才关闭了报告。这种报告，我恨不得给他发奖金。

所以，别想太多。把你看到的、试过的、得到的，按顺序写清楚。不用华丽辞藻，不用风险评估模板。就像告诉朋友“你家门锁用张卡片就能捅开”一样——直接、具体、可验证。剩下的，交给我们。