一次水平越权漏洞的利用

本文记录了一次水平越权的全过程,大致发生了如下:

  • 修改post参数,导致越权查看和删除;

  • 修改路径(REST风格参数),导致越权修改;

  • 修改cookie字段,绕过登录实现未授权访问;

  • 越权编辑植入xssPayload,获取完整cookie。

好了,开始虚构。

0x01 越权查看和删除

注册登录进入个人中心,一通胡乱测试,发现可通过修改参数来越权查看或修改任意用户资料。这里就拿教育经历做演示吧。

1、先创建,再修改。

2、抓包拦截重放,通过infoId去引用对象,返回用户信息,并进入编辑状态。

3、请求包中通过infoId参数引用对象,sql注入无果,尝试修改infoId值,引用对象成功,返回其他用户信息。删除时修改post参数值同样可越权删除任意用户信息。

4、继续编辑自己的自我评价,点击保存。发现前面infoId的值跑到路径中去了,也尝试修改一下(注意这里涉及修改了,就不要随意修改了,可以尝试修改另外的测试账号的内容)。

5、返回修改成功(去目标账号中刷新,发现资料确实被修改了)。

6、为什么路径也能作为参数测试点呢,因为这里使用的是REST风格参数。

参考链接:https://blog.youkuaiyun.com/weixin_44750790/article/details/118195473

0x02 绕过登录未授权访问

前面一顿操作,一直没能获取到手机号邮箱等敏感信息,结果发现这些基本信息的编辑使用的不是同一套流程,为了能扒出来,就有了下文。

1、下面是预览资料的请求,没看到get/post参数啊,自然不存在“不安全的直接对象引用”这类越权漏洞。

很明显是通过cookie鉴别的,又这么多字段,一般这种我都不考虑越权(头不够铁),不过乍一看cookie中字段值貌似都为base64编码。竟然都是base64编码的,这!

2、控制变量法,逐个字段删除,找出有效的字段(删除某个字段,页面无变化说明该字段是无效字段,相信大家都知道这个技巧)。一番删除操作,只留下了 career_id 这个字段。重放返回该个人资料,修改删除该字段便异常,说明服务端仅校验该字段。

仅校验一个字段,看似使用是简单的base64编码,不错不错!

3、解码看看,5160397估计就是该用户id了。

4、通过Burpsuite的Intruder模块遍历career_id字段,抓个别的id看看。

5、使用该id,成功越权访问到该用户的个人简历信息。

6、接下来,复制该cookie替换掉自己浏览器中的cookie,成功绕过登录,未授权访问其他用户个人中心,且可进行资料编辑删除等操作。

0x03 利用“self-xss“获取更多权限

正经的越权到上面差不多就结束了,下面就是利用的“歪门邪道”了。

1、进一步摸索发现,其实仅仅是个人中心的访问凭证是只校验 career_id 这一个字段,其他页面还校验了更多的cookie字段,只有校验通过才可访问更多页面查看岗位信息、投递简历等操作。

2、其实吧,编辑资料这里还存在个存储型XSS。简历编辑页的存储型xss,基本是个self-xss无疑了,一般谁能访问到我的简历编辑页。

3、竟然都能越权编辑他人简历了,那我们是不是可以在编辑别人的简历的时候向其中植入xssPayload,一套“越权 + self_xss”组合拳。

另外,不难从前面的请求包中看出,这些资料编辑操作,一定是存在CSRF漏洞的。那么,又一套“CSRF + self_xss”组合拳。当然,CSRF肯定不如我们越权编辑稳当。接下来就等目标访问了......

这里就简要分析下思路,就不做演示了。

0x04 总结

总结一下测试水平越权漏洞的基本思路:

  1. 控制变量法删除参数或cookie字段,找到有效参数或cookie字段;

  2. 尽可能的对参数或cookie字段去模糊化,再进一步测试;

  3. 修改参数值或cookie字段,对增删改查等操作进行越权测试;

  4. 越权结合其他漏洞提升危害等级。

越权漏洞也可以结合Authz这类burp插件来测试,不过一般都局限于查看操作的越权。

链接:http://www.360doc.com/content/22/0715/07/77981587_1039917515.shtml

### 水平越权漏洞的原因及原理 水平越权漏洞(Horizontal Privilege Escalation)指的是同一权限等级内的不同用户之间发生的数据或功能访问超越了应有的边界。具体来说,当应用程序未能正确验证当前用户的标识符或其他唯一识别信息时,可能导致一个普通用户可以访问其他同级用户的敏感数据或执行不应被允许的操作[^3]。 #### 原因分析 1. **缺乏有效的身份验证机制** 如果系统仅依赖于前端传递的身份标识(如URL中的ID参数),而未在服务器端进行严格的校验,则容易受到攻击者的利用。例如,在查看订单详情页面时,如果只是简单地信任客户端提交的商品编号而不做进一步确认,那么恶意用户就可以轻易更改这个编号来窥探别人的订单情况[^4]。 2. **不安全的对象引用** 当程序设计人员假设某些对象引用(Object Reference, OR)是私密的或是难以猜测到的时候,实际上这些OR可能会暴露给未经授权的人士。比如文件路径、数据库记录索引等都属于此类潜在风险点。一旦这类信息泄露出去,并且服务端又缺少必要的防护措施的话,就会形成安全隐患[^1]。 3. **业务逻辑错误** 开发过程中可能存在一些疏忽之处,使得即使是在正常流程下也有可能触发越权行为。例如,在社交网络平台上实现好友间的消息发送功能时如果没有仔细考虑消息接收方的有效性和合法性判断条件,就可能让非朋友关系之间的用户互相通信,进而造成隐私侵犯等问题[^2]。 ```python # 不推荐的做法:直接使用未经验证的用户输入作为查询条件 def get_user_profile(user_id): profile = db.query(f"SELECT * FROM users WHERE id={user_id}") return profile # 推荐做法:加入额外的安全检查以防止横向越权 def secure_get_user_profile(current_user_id, target_user_id): if not is_friend_of(current_user_id, target_user_id): # 额外增加的好友关系验证 raise PermissionDeniedError() profile = db.query(f"SELECT public_info FROM users WHERE id={target_user_id}") # 只返回公开的信息字段 return profile ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值