写毕设调查背景知识时做的，t00ls上发过好像没啥关注Orz，在这也分享一下，有兴趣的朋友们欢迎一起讨论呀。

词法分析技术是最简单的一类漏洞挖掘技术，其主要思想是将代码文本与归纳好的缺陷模式进行匹配，以此发现漏洞。由于其不深入分析程序结构和语义，往往只能挖掘较为简单的一类漏洞，并且存在相当高的误报率，在实际场景下应用较少，但由于其思想简单，适用性很广，目前也还存在类似工具，如：MobSF，Cobra。

形式化方法分析主要思想是将软件代码性质进行形式化描述，再判断该描述是否满足漏洞特征的一类分析方法[1]，其中定理证明技术是形式化代码分析技术的主要代表。

定理证明技术将漏洞存在（或不存在）定义为一定理，再将源程序代码特征转化为数学表达形式，最后对数学表达进行逻辑推理，若定理存在性得以证明，则漏洞存在（或不存在），即漏洞挖掘过程类似于数学上的定理证明过程。主要代表性工具有 infer、 ESC/Java[2] 和 saturn[3]。

该技术作为一种使用严格数理逻辑推理作为检测手段的技术，误报率较低，但由于其需要针对特定漏洞构建数学条件，需要大量人工参与，有的漏洞甚至难以用数学结构表达，目前只适用于死循环、资源泄露和空指针等问题，对新漏洞的扩展性不高，同时，如何将大规模程序应用于形式化方法分析也成为工业界亟待解决的问题。

对于形式化分析技术本人也不是很了解，想要进一步了解的建议看下论文[1]和lean2。

符号执行技术是一种将程序执行可达性问题转化为约束求解问题，并以此进行漏洞挖掘的技术[4]，代表性工具有angr，DART[5], CUTE[6], EXE[7]和KLEE[8]。

具体来说，符号执行包含一个符号状态表$ σ $和一个符号路径约束$PC$，开始时，$σ=∅, PC=true$，每读取一条语句，就将变量抽象为约束求解中的变量、常量或他们的表达式放入$σ$中，特别的，当遇到条件判断$if(e)$时，将if分支的$PC$更新为$PC ← σ(e)$，将else分支的$PC'$更新为$PC← ~σ(e)$，随后使用约束求解器求解$PC$和$PC'$，如果约束不满足，则停止对该分支的解析（因为该分支不可达）。当符号执行遇到程序崩溃、预先定义的漏洞语句、或是程序正常退出时，整个分析停止，同时可以计算可以到达停止点的输入。

符号执行可以分析程序中的控制流、覆盖更多代码，同时也有效降低了误报率，但传统符号执行严重依赖于约束求解器的能力，例如，若约束求解器不能处理非线性计算，或是整个程序中存在无法分析的第三方库，那么整个分析将无法继续。为解决这些问题，研究者们提出了动态符号执行的想法[5,6,7,8]，但其在实际应用中仍不是很广泛，主要原因在于其需要大量计算资源，甚至在处理大规模程序时，出现的路径爆炸问题会导致约束求解无法产生结果。

符号执行技术是目前工业界和企业界都在研究的热门领域，这里推荐英语好的朋友看下此视频和符号执行的经典文章“Symbolic Execution for Software Testing: Three Decades Later”[4]，英语不好的朋友推荐一下这wcventure大佬总结的这篇文章。

数据流分析是一种按程序执行路径模拟数据流动的一种分析技术，其原本用于进行程序优化[9]，安全研究者们发现后将其运用于漏洞挖掘中，如今该技术在白盒，灰盒和黑盒测试都有应用[10]。

在数据流分析过程中，存在过程内分析和过程间分析，过程内分析主要对函数内分析，而过程间分析主要处理跨函数分析。

• 对于过程内分析，根据其对程序路径的分析精度，可分为流不敏感分析，流敏感分析和路径敏感分析。流不敏感的数据流分析只是按代码行号从上而下进行分析；流敏感分析会首先产生程序控制流图（CFG, Control Flow Graph），再按照CFG的拓扑排序正向或逆向分析；路径敏感信息不仅考虑到语句先后顺序，还会考虑语句可达性，即会沿实际可执行到路径进行分析。

