借你一双慧眼，识别代码安全审计工具「建议收藏」
代码安全审计产品、代码缺陷分析产品、代码安全分析等基于源代码静态分析技术的产品市场上越来越多，但是质量却层次不齐，误报率非常高，漏报率也不低，究其原因是为什么呢？因为一款静态分析类产品研发不是轻松的事，往往要经历几年时间，产品才会逐渐成熟，支持的开发语言和安全漏洞类型才能达到企业级应用水平，一般中小企业是很难投入如此长的时间进行研发的，而且静态分析类产品底层技术是采用的与编译器非常类似的技术，也就是说大学课堂中编译原理课程上讲得哪些分析技术（例如：抽象语法树、切片、数据流分析、符号执行、指向分析、区间计算、到达定值分析、守卫值和非守卫值等等让人理解起来头疼的技术）大多都要用上，我记得当时学这些原理时就似懂非懂的，再把这些技术应用到产品中，难度可想而知，所以说市场上国内外的主流静态分析工具必然采用这些技术，把程序代码转化为抽象语法树是必须的一步，在抽象语法树上基础上，形成控制流图、函数调用图等之后再次进行切片分析，各种守卫值计算等等，零星的技术分析在网络上大多都能找到，但是缺乏系统化的技术分析，用这些技术、算法编码实现，在工程实践中会遇到各种各样的问题，产品市场化更是具有非常高的门槛，市场很多产品并非采用这样的主流技术，大多只是通过文件遍历扫描过程中，使用规则表达式、关键字搜索等技术匹配的特征字符串，所以这样的分析工具必然误报率非常高，这种搜索方法也只能查出一些特定的缺陷或安全漏洞函数，硬编码等特定缺陷，对于很多跨越文件的缺陷和安全漏洞是根本发现不了的。对于检测出大量误报的审计报告，测评人员和开发人员要花大量时间去分析，消耗大量时间，长此以往，这种工具必然被淘汰。
那如何来辨别一款静态缺陷分析类工具的质量优劣呢？我以国际上通用的一个Java检测的Benchmark中代码作为案例分析一下。介绍在可以OWASP官方网站（https://www.owasp.org/index.php/Benchmark）找到，在GitHub（https://github.com/OWASP/benchmark）上可以下载到最新代码，现在最新版本是Benchmark 1.2beta，目前包括2740个真假漏洞，通过一个检测工具报出的TP-真实漏洞、FN-漏报漏洞、TN-无误报漏洞、FP-误报漏洞通过约登指数（Youden Index）计算公式（真实漏洞检出率-假漏洞检出率）计算出得分，满分是1.0分。也就是评价一个检测工具最好的情况是真实漏洞全部报出，而假漏洞没有报出。在2740个案例中，有1415个真实漏洞，1325个假漏洞，对于一款非主流工具来说，可能把绝大多数假漏洞也作为漏洞报出，则约登指数得分很低。所以评价一款静态缺陷检测工具的话，最好通过国际上认可的标准案例集进行验证。当然除了Java语言之外，C/C++语言、PHP、Python等语言都有对应的案例集，详情可浏览https://samate.nist.gov/SRD/testsuite.php#sardsuites
我从SQL注入漏洞中选择两个案例，BenchmarkTest00043是真实漏洞，BenchmarkTest00052是假漏洞。这个表在下载Benchmark 1.2beta根目录中。
首先打开BenchmarkTest00043.java文件，查看里面代码
大家可以看到一般检测工具会直接定位到54行，因为这里出现一个特征方法executeUpdate，执行sql语句。但是如果没有上下文分析，则并不能确定是否为一个真实漏洞。主流检测工具会通过代码切片后，在抽象语法树上进行向后遍历，分析sql参数是否进行注入处理，则找到第50行，第50行是sql字符串的拼接，又引入了param变量。还需要在语法树上回溯param变量的取值，则找到第46行和47行，第47行无侵入可能，在46行，param变量值是通过scr对象的getTheParameter方法传递”vector”字符串获得，再向上找到src对象，src对象来自于其它类的定义，把post报文的请求参数request传递给SeparateClassRequest方法。
打开SeparateClassRequest.java文件
在构造函数中，传入了request参数，src调用getTheParameter方法时，把“vector”传给形参p，方法返回了p对应的参数值，并没有对post传入的参数进行任何处理。经过一系列的回溯和上下文分析，最后确认是存在着SQL注入漏洞。一般单文件漏洞扫描是无法跨文件去回溯和上下文分析确认是否为真实漏洞，但是通过简单的函数名称判断也会报出这个漏洞。但是对于OWASP Benchmark 作为一个专业的评价基准项目，也考虑了工具对于漏洞的分析能力，是否对于假漏洞，是否能识别出来呢？
打开BenchmarkTest00052.java这个文件，如下：
请上面代码截图中标注，对于分析也是与上面例子一样，通过在第55行发现可能的污点后，回溯到第46行。再看对应的另一个文件中的有关getTheValue方法。
大家是否看到getTheValue方法返回的是固定字符串“bar”，对于具有上下文和跨文件分析能力的工具来说，分析到这里，并不会报出漏洞。因为这不存在SQL注入的可能。而对于一般扫描工具，无法做到上下文分析，没有生成抽象语法树，更难于做到跨文件分析，自然会报出这个漏洞，但是这是一个假漏洞。对于真假漏洞基本持平的Benchmark 2740 全部漏洞，存在得0.10分左右的可能，毕竟真实漏洞比假漏洞多了90个。
好了，如果读者认真读到了这里，我相信您也具有了一双慧眼，掌握了如何对一款代码安全审计工具或代码缺陷检测工具做出评价和选择。
关注安全 关注作者
—————————————————————————————————————–
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/184233.html原文链接：https://javaforall.cn