Using an Access Control Matrix
摘要
本课程就是感受 RBAC 系统的权限控制矩阵。
错误实现的 RBAC 系统，某些角色(以及与该角色关联的用户)会拥有它不该拥有的权限。
RBAC 简介
RBAC（Role Based Access Control）模型，基于角色的访问控制模型有三个原则：最小权限原则、责任分离原则和数据抽象原则。
关于水平权限和垂直权限
基于角色的访问控制按角色权限高低可分为两类：垂直权限控制和水平权限控制。
垂直权限控制作用在两类不同权限的角色之间，例如A是普通用户，B是管理员用户，那么B就拥有更多的可访问资源，这些资源包括某个URL下的资源、系统中的某个接口调用等。对于垂直权限控制，各编程平台都会有一些框架可以利用，因为垂直权限控制易于抽象，与具体业务耦合较少。Java Web开发程序员可以利用Spring Security，通过一些配置即可完成系统中的垂直权限控制需求(可基于URL和基于Method)。
水平权限控制是作用与相同的角色之间的。例如A、B都是社交网站的用户，他们对该网站上的资源拥有同样的权限，但是各自又都有一些私有数据，类似私信列表、好友列表。因为构造一个获取其他用户私有页面的URL(REST风格，很好构造)是很简单的，所以A用户可能只要改下URL中的ID等信息就能得到B用户的URL，这个环节不做权限控制显然不合理，而这里又很容易被疏忽掉。试想动辄上百个接口或URL，对每个都要做这样的水平权限判断，漏掉任何一个都会造成潜在漏洞。此外，这类漏洞自动化工具还不好扫描，不易察觉。因为水平权限控制判断的依据已经是数据级别的，所以一般框架较难处理这类情况，程序架构好点的可以通过拦截器对同类接口参数进行过滤和判断。否则，也只能具体接口具体判断了。我现在只做过 Flask Web 开发，在用户权限管理这块主要是使用 Flask-Login ，垂直权限的管理只要用 @login_required 装饰器就行了，或者再添加一些自定义的权限检测装饰器。关于水平权限的隔离，暂时的思路，每个用户私信的REST url中再增加不同token来分离。
token的构造可以是 md5(用户名+uid)。
不过这样也侧面说明水平越权可能会更容易挖掘，另外我也很好奇例如QQ空间和微信朋友圈的权限控制系统会如何设计。
(对表中每一条记录，关联一个whitelist或者blacklist)
Bypass a Path Based Access Control Scheme
摘要
基于路径的访问控制可能会因为相对路径而绕过。
实验步骤
拦截HTTP请求，以相对路径方式修改请求资源。
修改File参数为以下参数
|
|
自动化检测的可行性
感觉较难，难点在于应该读什么文件，不同的开发方式服务器目录组织不同。
Role Based Access Control
摘要
这个之所以能够进行越权操作的根本原因在于，网站把用户权限的校验放在了前台，用户一旦登陆进去之后的操作，就没有再进行验证了。导致用户可以越权操作。
实验步骤
这一步要求我们绕过业务层访问控制。它给出了很多人的用户名和密码，可以用他们的用户名和密码登陆系统，但是每个人在该系统中的权限不一样，因此能够进行的操作也不一样。其中HR是能够删除任意员工的简介的，首先用HR的账号登陆之后，删除一个员工的简介，用burpsuit抓取提交的post参数
然后登陆一个普通用户的账户，他只有查看和搜索用户的权限，在其查看用户的时候，截取其提交数据查看。
修改提交的参数的值，将“ViewProfile”改为“DeleteProfile”，执行成功
自动化检测的可行性
感觉比较难，暂时没有很好的思路。主要是操作的名称难以确定。
Remote Admin Access
摘要
远程原理员访问。应用程序通常会有一个管理界面，这个界面一般用户无法访问到，只有具有特权的用户才能访问。很多网站开发人员在脚本中预留了相关的参数接口，一旦该参数被后台程序确认，则访问者的权限会被放大，浏览到先前不能访问的资源，如：程序调试日志、隐藏功能菜单等。在URL里面加上一个参数admin=true，例如
|
|
这就是URL里面隐藏参数的识别。此时，在左侧栏的“Admin Function”，子功能下增加了另三个功能
自动化检测的可行性
虽然这个漏洞感觉很low,但自动化检测时不妨一试。
admin=True 之类要建立一个字典来fuzzing
对比有参数和无参数的服务器响应结果是否相同即可。
更粗暴的方法可以直接比较返回长度。
