OWASP 测试指南 4.0-测试技术解释

          该部分提出可用于创建测试工程的各类高级测试技术。这里针对这些技术的具体实现方法并没有进行详细讨论，详情可参见后文。该部分旨在为下个后文所提出的测试框架提供上下文并突出某些技术在选择使用时应考虑的优点以及缺点。特别包括：
人工检查及复查
软件威胁建模
代码复查
渗透测试

0x01 人工检查及复查

      人工检查是安全测试过程中，通过人工检查或者审核的方式对应用开发过程中的人，策略和进程，包括技术决策如开发模型设计进行安全检测。人工检查通常采取文件分析或对设计师或系统的所有者进行访谈的方式进行。虽然人工检查和人员访谈这个概念十分简单，但是它们确是最强大的和有效的可用技术。通过询问别人这件事如何运行，为什幺采用当前的运行模式，能够帮助测试者快速确定是否存在显而易见的安全问题。人工检查及复查是在软件开发生命周期过程中对软件进行测试并确保其充分的策略和技能的为数不多的途径之一。正如生活中的许多事情，当进行人工检查及复查时，我们建议您通过信任但进行验证模式。并不是每个人告诉或展示给你的每件事都是准确的。人工检查对测试人员是否了解安全进程，是否了解安全策略，是否具有适合的技能以设计或执行一个安全的应用程序十分有用。其它包括文件，代码安全策略，安全要求，构架设计的检查都应该使用人工检查的方式来完成。

优点：

无需支持技术
可应用于各种不同的情况
灵活
促进团队协助
在软件开发生命周期早期

缺点：

可能会非常耗时
支持材料并不容易得到
需要大量的思考及技巧才能非常有效

 

0x02 软件威胁建模

        软件威胁建模已成为一种流行的技术，用以帮助系统设计师思考他们的系统/应用程序可能面临的安全威胁。因此，软件威胁建模可以被看作是应用风险评估。事实上，它能有效帮助设计师开发出缓解潜在的漏洞威胁的战略，并帮助他们将有限的资源和注意力集中在系统中最需要进行安全测试的部分。建议为所有的应用建立威胁模型并记录下来。威胁模型应与软件开发生命周期同步建立，并随着应用的演变和开发进程进行重新审视。我们建议采取NIST的800-30[11]标准的风险评估的办法来制定威胁模型。该方法包括：

分解应用程序——通过人工检查理解应用程序如何运作，它的资产，功能和连接。

界定和归类资产——将资产分为有形资产和无形资产并根据业务的重要性进行排名。
探索潜在的弱点——无论是技术上，运营上，或是管理。
探索潜在的威胁——通过使用威胁情景或攻击树，从攻击者的角度制定一个切合实际的潜在攻击矢量图。
建立迁移战略——为每一个可能演变成破坏的威胁制定迁移战略。
威胁模型本身的输入各有不同，但通常是清单和图表收集。OWASP代码审查指南简要指出，应用程序威胁建模可以用来
作为测试应用安全潜在漏洞的参考。选择创建应用威胁模型或者执行信息风险评估并没有正确错误之分[12]。

优点：

采用攻击者的思想对系统进行模拟攻击
灵活
软件开发生命周期早期

缺点：

相对新型的技术
良好的威胁模型并不意味着自动产生良好的软件

