本文更关注CodeQL,因此此处假设黑盒不存在误报。
是否有漏洞 | CodeQL认为 | 黑盒认为 | 是否出现过此情景 | 原因 |
---|---|---|---|---|
真有 | 有漏洞 | 有漏洞 | 是 | 正向结果 |
有漏洞 | 没有漏洞 | 是 | CodeQL 最后一步参数构造的问题,某些参数的值必须属于某个数值集合,否则代码流程中断,较难优化 | |
没有漏洞 | 有漏洞 | 是 | CodeQL Source覆盖不全,优化难度一般 | |
没有漏洞 | 没有漏洞 | 否 | 黑盒不存在误报 | |
真没有 | 有漏洞 | 有漏洞 | 否 | 黑盒不存在误报 |
有漏洞 | 没有漏洞 | 是 | CodeQL Sanitizer覆盖不全,某些情况下可以接受,优化难度一般 | |
没有漏洞 | 有漏洞 | 否 | 黑盒不存在误报 | |
没有漏洞 | 没有漏洞 | 是 | 正向结果 |
若是仅仅依赖白盒扫描器的话,我们可以把规则写细致一点,宁缺毋滥,提高准确率可能会牺牲覆盖率。
若是同时使用黑盒扫描器的话,我们可以把规则放宽一点,牺牲准确率,提高覆盖率可能会牺牲准确率。
仁者见仁,公司的环境不同最佳方案就不同。
规则优化
1、部分Source调用了安全SDK进行编码
还有POST类型的XSS
拼接参数时
AuthorityAssignQueryController.java
指标计算
https://www.zhihu.com/question/19645541/answer/91694636
样本:项目中所有的输入点
正样本:含有反射型XSS漏洞的输入点
负样本:不含反射型XSS漏洞的输入点
CodeQL
正样本:CodeQL判断正确的输入点
负样本:CodeQL判断错误的输入点(CodeQL认为该处有漏洞,但是该处实际没有漏洞)
精确率:CodeQL判断正确的输入点 /(CodeQL判断正确的输入点+CodeQL判断错误的输入点)100%
召回率:CodeQL判断正确的输入点/含有反射型XSS漏洞的输入点100%
全流程
正样本:高可信事件判断正确的输入点
负样本:高可信事件判断错误的输入点(最终认为该处有漏洞,但是该处实际没有漏洞)
精确率:高可信事件判断正确的输入点/(高可信事件判断正确的输入点+高可信事件判断错误的输入点)100%
召回率:高可信事件判断正确的输入点/含有反射型XSS漏洞的输入点100%