源代码审查
概述
源代码审查是手动检查Web应用程序源代码以解决安全问题的过程。任何其他形式的分析或测试都无法检测到许多严重的安全漏洞。正如流行的说法“如果你想知道真正发生了什么，请直接找到源代码。”几乎所有安全专家都认为实际查看代码没有任何替代品。所有用于识别安全问题的信息都在代码在某处。与测试第三方封闭式软件（如操作系统）不同，在测试Web应用程序时（特别是如果它们是在内部开发的），源代码应该可用于测试目的。
许多无意但重要的安全问题也很难通过其他形式的分析或测试发现，例如渗透测试，使源代码分析成为技术测试的首选技术。使用源代码，测试人员可以准确地确定发生了什么（或者应该发生什么）并删除黑盒测试的猜测工作。
通过源代码审查特别有利于发现的问题示例包括并发问题，有缺陷的业务逻辑，访问控制问题，加密弱点以及后门，特洛伊木马，复活节彩蛋，定时炸弹，逻辑炸弹和其他形式的恶意码。这些问题通常表现为网站中最有害的漏洞。源代码分析也可以非常有效地查找实现问题，例如未执行输入验证的位置或可能存在失效打开控制过程的位置。但请记住，操作过程也需要进行审核，因为部署的源代码可能与此处分析的源代码不同[13]。
好处：
-
完整性和有效性
-
准确性
-
快速（适合有能力的评审员）
缺点：
-
需要高技能的安全开发人员
-
可能会错过编译库中的问题
-
无法轻松检测到运行时错误
-
实际部署的源代码可能与正在分析的源代码不同
渗透测试
概述
多年来，渗透测试一直是用于测试网络安全性的常用技术。它通常也被称为黑盒测试或道德黑客攻击。渗透测试本质上是远程测试正在运行的应用程序以查找安全漏洞的“艺术”，而不了解应用程序本身的内部工作原理。通常，渗透测试团队可以像访问用户一样访问应用程序。测试人员就像攻击者一样，试图查找和利用漏洞。在许多情况下，测试人员将获得系统上的有效帐户。
虽然渗透测试已被证明在网络安全性方面是有效的，但该技术并不能自然地转化为应用程序。在网络和操作系统上执行渗透测试时，大部分工作涉及查找并利用特定技术中的已知漏洞。由于Web应用程序几乎完全是定制的，因此Web应用程序领域的渗透测试更类似于纯粹的研究。已经开发了渗透测试工具来自动化该过程，但是由于Web应用程序的性质，它们的有效性通常很差。
今天许多人使用Web应用程序渗透测试作为其主要的安全测试技术。虽然它确实在测试程序中占有一席之地，但我们认为它不应被视为主要或唯一的测试技术。加里麦格劳[14]总结了渗透测试，他说，“如果你没有通过渗透测试，你知道你确实有一个非常糟糕的问题。如果你通过渗透测试，你不知道你没有一个非常糟糕的问题“。但是，有针对性的渗透测试（即尝试利用先前评论中检测到的已知漏洞的测试）可用于检测网站上部署的源代码中是否实际修复了某些特定漏洞。
好处：
-
可以快速（因此便宜）
-
需要比源代码审查相对较低的技能
-
测试实际暴露的代码
缺点：
-
在SDLC中太晚了
-
仅限正面碰撞测试。
平衡方法的必要性
由于有许多技术和方法来测试Web应用程序的安全性，因此很难理解使用哪种技术以及何时使用它们。经验表明，对于究竟应该使用哪种技术来构建测试框架的问题，没有正确或错误的答案。实际上，所有技术都应该用于测试所有需要测试的区域。
虽然很明显没有单一的技术可以有效地覆盖所有安全测试并确保所有问题都得到解决，但许多公司只采用了一种方法。历史上使用的方法是渗透测试。渗透测试虽然有用，但无法有效解决许多需要测试的问题。在软件开发生命周期（SDLC）中，它只是“太晚了”。
正确的方法是一种平衡的方法，包括从手动审查到技术测试的几种技术。平衡的方法应涵盖SDLC所有阶段的测试。该方法利用了最合适的技术，具体取决于当前的SDLC阶段。
当然，有时候和情况下只有一种技术是可能的。例如，对已创建的Web应用程序进行测试，但测试方无法访问源代码。在这种情况下，渗透测试显然比没有测试好。但是，应鼓励测试方质疑假设，例如无法访问源代码，并探索更完整测试的可能性。
平衡的方法取决于许多因素，例如测试过程的成熟度和企业文化。建议平衡测试框架应该类似于图3和图4中所示的表示。下图显示了覆盖软件开发生命周期的典型比例表示。为了与研究和经验保持一致，公司必须更加重视发展的早期阶段。