0x01、越权漏洞
越权（或者说权限提升，Privilege Escalation）是指攻击者能够执行他本身没有资格执行的一些操作，属于“访问控制”的问题。越权也就是“超越了我们所拥有的权限，干了我们本来不可能干的事儿”。越权漏洞是Web应用程序中一种常见的安全漏洞。
0x02、web网站常见的访问控制
常见的访问控制方式有三种：垂直访问控制、水平访问控制和上下文相关的访问控制。
垂直访问控制
允许不同类型的用户（常见的有基于角色划分用户类型）访问应用程序的不同功能，例如在某系统中普通用户只能执行有限的操作，管理员则拥有最高权限。
水平访问控制
允许用户访问一组相同类型的资源，如在一个网银系统中，每个用户只能看到他自己的账户信息，只能操作自己的账户进行转账。
上下文相关的访问控制
确保基于应用程序当前的状态，限制用户仅能访问所允许的内容，如在常见的找回/修改密码功能中，必须通过身份验证才能重新设置密码。许多情况下，垂直访问控制与水平访问控制会相交交叠，配合使用。
0x03、越权的分类
垂直越权
如果攻击者能够执行某项功能，而他所对应的角色并不具备该权限，这就存在垂直越权漏洞，例如普通用户可以执行管理员的操作
水平越权
攻击者能够执行与自己同级别的其他用户能够执行的操作，这就存在水平越权漏洞，例如网银系统我们可以看到别人账户余额
上下文相关的越权
攻击者能够利用应用程序状态机中的漏洞获得关键资源的访问权限，这就存在上下文相关的越权。如在找回密码过程中，攻击者使用自己的账户信息通过验证，但最终却通过某种手段（例如使用BurpSuite改数据包）将他人的密码进行了修改。上下文相关的越权漏洞一般属于业务逻辑漏洞。
0x04、越权漏洞的产生
web应用程序提供的功能时，流程是：登录—>提交请求—>验证权限—>数据库查询—>返回结果。如果在“验证权限”环节存在缺陷，那么便会导致越权。
一种常见的存在越权的情形是：Web应用程序的开发者安全意识不足，认为通过登录即可验证用户的身份，而对用户登录之后的操作不做进一步的权限验证，进而导致越权问题。
1、通过隐藏url实现访问控制
有些应用程序仅通过URL实现访问控制。例如：使用管理员身份登录后可以看到后台管理页面的链接，但是以普通用户登录则看不到该链接。在这种情况下，开发者认为普通用户不知道或者很难猜到后台管理页面的URL，因此实现对管理功能的保护。这其实是一种错误观点，因为攻击者完全有可能通过其他方式（如Google Hacking、HTML/js源码分析、暴力猜解URL、利用其他漏洞等）得到后台管理URL。
2、直接对象引用
用户提交HTTP请求访问某资源时，被请求资源的标识符常常以GET或者POST请求参数的形式出现在URL查询字符串或者POST请求主体中提交给服务器。例如，在一个网银系统中，用户可以使用以下URL查询账户信息：
https://www.onlinebank.com/viewInfo.php?accountId=12345678
其中accountId是用户自己的账户ID。用户登录自己的账户后，该URL的链接会出现在用户账户页面中，用户点击即可跳转到账户信息页面。虽然其他用户无法看到这个链接，但是如果该网银系统的访问控制不完善，攻击者完全可以通过枚举accountId进而构造出URL，然后越权查看他人的账户信息。
3、多阶段功能
应用程序的一些功能通过几个阶段执行，并且在执行过程中向服务器依次提交多个请求。这种情况很常见，比如转账功能、找回密码功能等，需要先验证用户的身份，验证通过后才允许用户执行后续动作。多阶段功能本身并没有问题，但是如果开发者认为到达验证过程后续阶段的用户一定已经拥有了相关的权限，并在后续阶段执行操作时不再对用户提交的请求进行验证，那么就很有可能存在越权漏洞。攻击者完全有可能绕过前几阶段的验证阶段，直接执行后续的动作。
4、静态文件
有些Web应用程序在用户访问动态页面时会执行相应的访问控制检查，以确定用户是否拥有执行相关操作所需的权限。但是，用户仍然会提交对静态资源的访问请求，如下载网站中的word、excel、pdf文档等。这些文档都是完全静态的资源，其内容直接由Web服务器返回，它并不在服务器上运行。因此，静态资源自身并不能执行任何检查以确认用户的访问权限。如果这些静态资源没有得到有效的保护，那么任何知晓URL命名规则的人都可以越权访问这些静态资源。这种情况的越权也很常见，而且即使不知道URL命名规则，完全有可能通过Google hacking搜索到敏感文件。
5、平台配置错误
一些应用程序通过在Web服务器或应用程序平台层使用控件来控制对特定URL路径的访问。例如，有些应用程序会根据用户角色来限制对管理后台路径（如/admin）的访问，如果用户不属于“管理员”组，则拒绝其访问后台管理页面的请求。但是，如果在配置平台及控件时出现错误，就可能导致越权访问。
0x05、越权漏洞的挖掘
1、HTTP请求上来说，通过BurpSuite抓取在目标站点正常操作所产生的请求数据包，然后找出可能产生越权的请求。一般情况下，类似上文所述URL的GET或者POST请求都要列为重点怀疑对象：
https://www.onlinebank.com/viewInfo.php?accountId=12345678
2、从业务功能上来说，找到容易产生越权的功能点。常见的越权高发功能点有：根据订单号查订单、根据用户ID查看帐户信息、修改/找回密码等。
确定了怀疑对象之后，还需要进一步的分析，以确定是否真的存在越权。这时，需要两个不同的账号（下文分别称为账号A和账号B），以便测试登录账号A后进行操作能否影响到账号B。注意在浏览器中测试时，需要使用两个浏览器分别登录不同的账号，或者使用浏览器的隐私浏览功能登录其中一个账号。
以上文提到的URL为例进行说明。假设账号A的id为1234，账号B的id为5678，BurpSuite中抓取的数据包都是在账号A的。通常测试是：在BurpSuite中将该请求发送到Repeater，然后将参数id的值修改为5678，最后提交修改后的请求包；服务器返回响应后，可以看一下BurpSuite中收到的响应报文。如果响应报文直接提示错误之类的，基本上可以确定此处不存在越权；如果响应报文提示操作成功，此时应该使用浏览器登录账号B进行二次确认，如果数据确实有相应的改动，那么则说明这里存在越权漏洞。这里需要注意：BurpSuite中报文提示操作成功有可能是误报，必须在浏览器中进行再次确认。而对于查询订单这类的请求来说，情况更简单了，修改参数id提交请求，如果返回了账号B的数据，那么就可以确定存在越权。
当然，越权漏洞的攻击点不仅仅存在于请求参数中，还有可能在Cookie中。因此，需要具体情况具体分析，复杂一点的可能还需要Cookie值配合请求参数值以实现越权攻击。
0x06、越权漏洞的防范
1、永远不要相信来自客户端（用户）的输入！
2、执行关键操作前必须验证用户身份，多阶段功能的每一步都要验证用户身份。
3、对于直接对象引用，加密资源ID，以防止攻击者对ID进行枚举。
4、在前端实现的验证并不可靠，前端可以验证用户的输入是否合规，在服务器端验证用户权限。
参考链接：http://www.2cto.com/article/201311/255079.html
http://bobao.360.cn/learning/detail/3169.html
http://www.freebuf.com/vuls/112339.html