• 过程间分析，首先构造程序的调用图（CG, Call Graph），接着遍历图中函数进行过程内分析，当遇到其他函数时，若已分析过，则直接使用分析结果向下分析，若未分析过，则跟进该函数，再次进行过程内分析，并且将分析结果保存。

数据流分析能够一定程度上理解程序语义，是一种比词法分析技术更为精确的一类分析技术，其关键在于准确计算程序的数据流。

污点分析属于数据流分析的变种，通过判断关键操作的数据（如调用危险函数的参数）是否可被用户操控，推测程序是否存在安全性漏洞。由于其了解程序上下文，并且有较强的可解释性——安全工程师可以通过跟踪污点传播过程判断是否存在安全问题，因此其也成为了挖掘 Web 或 Android 漏洞较为常用的技术，也被很多开源或商用白盒扫描器使用，如：Pixy[11]、Find Security Bugs、Fortify和LGTM。

三要素

污点分析主要有三个组成要素：污点信息产生点（source）、污点信息汇聚点（sink）和污点信息清洁点（sanitizer），它们通常需要富有经验的安全工程师手动设置。

• 产生点（source）：污点产生点往往是用户输入的数据，比如Web应用中读取URL参数的函数，顾名思义，这些函数调用后的返回值被标记为污点——攻击者可以操控的数据点。
• 汇聚点（sink）：检查点是程序的一些敏感操作，如调用数据库查询语句，或是将数据返回到网页，如果这些操作的数据是污点，那么意味着操作可被攻击者利用，即程序存在漏洞。
• 清洁点（sanitizer）：清洁点通常是对污点进行消除的一类操作，如SQL注入、XSS中的过滤函数。清洁点是污点传播准确性的重要保证，不能识别清洁点即会引发污点过污染问题。

分析过程

污点分析分为静态污点分析和动态污点分析，两者区别在于静态污点分析只使用程序代码模拟污点传播过程，而动态污点传播则通过程序的实际运行进行传播，由于本文关注于白盒测试情景，故只介绍静态污点传播方法，而在下一子章节会介绍动态传播的优劣势。

在定义好三要素之后，污点分析法会与数据流分析一样，对程序进行过程内分析和过程间分析。

过程内分析包括了显式流分析和隐式流分析，显示流分析即通过分析变量的数据依赖关系进行污点传播，而隐式分析则是指考虑控制依赖进行污点传播。

如上图所示，首先假设变量$a$为污点变量，实线箭头表示了显示污点传播路径，而虚线箭头表示了隐式污点传播路径，同时该图也说明了过程内污点传播基本思想，即从上至下遍历数据流图，若未标记的变量依赖于污点变量，则新变量也被标记为污点变量。虽然攻击者确实可以利用控制依赖操作数据进行攻击，但由于其分析复杂且会产生大量误报，在工程领域常常只做数据流依赖的显示分析，因此本文主要讨论显式流分析。

现代程序存在着复杂的函数调用，除了进行过程内分析，还需要进行过程间分析。其分析首先构造函数调用图（Call Graph），接着搜索存在产生点的函数，对于每一个存在产生点的函数，自顶向下分析（也可以自底向上分析）。遇到函数调用时，跟进被调函数，进行过程内污点分析，将分析结果表达为 的函数摘要，其中$f$包含函数本身摘要信息（类名方法名和函数签名），$S$指调用过该函数后被污染的变量集合，$r$取值0或1，标记函数返回值是否被污染；接着根据函数摘要，再进行过程内分析，如此往复直至分析完函数所有代码块或是污点传播至汇聚点，报告漏洞。

如上图所示，分析过程从左侧函数开始，因为其找到了一处产生点——request.getParameter("xss")，于是将污点传递到变量p，接着调用函数func(p)，于是对函数func()做过程内分析，得到其函数摘要，$\left\langle func, \left{a, b, c\right}, 1\right\rangle$，于是回到调用者的函数内，变量q被标记为污点，又因为第三行存在一处汇聚点——response.getpriter.print()，并且参数为污点，于是报告此处有漏洞，并且根据汇聚点可以判断该漏洞是一个 XSS 漏洞。

优势和不足

污点分析能够对程序上下文有一定理解，往往能产生误报率相对较低以及可解释的漏洞报告，其方法对 Web 类型的安全漏洞覆盖率较高，而污点类型的漏洞普遍具有较高危害性，因此该方法已被很多工业界、学术界的安全静态扫描工具所使用。