0x03 代码复查

        代码复查是手动检查的一个过程，它往往用于检查WEB应用程序中的源代码可能存在的安全问题。许多严重的安全漏洞不能被任何其它形式的分析或测试所检测到。有句俗话，“如果你想知道一件事是怎么产生的，请直接寻找其根源。”几乎所有的安全专家一致认为，没有任何检测方法可以取代代码审查。几乎所有信息安全问题都被证实为代码问题。与对源代码不开放的第三方软件，如操作系统进行测试不同，测试Web应用程序时（特别是如果他们已经完成内部定制）源代码应当可以获得。

        一些由于过失而导致的显着安全问题，通过其它形式的分析和测试，比如渗透测试是极其难以发现的，这也是在测试技术中源代码复查技术不可缺失的原因。测试者通过代码复查可以准确判断接下来将发生什幺事情（或应该发生），消除了黑盒测试中的猜测过程。源代码复查特别有利于发现以下安全问题：如并发的问题，有缺陷的业务逻辑，访问控制的问题，加密的弱点，后门，木马，复活节彩蛋，定时炸弹，逻辑炸弹，和其它形式的恶意代码。

         这些问题在网站中往往表现为最有害的漏洞。源代码分析对于查找可能存在的执行问题，比如某个需要输入验证的地方不能有效执行或打开控制进程失败是十分有效的。但是请记住，业务流程同样需要加以审查，因为真实运行环境中的源代码可能与此处已分析的源代码不一样

优点：

完整性和有效性
准确
快速(对具有高能力的复查者而言)

缺点：

需要高度熟练的安全开发者
可能错过存在于已编译好的类库中的问题
无法检测运行时产生的错误
真实运行环境中的源代码可能与此处已分析的源代码不一样
欲了解关于代码审查的更多信息，查询OWASP代码审查项目 

 

0x04 渗透测试

        渗透测试作为一个网络安全通用的测试技术已经多年。它也通常被称为黑盒测试或道德入侵(Ethical Hacking)。渗透测试在本质上是“艺术”，在不知道内部运作的应用程序本身的情况下，对正在运行的应用进行远程检测，发现安全漏洞。通常，渗透测试团队会假装成合法用户使用应用程序进行。测试者通过模拟攻击者的攻击手法，试图发现并利用安全漏洞。

         通常情况下，测试者将得到一个有效的系统帐户。对网络安全而言，渗透测试已被证明是一种非常有效的检测手段，然而该技术对应用而言却不是十分有效。当测试者对网络和操作系统进行渗透测试时，大多数的工作是寻找，然后采用具体技术对已知漏洞加以利用。Web应用程序几乎完全定制，对Web应用进行渗透测试更象是纯理论的研究。

         虽然已经开发出来自动化渗透测试工具，但是，针对Web应用程序的性质其效力通常很差。许多人今天使用Web应用程序渗透测试作为其主要的安全检测技术。虽然在测试过程中，其肯定占有一席之地，然而，我们不认为它应被看作是主要的或唯一的测试技术。Gary McGraw[14]对渗透测试进行了总结，他说：“如果一个渗透测试未通过，你知道你确实有一个非常不好的问题。如果你通过了渗透测试，你不知道你没有一个非常不好的问题”。然而，集中渗透测试（即试图利用之前检测发现的已知漏洞检测）可用于检测某些特定的安全漏洞，如部署在网站上的固定的源代码。

优点：

可以快速进行（因此便宜）
需要较低的技能，相对于源代码复查而言
测试实际曝露的代码(译注：即指实际运行的程序)

缺点：

软件开发生命周期晚期
仅仅测试前部影响!

 

 

0x05 方法平衡的需求

       针对WEB应用安全测试，有如此之多的技术及方法，了解何时选用哪一种技术进行测试非常困难。经验表明，选取哪一种技术用于建立测试框架并没有对错之分。事实上，所有的技术都应该被适当采用以确保所有需要测试的范围都已经被测试。

      但是，显而易见的是不存在某一种单一的技术可以覆盖安全测试的各个方面以确保所有的问题都已涉及到。在以往，许多公司都采取渗透测试这一种方法进行测试。虽然渗透测试在一定程度上具有可用性，但是不能涉及到所有需要测试的问题，并且对于软件开发生命周期而言，渗透测试过于简单和迟来。

      正确的做法是采取多种技术以达到平衡，包括人工检查和测试技术。方法平衡应确保在覆盖到软件开发生命周期的各个阶段。这种方法可以根据当前所在的软件开发生命周期的阶段平衡一种最合适的技术。

      当然，在某些时间或情况下，一种测试技术也是有可能的；例如，针对WEB应用所做的测试框架已经建立，但是测试团队无法获取WEB应用源代码。在这种情况下，渗透测试总好过不进行测试。然而，我们鼓励测试团队挑战假设，比如不能获取源代码时，探索其它更加全面的测试方法。

       平衡方式各不相同，这取决于许多因素，比如测试过程的成熟度和企业文化。尽管如此，我们建议采用图3和图4中展示的平衡框架。下图展示了测试技术在软件开发生命周期中一个典型的具有代表性的覆盖比例。随着研究的深入和经验的积累，公司对早期开发阶段的重视是非常重要的。

 

 

 

