IDOR介绍

IDOR在OWASP TOP TEN 之中排行第四，可见该技术对于安全影响非常广。IDOR轻则导致信息泄漏，重则可以提权。目前到多数文章案例只是告诉读者IDOR应该怎么做。其实IDOR更主要的是对于业务逻辑的理解。如果被认为是“点点鼠标、改改参数”就能够完成IDOR。那可能源于对于IDOR理解不够充分和深刻。

正确的理解IDOR

IDOR 是越权漏洞。越权漏洞也是会包含增删改查，但是从执行角度理解是SQL语句增删改查权限限定问题。既然是SQL语句，那可以结合SQL注入进行对比，SQL注入影响到SQL执行语法层面，越权则是影响到SQL执行业务逻辑层面。通过对比来说，SQL注入存在POP和ROP两种逻辑，越权漏洞其实也存在两种逻辑。如果对于POP逻辑叫做“改改参数”，ROP逻辑不妨称为组合越权。

IDOR 组合越权案例

对于常见的越权逻辑，网上的文章非常多，并且有很棒的赏金吸引眼球。那么不常见的组合越权，应该怎么挖掘和寻找？一起来看案例。

先来看下登录功能，该功能将用户名和密码发送至后端校验。功能分为第一步将用户名查询到对应ID，第二步将密码使用RSA加密，第三步输入验证码，第四步将ID、验证码、密码密文发送至后端，第五步后端返回用户信息的JSON。

通过正常逻辑来看登录功能没有问题，但是登录之后继续看。（登录密码哪里获得，通过用户提供、社工等等）

由于平台是核算销售业绩，所以会有销售业绩排名功能。通过排名的信息泄漏获得用户名对应ID。

通过查询销售所属机构，能够查询到当前用户的密文密码。当替换用户ID时候，能够获得其他用户密码密文。

这样最终导致任意用户登录漏洞。

漏洞逻辑是：

登录用户 -> 排行榜获得用户ID -> 替换用户ID查询所属机构获得用户密码密文 -> 返回登录界面 -> 使用ID和密码密文 -> 任意用户登录

IDOR 提权案例

提权经常存在于用户权限查询模块，一些老平台之中低权限用户也会存在查询当前权限的功能。这种功能往往还和修改密码在一起。（可能是研发图省事了）

这时候如果在参数之中发现存在权限的数字或者ID令牌，则建议尝试修改。

很多时候能够触发提权漏洞，由于平台逻辑，可能是根据权限令牌判断业务逻辑，当用户将令牌修改，则触发另外一段的逻辑代码。另外一段逻辑代码，属于高权限用户，这样就产生提权漏洞。

总结

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