# 原理： 逻辑越权本质上来讲是设计者或者开发者在思考过程中做出的特殊假设存在明显或隐含的错误。如：如果发生A，一定出现B，因此执行C。开发者没有考虑到出现X的情形 # 防御： * 最先权限原则设置访问控制策略 * 敏感/关键接口的读写增加session鉴权 * 对交易参数进行签名校验，防止用户篡改 * 开发者尽可能多的考虑用户的反常行为和输入 # 分类： * 水平越权：攻击者执行了与自己所属角色同级别的其他用户能够执行的操作。如：注册某招聘网站成为应聘者后可以看到其他应聘者的简历 * 垂直越权：攻击者执行了额自己所属角色并不具备权限的操作。如：普通用户权限浏览到管理员才能看到的页面 # 发现： * 发现隐藏的URL：开发者在菜单栏隐藏URL，攻击者可以通过google hacking，前端源码（路由）分析，路径扫描或利用其它漏洞来发现这些URL * 关键请求参数（包括header）中的各种ID：从前端获取回来的ID直接带入业务逻辑，未校验该ID的归属，是否为当前登录用户 * 看似顺序执行的流程：很多功能的实现都需要分阶段请求，比如找回密码，购买商品等。以找回密码举例：第一步，对当前需要找回密码的账号进行认证，认证通过后到修改密码的阶段二，通过拦截修改请求数据包中的账号为受害者账号，如果开发者认为到达验证通过后的第二阶段的用户一定已经拥有了相关的权限，并在后续阶段执行操作是不再对用户提交的请求进行验证，那么此时会成功修改掉受害者账号密码。类似的还有验证码泄露，验证码认证绕过，邮箱弱token等 # 自动化思路: 正常使用两个账号，在不同的浏览器中登录，互相测试能否对另一方的数据进行越权操作。这个过程设计很多参数修改，比较复杂。但是有两个思路： * 越权遍历ID型：爬取收集带参数ID的url，设置阀值N，对ID参数遍历N次，N次错误则告警并人工处理 * 垂直越权类问题：结合自身业务特点建立不同角色访问控制模型，准备不同级别的账户登录认证Cookie，扫描器交叉请求，根据返回不满足模型的就告警输出，然后人工分析 # 越权场景： * 菜单URL越权访问：不同角色账号访问系统菜单URL不一样，互相访问未做限制 * 订单/用户等信息遍历：未校验ID是否归属于当前认证用户，修改ID，即可水平越权 * 找回/修改密码：后续阶段未做校验用户的真实性 * 交易流程：下单阶段未校验订单数量，价格 # tip： * 看似访问被403了，但是给请求头里加一个XFF，设置值为127.0.0.1，即可访问 * 看似需要验证码登录的后台，抓包后观察参数，把POST参数verifycode2换成verifycode绕过验证码登录策略