web网站漏洞如何查出id

```html

一个订单页面，站漏URL是洞何 /order/detail?order_id=1057。你把 1057 改成 1058，查出回车，站漏页面刷出了别人的洞何收货地址和手机号。这就是查出最原始的越权漏洞——它不靠猜密码，不靠注入，站漏单纯因为后端没校验“这个订单是洞何不是你的”。查出这种 ID 漏洞，查出核心就一件事：观察参数、站漏替换参数、洞何对比响应。查出

我做渗透测试这些年，站漏发现很多人把“查 ID”想复杂了。洞何他们上来就掏 sqlmap、查出Burp 扫全站，结果漏掉了最笨也最有效的方法：手动改数字。去年帮一个电商做复测，我打开他们的优惠券领取接口 /api/coupon/receive?coupon_id=88，把 88 改成 89，返回包里直接多了一张满 200 减 150 的券。整个过程不到十秒。这种漏洞不需要工具，需要的是耐心和“手贱”的习惯。

怎么系统性地找出这些 ID？先看 URL 路径。RESTful 风格下，/user/1024/profile 和 /user/1025/profile 就是典型。把 1024 换成 1025，如果返回了另一个用户的邮箱、昵称，那漏洞坐实。再看查询字符串，?id=、?uid=、?order_id= 这些参数名本身就是信号。别只盯着数字，试试 base64 编码后的值。比如 ?ref=eyJ1aWQiOjEwMjR9，解码是 { "uid":1024}，改掉再编码回去，一样能越权。

POST 请求里的 ID 更容易被忽略。很多前端把用户 ID 藏在 JSON body 里，像 { "userId": 1024, "action": "delete"}。你抓包改成 1025，如果后端只信任 body 里的值，就能删别人的数据。我见过一个后台管理系统，删除文章时传 { "articleId": 500}，没有 CSRF token，也没有权限校验。用 Burp 的 Intruder 跑一遍 1 到 1000，直接删了整站文章。这不是技术多高明，是开发偷懒。

还有一种隐蔽的 ID：它们不在请求里，而在响应里。比如你登录后，服务器返回 { "user_id": 1024, "role": "user"}。你把这个 user_id 记下来，然后去访问 /admin/user/1024/edit，如果页面正常打开，说明水平越权。更狠的是，有些系统用 role 字段做前端隐藏，你把 user 改成 admin，刷新页面，管理菜单就出来了。这种漏洞查起来靠的是“看响应、猜接口”。

工具能帮上忙，但别依赖。Burp Suite 的 Repeater 适合手动改 ID 看响应差异。Autorize 插件可以自动对比不同权限下的响应长度，帮你快速定位越权点。但工具不知道你的业务逻辑——它不知道 /export?file_id=1 导出的是一份工资表。只有人知道。所以我的习惯是：先用浏览器正常操作一遍，把每个请求的 ID 参数记在记事本上，然后逐个替换。替换时注意看 HTTP 状态码：200 不一定成功，302 跳转到登录页反而可能是漏洞被拦截了。最可靠的是对比响应内容——长度、关键字、JSON 字段。

说个真实案例。某政务网站有个 /document/download?doc_id= 接口。我改成相邻 ID，下载了一份“内部人员名单.xlsx”。里面包含姓名、身份证号、职务。这个漏洞怎么查出来的？就是手动把 doc_id 从 1001 改成 1002。没有扫描器报警，没有 WAF 拦截。后来我问开发，他说“以为前端不显示链接就安全了”。这种“以为”就是 ID 漏洞的温床。

最后提一个容易漏的点：Cookie 和 Header 里的 ID。有些系统把用户 ID 放在 X-User-Id 头里，或者 Cookie 里的 uid=1024。你改掉这些值，如果后端还认，就是漏洞。我见过一个 API 网关，只校验了 URL 里的 token，没校验 Header 里的 X-User-Id。结果攻击者可以伪造任意用户身份。查这种 ID，需要你把整个请求包翻一遍，别只看 URL。

总结一下实际操作顺序：打开 Burp 代理，浏览目标网站，把所有带数字、带编码、带用户标识的请求丢进 Repeater。然后，对每个 ID 参数做三件事——加一、减一、改成其他用户的已知 ID。看响应。如果返回了不该看的数据，漏洞就在那里。别想太复杂，ID 漏洞往往就藏在最显眼的地方。