Web业务安全测试学习：越权访问安全案例
本帖最后由 悠悠小仙仙 于 2019-4-10 16:12 编辑平行越权攻击者请求操作（增、删、查、改）某条数据时，Web 应用程序没有判断该数据的所属人，或者在判断数据所属人时直接从用户提交的表单参数中获取（如用户ID），导致攻击者可以自行修改参数（用户ID），操作不属于自己的数据
案例1：某高校教务系统用户可越权查看其他用户个人信息
[*](1) 以 "高某某" 学号为12Sxxxx0031为例，登录教务系统，并查看该账号的学籍信息。
[*](2) 访问学号为 12Sxxx0032 的学生的学籍信息
[*](3) 访问学号为 12Sxxx0033 的学生的学籍信息
案例2：某电商网站用户可越权查看或修改其他用户信息
[*](1) 注册账号并登录，当前用户名为 april，UserID 为 460，添加收货地址并查看 "我的地址簿"
[*](2) 使用 BurpSuite 抓包，修改 cookie 中的 UserID 为360，提交后服务器返回地址信息
[*](3) 在前台下单并提交后，单击查看 "我的订单"
[*](4) 同时使用 BurpSuite 抓包，修改cookie中的UserID 改为 360，提交后服务器返回的订单信息
案例3：某手机APP普通用户可越权查看其他用户个人信息
[*](1) 注册用户并登录后点击"系统设置->个人信息" 处查看个人信息
[*](2) 使用 BurpSuite 抓包并修改 studentId 为188750，提交后服务器返回其他用户信息
[*](3) 修改 studentId 为 138850，提交后服务器返回其他用户信息
纵向越权案例1：某办公系统普通用户权限越权提升为系统权限
[*](1) 使用普通权限账号 a02 登录办公系统，尝试修改权限。由于普通用户无法访问修改权限模块，系统会跳转到 NoPower 页面提示用户无操作权限
[*](2) 使用 BurpSuite 修改 Cookie 中的 Tname 参数为 admin，欺骗服务器该请求为系统管理员发出的，成功提升账号 a02 为系统管理员权限
[*](3) 再次访问权限修改 modifyuser 页面 ，可成功访问
案例2：某中学网站后台可越权添加管理账号
[*](1) 访问登录页面，尝试登录，由于不知道账号密码，所以登录失败。
可直接打开添加用户页面，添加账号 test，密码为123456，添加完用户返回首页登录
[*](2) 登录成功后，提示没有分配管理权限，然后会强制退出管理系统。但此时会生成一个 Cookie
[*](3) 使用该 Cookie ，可直接打开分配权限的页面。其中 test 用户不能修改自己的权限，但可以修改其他用户的权限。再添加一个新用户 test2，两者可以互相添加权限
[*](4) 使用 test 账号修改test2账号的权限为管理员权限
[*](5) 使用 test2 账号重新登录，成功进入管理后台
案例3：某智能机顶盒低权限用户可越权修改超级管理员配置信息
[*](1) 使用超级管理员登录，配置 user 密码。智能机顶盒设备的超级管理员的账号和密码为chinanet/123456，登录后查看该机顶盒的设备信息。使用超级管理员登录后，在 "管理" 模块下的 "用户管理" 中配置 user 用户的密码
[*](2) 使用超级管理员配置 proxy 代理地址，通过超级管理员在 "应用" 模块下的 "proxy代理" 中配置，使用抓包工具抓取提交的链接和参数
[*](3) 退出超级管理员，清除浏览器的 Cookie 信息，使用 user 账号登录。与超级管理员相比，user 用户在 "应用" 模块中只有简单的 "日常应用" 一项权限，并没有其他的权限
[*](4) 利用 user 用户的权限来配置以前没有权限配置的 proxy 代理，直接使用hackbar 工具通过 POST 方式提交数据。通过抓取的数据包可以看出，使用的是 user 用户权限进行提交的。
[*](5) 再次使用超级管理员chinanet 账户登录，单击进入 "proxy代理" 的配置，此时内容已发生改变了。
PS：其实这个案例说白了也就是使用普通账号的cookie去成功调用了本该只属于超级管理员的接口。
案例4：某Web防火墙通过修改用户对应菜单类别可提升权限
[*](1) 以 audit 用户身份登录系统，使用 BurpSuite 抓包 category 的值 system.audit 修改为 system.admin
[*](2) category 的值修改后，单击 Forward，进入管理员管理界面。
[*](3) 将 audit 账号的权限设置为最大
[*](4) 再使用 audit 账号登录系统，audit 账号拥有管理员权限。
防范越权访问漏洞的相关手段实现应用程序的完善的访问控制不是件容易的事，越权漏洞防不胜防。
[*](1) 执行关键操作前必须验证用户身份，多阶段功能的每一步都要验证用户身份
[*](2) 对于直接对象引用，加密资源ID，以防止攻击者对ID进行枚举
[*](3) 在前端实现的验证并不可靠，前端可以验证用户的输入是否合规，要在服务端对请求的数据和当前用户身份做校验。检查提交 CRUD 请求的操作者（Session）与目标对象的权限所有者（查数据库）是否一致，如果不一致则阻断
[*](4) 在调用功能之前，验证当前用户身份是否有权限调用相关功能（推荐使用过滤器，进行统一权限验证）
[*](5) 把属主、权限、对象、操作的场景抽象成一个统一的框架，在框架内统一实现权限的管理和检查。
支持
页:
[1]
