Over Permission

越权风险问题

越权访问（Broken Access Control，简称BAC）是Web应用程序中一种常见的漏洞

越权访问漏洞的产生
比如，某个订单系统，用户可以查询自己的订单信息。A用户查询订单时，发送的HTTP请求中包含参数orderid=A，订单系统取得orderid后最终会查询数据库，查询语句类似于select * from tablename where orderid = A。B用户查询订单时，发送的HTTP请求中包含参数orderid=B，系统查询数据库语句类似于select * from tablename where orderid = B。正常情况下，每个用户只会查询到自己的订单。但是，当B用户将自己的HTTP请求参数修改为orderid=A，那么最终B用户执行的数据库语句变成了select * from tablename whereorderid = A，导致A的订单信息被B用户获取到了。

概述

如果使用A用户的权限去操作B用户的数据，A的权限小于B的权限，如果能够成功操作，则称之为越权操作。 越权漏洞形成的原因是后台使用了不合理的权限校验规则导致的。一般越权漏洞容易出现在权限页面（需要登录的页面）增、删、改、查的的地方，当用户对权限页面内的信息进行这些操作时，后台需要对当前用户的权限进行校验，看其是否具备操作的权限，从而给出响应，而如果校验的规则过于简单则容易出现越权漏洞。
因此，在在权限管理中应该遵守：
1.使用最小权限原则对用户进行赋权;
2.使用合理（严格）的权限校验规则;
3.使用后台登录态作为条件进行权限判断,别动不动就瞎用前端传进来的条件;

漏洞产生条件

越权漏洞高于逻辑漏洞（逻辑漏洞就是指攻击者利用业务的设计缺陷，获取敏感信息或破坏业务的完整性。一般出现在密码修改、越权访问、密码找回、交易支付金额用户登录等功能），是由于权限校验的逻辑不够严谨导致的。每个应用系统其用户对应的权限是根据其用户功能划分的，而每个企业的业务又都是不一样的。因此越权漏洞很难通过扫描工具发现出来，往往需要手动进行测试。

常见越权漏洞

通过修改GET传参来越权。案例
修改POST传参进行越权。案例
修改cookie传参进行越权。案例
抓取传参可以在浏览器、APP、应用程序exe 案例
未授权访问。严格意义上而言这个不属于越权漏洞，但是在日常测试中常常会遇见。只要输入正确的网址就可以直接访问，例如/admin默认是登录，登录后跳转到user.php,然后你直接访问user.php，发现你直接有后台权限。案例
业务逻辑绕过。案例

水平越权（平行越权）

概述

A用户和B用户属于同一级别用户，但各自不能操作对方个人信息，A用户如果越权操作B用户的个人信息的情况称为平行越权操作。
在这里插入图片描述

pikachu靶场练习1

在当前已登陆的lucy的个人信息页面，修改url里面的username，改为lili的用户名，如果可以登陆成功查看lili的信息，说明这是一种越权行为,我们需要在源代码中添加一段判断的get请求是否来自于lucy即当前登录的用户的代码,来拒绝越权的尝试。
在这里插入图片描述

垂直越权

概述

权限较低的用户去执行高权限用户的操作。
在这里插入图片描述

pikachu靶场练习

1.获取普通用户登录态的cookie
在这里插入图片描述
2.用普通用户的cookie来代替超级管理员创建新用户的cookie，在burp页面右键点击发送到repeater，关闭代理。在超级管理员创建用户的页面点击回到admin，在burp页面点击send，刷新超级管理员的登陆页面，即可操作成功。
在这里插入图片描述

用普通用户的身份进行超级管理员的操作，如果操作成功，即可说明后台存在垂直越权的漏洞。通过burp抓包拦截超级管理员登陆的数据包，然后将其登录态的cookie【指某些网站为了辨别用户身份、进行 Session 跟踪而存储在用户本地终端上的数据，而这些数据通常会经过加密处理】代替普通用户登录态中的数据包中的cookie，可以操作成功，即进行了一次垂直越权查看后台源码可发现，源码中只有判断超级管理员是否登录的代码，应该添加一段判断当前用户登陆的权限,判断用户级别是否为超级管理员的代码。
在这里插入图片描述

修复建议

越权访问漏洞产生的主要原因是因为没有对用户的身份做判断和控制，防护这种漏洞是，可以使用session【当访问服务器某个网页的时候,会在服务器端的内存里开辟一块内存，这块内存就叫做`SESSION】来控制，例如用户在登录成功后，将用户名写入session中，当用户查看个人信息时，通过session中取出username，而不是从GET或者POST中取到username，那么此时的username就不会被篡改了