SAST

本文转载：https://xz.aliyun.com/t/10216

SAST(Static Application Security Testing)：静态应用程序安全测试技术，通常在编码阶段分析应用程序的源代码或二进制文件的语法、结构、过程、接口等来发现程序代码存在的安全漏洞。

目前有多款静态代码检测的开源项目，通过对几款项目的调研，可总结出目前优秀的静态代码检测工具的基本流程为：

对于一些特征较为明显的可以使用正则规则直接进行匹配，比如硬编码密码、错误的配置等，但正则的效率是个大问题。

对于 OWASP Top 10 的漏洞，通过预先梳理能造成危害的函数，并定位代码中所有出现该危害函数的地方，继而基于Lex(Lexical Analyzer Generator, 词法分析生成器)和Yacc(Yet Another Compiler-Compiler, 编译器代码生成器)将对应源代码解析为AST(Abstract Syntax Tree, 抽象语法树)，分析危害函数的入参是否可控来判断是否存在漏洞。通过操作类的字节码返回解释器执行。

大致流程如下图所示（该流程也是目前主流静态代码检测产品的大致流程）：

1.2 SAST技术发展阶段
当然静态检测所对应的技术也是经过不断发展。这边推荐阅读@LoRexxar师傅写的《从0开始聊聊自动化静态代码审计工具》一文，文中详细介绍了静态代码检测技术的几个发展阶段：

技术发展阶段 代表工具 优点 缺点 备注
基于正则-关键字匹配的方案 Seay：高覆盖，通过简单的关键字匹配更多的目标，后续通过人工审计进行确认；-Rips免费版：高可用性，通过更多的正则约束、更多的规则覆盖多种情况。 方案简单，实现起来难度不大 1. 无法保证开发人员的开发习惯及代码编写，误报率及漏报率非常高；2. 无法保证高覆盖及高可用性； 3. 维护成本太大。
基于AST(抽象语法树)的方案 Cobra：侧重甲方的静态自动化代码扫描，侧重低漏报率； Kunlun-M：侧重于白帽子自用，只有准确的流才会认可，否则标记为疑似漏洞，侧重低误报率。 在编译处分析代码，无需关注开发人员的开发习惯（编译器是相同）。 1. 无法保证完美处理所有的AST结构； 2. 基于单向流的分析方式，无法覆盖100%的场景；3. 忽略了大多数的分支、跳转、循环这类影响执行过程顺序的条件，会造成 常见的语义分析库：PHP-Parser、phply、javalang、javaparser、pyjsparser、spoon
基于IR/CFG这类统一数据结构的方案 fortify、Checkmarx、Coverity及最新版的Rips：都使用了自己构造的语言的某一个中间部分。 较于AST，该方法带有控制流，只需要专注于从Source到Sink的过程即可。
基于QL的方案 CodeQL：可以将自动化代码分析简化约束为我们需要用怎么样的规则来找到满足某个漏洞的特征。 把流的每一个环节具象化，把每个节点的操作具像成状态的变化，并且储存到数据库中。这样一来，通过构造QL语言，我们就能找到满足条件的节点，并构造成流。
0x02 静态代码检测（代码审计）工具调研
本次调研测试，对四个开源项目（两个Java，两个PHP）进行扫描，分别为DVWA、Mutillidae、java-sec-code、OWASP Benchmark。其中OWASP Benchmark是OWASP组织下的一个开源项目，又叫作OWASP基准测试项目，它是免费且开放的测试套件。它可以用来评估那些自动化安全扫描工具的速度、覆盖范围和准确性，这样就可以得到这些软件的优点和缺点。OWASP Benchmark计分器的使用可以参考下文 0x03附录-3.1 OWASP Benchmark计分器使用。

标签：SAST,AST,静态,代码,Benchmark,OWASP,正则
来源： https://www.cnblogs.com/fan-gx/p/16456594.html