注：关于WEB应用扫描器

       许多组织或企业已经开始使用自动WEB应用扫描器。虽然他们对目前的测试计划毫无疑问，但是我们希望强调一些根问问题：为什么我们（从不）不信任自动化黑盒测试的有效性。通过强调这些问题，我们不鼓励使用WEB应用扫描器。另外，我们所说的其局限性应当被充分了解，同时应当建立适用的测试框架。

重要：OWASP目前在正致力于开发一个WEB应用安全扫描基准平台。下面的例子将表明为什么自动化黑盒测试并不奏效。

例 1: Magic 参数

        请想象一个简单的WEB应用程序，接受一个“magic”的名称，然后赋值。通常情况下，Get请求可能为：http://www.host/application?magic=value
       为了进一步简化以上举例，这个请求中的值只能是ASCII码a–z(大写或小写)以及整数0–9。该应用程序的设计者在测试期间建立了一个管理后门，同时对其进行混淆已避免被其它人发现。通过输入值sf8g7sfjdsurtsdieerwqredsgnfg8d (30个字符),用户就可以直接登陆并能够对该应用进行完全控制。HTTP请求如下:
http://www.host/application?magic= sf8g7sfjdsurtsdieerwqredsgnfg8d
        考虑到其它所有参数都是简单的2、3个字符，不可能开始猜测大约28个字符的组合。一个web应用扫描器将需要蛮力（或猜想）破解整整30个字符的关键空间。高达30^28种排列，或万亿HTTP请求！这是一个在电子数字中大海捞针！这个典范magic参数代码检查可能看起来如下所示：
publicvoiddoPost( HttpServletRequest request, HttpServletResponse response){ String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”; boolean admin = magic.equals( request.getParameter(“magic”)); if (admin) doAdmin( request, response); else …. // normal processing }
通过查看代码，该弱点事实上导致该页面存在潜在问题。

例 2: 无效加密

       密码学广泛应用于Web应用程序。可以想象，开发人员决定采用一种简单的密码学算法来对用户从站点A到站点B进行自动认证。开发人员以其聪明才智决定，如果用户登陆到站点A，他或她将产生一个采用MD5散列(Hash)函数进行加密的钥匙，其内容包括： Hash { username : date }当用户通过站点B，他或她将该钥匙以询问字符串的形式通过HTTP复位向发往站点B。站点B通过独立计算Hash值，并且对请求通过的Hash值进行比较。如果他们匹配，站点B则声称该用户是其标志用户。

          我们可以清楚看到，像我们解释的那样，该计算可能执行失败或者被其它人看见它是如何计算的(或被告诉知它是如何运作的，或者从Bugtraq可直接下载相关信息)，从而可能作为其合法用户进行登录。通过对代码进行手工检查，例如访谈，将迅速揭露这类安全问题。黑盒Web应用程序扫描器可能认识到不同的用户的hash值采用自然的方式在改变，但是并不能预测其改变的方式。

注：关于静态源代码复查工具

        许多组织或企业开始使用静态源代码扫描器。毋庸置疑，综合测试一个应用程序时，其具有一定的有效性，然而，我们想要突出的根本问题是，当单独时使用该类工具时，为什么我们并不相信这种方法的有效性。静态源代码分析在设计不可能辨认问题由于缺点，因为它不可能了解所开发代码的上下文。源代码分析工具是在确定由于编码错误而导致安全性问题有用的，然而重大手工努力需要确认研究结果。

 

欢迎大家分享更好的思路，热切期待^^_^^ !