然而，污点传播仍有可能发生误报，以下通过简单示例来说明。

首先，污点传播对容器类型无法做很好处理，如上图 (a)所示，当污点传入 容器类型时（在此例子中为 map），静态污点传播只能将这类变量的传播规则设 为传播/不传播污点，从而造成过污染/欠污染，就如图所示，若设为 map 传播污点，由于案例实际从容器中取出的是没有污点的变量，即过污染，而若设为不传播，若 q 取出参数 p，那么又导致欠污染。动态污点传播虽然解决了这一问题， 但是由于其使用条件复杂，且无法用于静态分析，本文暂不讨论。

此外，不论是动态污点传播还是静态污点传播，其对污点清洁点的识别能力几乎为零，如上图(b)所示，该函数是一个典型的防御 SQL 注入的污点清洁 函数，即在第 2∼5 行对待拼接 SQL 字符串存在的特殊字符进行替换和过滤，但 是污点传播并不能识别这些清洁函数，导致误报。

再者，静态污点传播对控制流没法做很好的处理，如上图(c)所示，在第三行，程序已经对可能产生的 SSRF 漏洞进行了处理，即如果是内部地址则直接返回，但是不论是考虑显式流还是隐式流，污点传播都不能避免这一类误报。

最后，对于特殊触发条件的漏洞，污点传播无法很好处理，如上图(d)所示， 在第二行，因为 SSRF 要求攻击者能够操控主机名，所以即使用户输入的污点变量拼接在一个正常主机名之后，程序也不会出现 SSRF ，而按照污点传播分析法，毫无疑问它会报告这段程序存在 SSRF 漏洞。

这些问题也是工业界和学术界亟待解决的问题，如工业界开始尝试用符号执行，以及用黑盒、IAST配合解决白盒，在学术界也正尝试用机器学习解决问题。

1. J. M. Schumann, Automated Theorem Proving in Software Engineering, Springer Berlin Heidelberg, Berlin, Heidelberg, 2001.
2. C. Flanagan, K. R. M. Leino, M. Lillibridge, G. Nelson, J. B. Saxe, R. Stata, Extended static checking for Java, in: Proceedings of the 2002 ACM SIGPLAN Conference on Programming Language Design and Implementation, Vol. 48, ACM Press, New York, New York, USA, 2002, pp. 234–245.
3. Y. Xie, A. Aiken, Saturn: A scalable framework for error detection using Boolean satisfiability, ACM Transactions on Programming Languages and Systems 29 (3) (2007) 16
4. C. Cadar, K. Sen, Symbolic Execution for Software Testing: Three Decades Later, Communications of the ACM 56 (2) (2013) 82–90.
5. P. Godefroid, N. Klarlund, K. Sen, DART: directed automated random testing, in: Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation, Vol. 40, ACM Press, New York, New York, USA, 2005, pp. 213–223.
6. K. Sen, D. Marinov, G. Agha, CUTE: a concolic unit testing engine for C, Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering 30 (5) (2005) 263.
7. C. Cadar, V. Ganesh, P. M. Pawlowski, D. L. Dill, D. R. Engler, EXE: Automatically Generating Inputs of Death, ACM Transactions on Information and System Security 12 (2) (2008) 1–38.
8. C. Cadar, D. Dunbar, D. Engler, Klee: Unassisted and automatic generation of highcoverage tests for complex systems programs, in: Proceedings of the 8th USENIX Symposium on Operating Systems Design and Implementation, OSDI 2008, Vol. 8, 2019, pp. 209–224
9. G. A. Kildall, A unified approach to global program optimization, in: Proceedings of the 1st annual ACM SIGACT SIGPLAN symposium on Principles of programming languages, ACM Press, New York, New York, USA, 1973, pp. 194–206.
10. B. Shastry, F. Yamaguchi, K. Rieck, J. P. Seifert, Towards Vulnerability Discovery Using Staged Program Analysis, in: Detection of Intrusions and Malware, and Vulnerability Assessment, Springer, Cham, 2016, pp. 78–97.
11. N. Jovanovic, C. Kruegel, E. Kirda, Pixy: a static analysis tool for detecting Web application vulnerabilities, in: Proceedings of the 2006 IEEE Symposium on Security and Privacy, IEEE, 2006, pp. 258–263.