目录
一、前言：
二、介绍：
三、原理：
四、产生原因：
4.1、代码逻辑（前端）问题
4.2、数据库（后端）问题
五、危害：
六、漏洞出现：
七、利用过程：
7.1、pikachu（Over Permission-水平越权）
7.1.1、第一步：日常分析参数
7.1.2、第二步：日常修改参数
7.1.3、第三步：查看返回的信息
7.2、pikachu（Over Permission-垂直越权）
7.2.1、第一步：分析高权限用户操作功能
7.2.2、 第二步：获取操作的URL
7.2.3、第三步：实现越权添加用户
（青春是用来奋斗的）
一、前言：
越权访问（Broken Access Control，简称BAC）是Web应用程序中一种常见的漏洞，由于其存在范围广、危害大，被OWASP列为Web应用十大安全隐患的第二名。
二、介绍：
水平越权和垂直越权（常见的漏洞类型），在开发时候权限划分和控制上存在逻辑上的缺陷导致（逻辑安全漏洞）
顾名思义，攻击者利用逻辑安全漏洞进行越权，去执行超出了权限或权力范围的命事件，并且服务器端对客户提出的数据操作请求过分信任，忽略了对该用户操作权限的判定，导致修改相关参数就可以拥有了其他账户的增、删、查、改功能，从而导致越权漏洞。
eg：
用户A只能够对自己的信息进行增删改查操作，但是由于对用户的权限没有做出严格的限制，使得用户A可以通过修改数据包，从而达到访问同级用户B或操作用户B的目的，用户A也可以通过修改数据包访问或操作管理员用户C。
三、原理：
越权漏洞，对用户权限的判定、检查授权存在漏洞，针对此漏洞，通过低权限用户账户绕过权限检查，从而访问、操作同级用户或更高权限的用户。
水平越权（同级越权，是一种访问控制攻击）：用户在权限相同级别下的组，可以进行越权访问、修改、删除数据。服务器接收到用户请求数据包，增删改查某条数据时，没有对数据的所属人进行严格判断，直接从前端用户提交的数据包中的表单参数里面获取了userID，并进行授权。如果攻击者恶意构造他人的userID后进行增删改查，那么将导致水平越权的产生。
垂直越权（跨级越权，是一种权限提升攻击）：用户可以在不同权限的组下，进行高级别的权限访问。服务器端没有做严格的权限控制，导致低权限用户只要猜到高权限管理页面的URL，通过低权限用户伪造高权限用户URL，达到访问或控制其他角色的数据，实现了权限提升。
四、产生原因：
4.1、代码逻辑（前端）问题
判定前端传输的数据，根据用户的权限，选择性的显示对应权限的代码内容
只是将前端进行一个隐藏，并没有对后端进行一个权限过滤，没有将用户权限与对应功能进行绑定，高权限用户的功能点还是能被触发
4.2、数据库（后端）问题
数据表没有进行一个很好的权限划分，将不同权限的用户都存在一个user表中（高低权限用户同表），通过usertype类似的字段来区别权限，并未对参数进行一个过滤，攻击者可以修改usertype的参数，达到进行越权访问。
没有进行session等验证
五、危害：
浮想联翩了，漏洞利用能实现什么功能也就能对用户产生哪些危害
用户信息泄露、篡改……
六、漏洞出现：
越权漏洞一般出现在登录页面（权限区分的地方）和增删改查的的地方
针对对象 用途 用户提交信息 userID 使用某些功能时 提交的身份ID (userID、账号等用户的唯一标识信息) 对象ID 对象ID (如交易号) 文件名 文件名
（自身的强大，掩盖一切的平庸）
七、利用过程：
7.1、pikachu（Over Permission-水平越权）
7.1.1、第一步：日常分析参数
登录的用户名和她参数相对应的，都没必要去多次尝试推理爆破啥的了
7.1.2、第二步：日常修改参数
（没事多用用burpsuite，天天在浏览器上改就碰不到burpsuite的问题，到以后碰到问题也不会解决了）
登录lucy用户，然后在lucy里面执行查询个人信息操作
将对应参数使用burpsuite抓包并改为kobe，再放包
7.1.3、第三步：查看返回的信息
现在URL地址是Lucy的，但是查看的信息变成了kobe的
（挺有趣的操作）
7.2、pikachu（Over Permission-垂直越权）
7.2.1、第一步：分析高权限用户操作功能
分析管理员和用户区别
下面登录的pikachu（低权限用户）
只能查看相关信息
登录admin（高权限）去执行相关操作
7.2.2、 第二步：获取操作的URL
点击添加用户
下面这个URL就是执行添加用户操作的
如果是抓包，也就是这样的
注意：但是上面这些只是添加操作的URL，看见GET就知道不是提交表单的POST
7.2.3、第三步：实现越权添加用户
再来看看提交数据时的数据包
使用admin（高权限）提交的表
POST /pikachu-master/vul/overpermission/op2/op2_admin_edit.php HTTP/1.1
……
username=test&password=000000&sex=%E7%94%B7&phonenum=1111111&email=%40qq.com&address=beijing&submit=%E5%88%9B%E5%BB%BA
使用pikachu（普通用户）的session执行添加操作
来的地址，是登录，这一步登录就变成修改了
（感觉就是伪造数据包）
Referer: http://localhost:8080/pikachu-master/vul/overpermission/op2/op2_login.php
然后请求方法和URL都改为修改时候的URL
POST /pikachu-master/vul/overpermission/op2/op2_admin_edit.php HTTP/1.1
使用的是pikachu的cookie
Cookie: PHPSESSID=tb9nagh7k6bteg9hj288pfh481
放包后再查看，就已经添加成功了
（这不就是数据包伪造嘛，不过他确实越权了，这个名字取的没毛病）
