静态代码审查方法

信息安全 Web应用程序 代码审查 二进制代码 静态分析
2021-08-26 18:07:58

我的问题与 Veracode vs Fortify/AppScan 使用的静态代码分析方法有关。

  1. Veracode – 无需源代码即可发现应用程序二进制文件和字节码中的安全漏洞
  2. Fortify/AppScan - 分析实际源代码以识别安全漏洞。

A) 对源代码进行二进制审查是否有优势/劣势?B)哪一个提供更多的覆盖/漏洞。C)任何例子都会很棒。

谢谢,

4个回答

A) 对源代码进行二进制审查是否有优势/劣势?

编译器通常不会按照源代码中的意图明确编写代码。例如,面向返回的编程利用了编译器将插入RET比程序员意识到的更多的操作码这一事实。由于流水线和其他优化技巧,编译器本质上会重写您的代码,并且可能会添加自己的漏洞。 这意味着源代码中的某些结构可能根本没有用二进制表示!

这是一类基本上无法通过手动代码分析捕获的错误......我怀疑 Java/C# JIT 代码的风险仍然存在,但这会被静态分析工具混淆。

手动源代码分析可以通过目视检查发现常见的漏洞这一事实有所帮助而且它还有其他好处,最显着的只是减少了一般产品错误的数量。(因此成本。)它也有助于社交方面:来源评论鼓励人们写作,就好像其他人正在观看一样。主要缺点是,如果你正在处理一个动态类型语言,如PERL,Groovy中,LISP和其衍生品的大多数数据将无法在运行时之前该装置看起来既不静态分析或源代码分析就足够了.

您甚至可以通过在运行时将静态类型代码转换为指令来欺骗静态分析工具。Veracode 不喜欢您的 java 构造?使用反射重写它,Veracode 错误消失了,没有人比它更聪明。作为安全专家,您还需要假设在您自己公司工作的程序员是潜在威胁。

所以简而言之,如果您希望是一个可以接受的安全代码库,那么在任何给定的应用程序中都没有办法逃避源代码分析、静态分析和动态分析。*

B)哪一个提供更多的覆盖/漏洞。

源代码分析依赖于具有出色安全技能的审阅者,并且由于他们是人类,因此您不能合理地期望完美的性能。这就是静态分析工具派上用场的原因。我的偏好是先运行静态分析工具,然后在发现缓解进行安全代码审查,我更喜欢使用 STRIDE,但还有其他框架需要考虑。这使人们可以专注于与逻辑相关的不那么平凡的安全问题。但是一个聪明的人会在一周中的任何一天击败一个愚蠢的静态分析工具。

源代码分析可以帮助您找到程序员留下后门的地方......静态分析工具无法处理这个问题。

所以这个问题的答案是……“这取决于。” 您希望对哪些威胁置之不理?

*除非“可以接受的安全”被定义为保持窗户打开且前门未上锁。

一个人可以写关于这些事情的书,但永远不会满足。让我试着笼统地回答这个问题,而不用命名特殊产品。

二进制/字节码分析

好处

  • (主要)与编程语言无关
  • 可以在您从任何地方获得的封闭源代码二进制文件/库上运行
  • 可以发现由于编译器错误(或源语言的未定义行为)而引入的缺陷

缺点

  • 由于快速发展的硬件(例如可能还不了解英特尔 AVX),通常更难编写/维护
  • 仅限于某些架构(实际上很少出现问题,因为大多数东西都在 x86/x86_64 上运行)
  • 多线程同步结构很难被检测到,如果有的话。

源码分析

好处

  • 通常更容易将发现的缺陷追溯到实际源代码
  • 通常允许工具查看事物如何更好地协同工作的“更大图景”(例如,在此处分配的事物,在此处释放的事物,在此处释放后读取的可能性)
  • 提供语义更高级别的分析(例如,某些计算中的整数溢出,在汇编级别是难以理解的移位和添加混乱)
  • 源代码注释可以帮助工具理解正在发生的事情(例如“相信我,这是一个同步原语,因此以下是原子的,无需担心竞争条件”)

缺点

  • 源代码必须可用
  • 可能不完全支持所有语言(例如 C++ 模板元编程结构)
  • 可能无法准确模拟稍后将运行的机器的属性(例如整数大小等)
  • 不会下降到可能仅作为二进制文件可用或在不同系统上不同的库依赖项。

覆盖水平

这主要与工具的操作方式正交,主要是衡量该产品的质量。只要付出足够的努力,所有工具都可以对各种漏洞进行所有检查,但没有人拥有足够的人力。容易做的事情会做;那些很难做到的,可能永远不会实现。

您可以拥有两个专注于完全不同事物的源代码分析工具(例如,一个针对竞争条件,另一个针对溢出)。我确信这些工具之间总是有一些重叠,但没有两个工具能找到完全相同的缺陷。

如果你有可能,尽可能多地运行这些,你永远不知道你是否在某个地方有一个只能通过你还没有运行的工具之一找到的错误......

简短的回答是同时使用它们。混合或集成应用程序安全测试 (IAST) 将二进制文件和字节码的动态应用程序安全测试 (DAST) 与静态应用程序安全测试 (SAST) 相结合,以创建应用程序漏洞的统一视图。目标不仅仅是发现漏洞,还帮助开发人员快速识别、解释和修复这些错误。混合工具超越了 DAST,使用静态分析指向特定的源代码行并扩展工具的覆盖范围。此外,IAST 工具通过对 SAST 发现的实时测试来减少误报——软件开发人员的祸根。IAST 可以利用 SAST 和 DAST 方法的优势,并抵消各自固有的弱点。例如,SQL 注入的动态测试可以确认攻击确实进入了数据库。IAST 通过检查代码以缩小攻击面来加速测试;如果页面不执行任何 SQL,则无需测试页面是否进行 SQL 注入。IAST 可以使用 SAST 来发现代码中可能隐藏在动态测试方法中的攻击面。

IAST 工具的示例包括 Aspect 的 Contrast、Quotium Technologies 的 Seeker、IBM 的 Appscan Enterprise、Acunetix Web Vulnerability Scanner 和 HP WebInspect Real-Time。请参阅 Jeff Williams 的博客文章Why static application security scanners just can't cut it again See the similar question Effectiveness of Interactive Application Security Testing

A) 对源代码进行二进制审查是否有优势/劣势?

我通常“反编译/反汇编”二进制文件并查看它们而不是源代码。有时我什至无法访问源代码。可能有不同的“分支”,甚至源代码永远不会在编译的二进制文件中出现(死代码)。

B)哪一个提供更多的覆盖/漏洞。 源代码有提示,例如 //TODO 和注释,如果需要实施/有弱点,可以提供帮助。二进制文件没有。两者都有优点。