「前情提要」

在挖掘某EDU证书站时，我前后测了两次，两次都在预约模块发现了越权。第一次在预约新增和预约取消，开发修复后我再次测试，又在订单编辑发现同类越权。第二次的利用方式比较特别：请求里原本没有预约ID参数，手动加上之后，越权触发。

下面梳理一下两次的发现过程。

「漏洞详情」

第一次：新增 / 取消预约越权

（1）预约新增和取消两个接口，服务端没有校验目标预约单是否属于当前登录用户。只要抓包篡改请求里的预约ID，就能操作别人的预约单。

（报告太久远了，已经找不到了，所以自己模拟了一个请求，旨在简单说明当时的环境，各位见谅）

（2）正常取消自己的预约，请求如下：

POST /api/order/cancel HTTP/1.1
Host: target.com
Cookie: session=AAAA
Content-Type: application/json

{"orderId":"1001"}

（3）把orderId改成他人的订单号，比如2001：

POST /api/order/cancel HTTP/1.1
Host: target.com
Cookie: session=AAAA
Content-Type: application/json

{"orderId":"2001"}

（4）请求成功返回，用我自己的账号取消了他人的预约，服务端全程没有校验预约单归属，越权成立。

第二次：编辑订单越权

（1）复测的时候，我思路是这样的：上次是预约的增删，这次我重点盯"改"，也就是编辑预约。同一个模块，鉴权逻辑很可能有共性遗漏。再加上有时候只会按照最简单的方式修复漏洞，会忽略掉一些不经意的地方。

（2）我用自己账号编辑自己的预约，抓包看请求长什么样：发现请求体里只有地址、电话这些字段，没有预约ID。

POST /api/order/update HTTP/1.1
Host: target.com
Cookie: session=AAAA
Content-Type: application/json

{"address":"预约场馆地址","phone":"138xxxx"}

（3）这里我多想了一步。正常编辑一个预约单，服务端总得知道你要改的是哪一单吧？请求里不带ID，那服务端大概率是靠会话（Cookie/Session）隐式确定当前用户要编辑的预约单。这种方式本身没问题，但问题来了，如果服务端同时还接受客户端传进来的预约ID呢？

（4）于是我就试了一下，手动在请求体里加了一个orderId 字段，值填成别人的预约单号：

POST /api/order/update HTTP/1.1
Host: target.com
Cookie: session=AAAA
Content-Type: application/json

{"orderId":"2001","address":"攻击者修改后的地址","phone":"139xxxx"}

（5）结果真就成了，请求成功返回，用我自己的账号修改了他人预约的信息，越权坐实。

「挖掘反思」

这次在预约编辑处挖到这个越权，最大的收获是别只盯着请求里现成的参数去改。第一次挖越权时我习惯性去改已有的预约ID，但这次请求里压根没有ID，真正让我多走一步的是服务端总得知道我要改哪一单，它凭什么知道？顺着这个逻辑手动加了个ID试了试，结果真就成了。所以不要默认请求里没写的参数服务端就不处理，漏洞往往不在你看到的参数里，而在你以为不存在的参数里。