写在前面
一些概念会直接引用，主要是对于靶场和关键知识点会进行讲解。
资料引用
访问控制概念
简单的来说就是应用程序首先会判断用户的身份（账号密码登录），随后确认后续请求是否由该用户发出（会话管理），然后判断是否允许用户执行“所请求的操作”或访问“所请求的资源（访问控制）”
1、从用户角度访问控制模型分为以下类型：
垂直访问控制：控制不同权限等级的用户访问应用程序不同的功能；如“管理员”可以修改/删除账号，而普通账号无法操作。
水平访问控制：控制用户只能访问自己的资源，而不能访问其他用户相同类型的资源；如“银行程序用户只能从自己的账号进行付款，而不能查看其他用户的账户”。
上下文相关的访问控制（多步骤）：与上下文相关的访问控制根据应用程序的状态或用户与应用程序的交互来限制对功能和资源的访问。
与上下文相关的访问控制可防止用户以错误的顺序执行操作。例如，零售网站可能会阻止用户在付款后修改其购物车的内容。
2、出现访问控制漏洞的原因：
理论上应用程序需要对每一个请求，以及特定用在特定时刻的每一项操作，都需要进行访问控制检查，但是由于该策略是人为设定，所以常常出现安全问题。
当用户实际上可以访问某些资源或执行某些他们不应该能够访问的操作时，就会存在损坏的访问控制漏洞。
如果用户可以访问他们不被允许访问的功能，那么这就是垂直权限提升。例如，如果非管理员用户实际上可以访问管理页面，他们可以在其中删除用户帐户，那么这就是垂直权限升级。
Unprotected admin functionality
robots数据泄露
进入管理界面，就是垂直越权
Unprotected admin functionality with unpredictable URL
源码泄露敏感连接，垂直越权成功。
User role controlled by request parameter
不安全cookie带来的权限问题
改一下cookie查看到敏感链接。接下来带cookie访问管理员功能
最后带cookie删除即可
User role can be modified in user profile
找到敏感post请求
这是因为对于一个用户是单独进行更新的，并不是邮件单独更新的，在传递邮件信息时势必要带上当前用户的id之类的东西（只是省略了，可能在session中），这样才能定位更新。 更新后返回json来重置当前页面信息。这就是在返回时带出了过多信息。
我们就可以多提交一点更新内容。
进入302的跳转位置，跟随进去就可以了。
URL-based access control can be circumvented
从这里就比较有意思了，本题的环境是，直接基于url进行限制访问，比如直接禁止任何外网访问指定url，仅规定内网能够访问。
或者比如限制对敏感url进行请求。
此时相对来说是非常严格的检查。
但是有些应用会支持非标准的请求头，比如：允许”X-Original-URLorX-Rewrite-URL“覆盖目标url值。这种方式适合于权限控制是基于请求链接限制的情况，比如：应用程序的后台地址”/console“或者"/admin"禁止通过互联网访问。但是探测到请求头支持”X-Original-URLorX-Rewrite-URL“，可以使用以下方式绕过该限制。
这里可以看到，它有解析X-Original-URL这个头部字段，我本来请求的是首页的一个普通界面。
接下来一路跟下去，不过这里有一个小问题，这个字段只能重写请求的url，它无法携带请求参数。
所以你需要在真正请求上带上请求参数。
就像下面这样。
更改参数时，建议在inspector中完成
Method-based access control can be circumvented
在前面一个问题，它是使用黑名单进行限制，比如禁止对 /admin/secrect 发起post请求，就是从url和请求方法进行限制。
首先使用管理员权限登录administrator，能够成功执行管理员功能。
接下来启用无痕模式
使用常规用户登录
使用常规用户的cookie执行管理员操作，对敏感链接进行请求，当然这里显示的是权限不足。关键就在这里，作为普通用户，不能够对权限更高的/admin-roles页面发起post请求，但是如果我使用的不是post请求呢？
在这里更换我的请求方式，探测出来是缺少参数，探测成功，可以使用其他请求方式。这里就是这个基于请求方式的绕过了。
切换为有效的GET请求，并带上参数即可
不过，这样的关键在于你能够获取到敏感操作的路径，可以结合其他方式进行攻击。