挖洞经验 | 如何发现更多的越权漏洞（2）

如果无法猜测，可以尝试创建比如，如果对象引用号（object reference IDs）无法预测

可以看看能有什么操作来影响这种ID号的创建或链接过程。

给Web应用提供一个请求ID，哪怕它没作要求

如果Web应用在请求动作中没有ID号要求，那么可以尝试给它添加一个ID号看看会发生什么。

比如添加一个随机ID号、用户ID、会话ID，或是其它的对象引用参数，观察服务端的响应内容。

如下列请求接口用于显示当前用户所属的私信会话内容：

GET /api_v1/messages

那要是把它换成这种样式，会不会显示出其它用户的会话内容？

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

使用HTTP参数污染方法（HPP,HTTP parameter pollution）

用HTTP参数污染方式针对同一参数去给它多个不同的值，这样也是可以导致IDOR漏洞的。

因为Web应用可能在设计时不会料想到用户会为某个参数提交多个不同值

因此，有时可能会导致Web后端接口的访问权限绕过。

虽然这种情况非常少见，我也从来没遇到，但从理论上来说，它是有可能实现的。如以下请求接口：

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

如果对它发起请求失败，那么我们可以尝试发起另外如下的请求：

GET /api_v1/messages?user_id=YOUR_USER_ID&user_id=ANOTHER_USERS_ID

或是这种请求：

GET /api_v1/messages?user_id=ANOTHER_USERS_ID&user_id=YOUR_USER_ID

又或是换成这种把参数列表化的请求：

GET /api_v1/messages?user_ids[]=YOUR_USER_ID&user_ids[]=ANOTHER_USERS_ID

使用盲IDOR法（Blind IDORs）

有些场景下，易受IDOR漏洞影响的接口不会直接响应出来请求查询的信息

但它们可以导致Web应用在其它方面泄露信息，如导出文件、邮件或是文本提醒等。

改变请求方法

如果某个请求方法无效，那么可以试试其它方法，如GET, POST, PUT, DELETE, PATCH…等

一个通常的技巧就是用PUT和POST进行互换，原因在于服务端的访问控制措施不够完善。

改变请求文件的类型

有时，切换请求文件的类型可能会导致Web服务端在授权处理上发生不同

如在请求URL后加上一个.json，看看响应结果如何。

如何提高IDOR漏洞的危害性

严重性IDOR优先

这里，找IDOR漏洞时首先要考虑的是其对目标网站关键业务的影响程度，所以，读写型IDOR漏洞都属于高危型IDOR漏洞。

按照状态改变型state-changing (可写型) IDOR漏洞来看，其导致的密码可重置、密码可更改或账户恢复等操作都会对目标网站关键业务造成严重影响，而那种更改邮件订阅设置的IDOR漏洞影响就较低。

而对于状态不可改变型non-state-changing（可读型）IDOR漏洞来看，我们就要去关注它其中对敏感信息的处理操作，比如，对用户私信会话的处理、对用户敏感信息的处理，或是非公开内容的处理。

考虑Web应用中哪些功能会处理这些数据，然后有目标的去查找类似IDOR漏洞。

存储型XSS（Stored-XSS）

如果把可写型IDOR和self-XSS（需要受害者交互的XSS）结合，那么就有可能形成针对某个特定用户的存储型XSS（Stored-XSS）。

它的用武之处在哪呢？

比如，如果你发现了一个可以更改另外一个用户购物车列表的IDOR漏洞，

实际来说，该IDOR漏洞危害并不高，充其量只会引起受害者的一些麻烦，但如果把它和self-XSS配合利用的话，在某个用户提交点，就能通过IDOR把XSS利用代码传递给受害者浏览器端

最后的效果是，它就形成了针对特定受害用户且无需交互的存储型XSS了！