视频笔记
- 前面讲了什么是IDOR，以及IDOR有多频繁，分类，略。
- 越权可能产生在多个不同的方式（攻击树）
- 一种越权绕过的场景：加了一个ignore_auth（此类后门），假如后门为1的时候就不会做权限校验。
- 另一种可能是如果skip_auth 不等于1的时候，才做校验，否则默认不做校验
- 或者当取不到uid时候，默认作为超级管理员账号处理
- 或者当取不到uid时候，默认取弱登陆身份（另外字段）
- 第三种可能：权限验证用的函数，完全没有验证，假的骗人。
- 怎么修复呢？
- 典型的检测方法
- 考虑被突破后怎么办（容侵），风险如何控制最低。
- 做限流，然后人工看超过频率。
- 人工枚举所有SAST规则。
- 最终：攻击尝试 不等于 攻击成功（每天一堆误报）
- 典型的修复方法
- 重新实现一种验权函数，然后规定所有人都用它（配合SAST，即使误报高）。
- 花很长时间，人工CodeReview。
- Case By Case 地与人安全评审。
- 问题：如何提高可扩展性？
- 对整体问题有个定义
- 这是一个接口分类问题
- 到底这个接口有没有鉴权？有？还是没有？
- 导致的结果是什么？
- 根据接口的请求和返回内容，进行分类接口
- 鉴权方法：即使你一个个硬编码，你没法枚举和跟上所有越权的情况。
- 这是一个接口分类问题
- 我们如何改进
- 了解与表达请求数据流
- 从可能被利用出发
- 如何通用地预测越权的结果？
- 如何改进-2
- 正常流量是什么样子？
- 执行环境是什么样子（如DB等）
- 收口验证逻辑
- 预测访问结果是否一致
- 我们可以尝试使用监督式模型来干！
- 训练集：请求 - 结果 -> 模型
- 预测集：请求 - 模型 -> 预测（是否OK） -> 是否告警/阻止
- 训练用的素材
- 验证结果Log - IAST执行流日志
- DB行为Log - DB日志
- 返回结果Log - 流量日志
- 把特殊信息作为参数添加到Request之中
- 有些复杂的业务逻辑不好收口
- 应用不一定像期待的那样执行
- 需要收集请求中的一些信息（IAST）
- 例如以下2个请求中的Log信息（IAST）
- 访问成功与失败是不同的
- 请求的次数特征和请求response长度，请求操作次数，是不同的。
- 有了数据，我们就可以用决策树模型了自动预测是否有越权漏洞。
- 决策树提升方案
- 避免过拟合
- 使用随机森林
- 使用GBM
- 使用决策树的问题
- 准确率55%
- 使用后端日志特征的局限：
- 同质化的信号
- 譬如查询次数一模一样，譬如每次都是先查询数据，然后再检查身份是否一致，一致再输出，这样就有漏报了。
- 同质化的信号
- 根据试验结果
- 准确率52%
- 召回率54%
- 提高的方案：
- 解决这个问题的方案，是把response信息也加上，譬如response的content-type，和content-Size。
- 关于Reponse信息需要注意要点
- 合规问题 — PCI不允许
- 结果可能被加密
- 有些用户自定义Response（如算法自动化推荐）
- 匿名化数据
- 脱敏数据 / 删除数据字段。
- 不知道说的是啥东西，似乎用代号来hashing返回结果？
- SSDEEP看起来是一种hashing差分算法？
- 使用SSDEEP这种算法处理Response信息，好处是你可以识别编辑距离变化有多大，而不用操作content本身。
- 进而可以转化成图像相似问题来解答。
- 我们使用了一些相似度对比算法，最后发现一些没屌用的，一些有用的，还有待验证的如上。
- 对于Json返回，也可以生成Baghashing
- 然后使用GBMs方法干。
- 到现在我们搞定两种情况
- 使用后端日志数据干活的方法（IAST）
- 使用response数据干活的方法（ReponseData）
- 以上两种方案，都是我们明确能够得到鉴权日志的情况
- 回答的是‘这个鉴权操作是否成功’的问题（依然需要有人发起恶意攻击尝试）
- 识别我返回鉴权失败，但是又给你返回了客户信息。
- 如果auth_checks_list没有，我们可以看db查询select的字段是否在response的字段里
- 用户a，请求用户b的数据，可以看所有结果，然后检查资源与请求的关系。它可能是隐私数据，也可能是公开数据。
- 怎么表达和解决这类问题呢？
- 可以生成一个行为序列新模型，然后用到WAF这种产品中，进行实时训练和预警（不同应用不一样）
- 略
- 可以阻止越权写操作
- 然后分享后面都是说的是自己做的Demo，略。
若有收获，就点个赞吧
0 人点赞
