如果写请求接口的级别过高，首先比较两个请求的返回是否一致。如果两个请求都成功并
且回报一致，则可能存在越权的风险。例如，更新商品信息可能会返回商品不存在或未经授权
的呼叫没有权限，或者可能都返回成功，但实际操作不会生效。只有商品信息的实际查询才能
进行，直到真正成功，这是一开始缺乏标准化造成的问题。目前越权算法无法很好的识别，先
标记为人工确认，需要转入人工处理后再进行改进。 一个系统需要一定的反馈机制来优化逻辑，提高逻辑判断的准确性。在后检查中，需要人工确
认的问题是通过引发之前识别并人工确认的问题来推断的。目前，需要手工确认的检验结果会
在历史检验记录中进行检查，如果是最近确认的，则标记为通过。当界面的字段发生变化或者
距离上次确认的时间间隔较长时，历史检验记录也会被标记为待确认，需要定期重新确认。后
面希望通过算法挖掘和学习已经发现并确认的问题，更智能的给出判断结果。除了核心算法，
整个平台还提供了操作管理、界面管理、结果管理等功能。，并提供了未授权配置、任务执行
、结果显示和分析等功能，方便R&D学生主动使用和管理安全问题。 发现和解决安全问题的过程是:平台总结每天扫描发现的问题，并转移到相应的业务上测试是否
是问题；如果问题转移到相应的开发进行修复；后续问题修复后，关闭问题，入库归档，沉淀
为数据；项目上线前，检查本次涉及的接口扫描情况，评估是否存在安全问题，修复后做补充
测试或回归。通过对界面越权平台的扫描，以及R&D同事和安全部门的支持，该机制运行良好
，可以在一个月内，在考前20+学生手动测试时发现安全问题。逐步形成了适合受好评业务系
统的非授权防控体系，进一步减少了测试人员的投入，加强了安全质量标准的执行。同时，培
养了R&D学生的安全意识，在代码编写和用例设计阶段充分考虑了安全性，产生了很大的价值。
目前接口越权扫描还在单点运行，考虑接入持续集成和安全防护系统可以发挥更大的作用。每
个业务的越权对象和越权定义都不一样，目前做出的判断也比较粗糙，需要抽象出合理通用的
算法和规则来满足各种业务场景，比如按照对象X操作的维度进行处理，可配置的可插拔规则
等。一般来说，规则的配置不够聪明。后续与安全等部门的同学合作，要考虑采用新的思路或
者机器学习、人工智能等技术来提高识别率和准确率。
还没有评论，来说两句吧...