owasp 测试指南 机翻阅读

OWASP测试项目
OWASP测试项目已经开发多年。该项目的目的是帮助人们了解测试Web应用程序的内容，原因，时间，地点和方式。该项目提供了一个完整的测试框架，而不仅仅是一个简单的清单或处理应解决的问题。读者可以使用此框架作为模板来构建自己的测试程序或限定其他人的流程。测试指南详细描述了一般测试框架和在实践中实现框架所需的技术。

编写测试指南已被证明是一项艰巨的任务。获得共识和开发允许人们应用指南中描述的概念的内容是一项挑战，同时也使他们能够在自己的环境和文化中工作。将Web应用程序测试的重点从渗透测试转变为集成在软件开发生命周期中的测试也是一项挑战。

但是，该小组对该项目的成果非常满意。许多行业专家和安全专业人员（其中一些人负责世界上一些大公司的软件安全性）正在验证测试框架。该框架可帮助组织测试其Web应用程序，以构建可靠且安全的软件。该框架并不仅仅强调弱点，尽管后者肯定是许多OWASP指南和清单的副产品。因此，必须就某些测试技术和技术的适当性作出艰难的决定。该小组完全理解并非所有人都同意所有这些决定。然而，OWASP能够通过基于共识和经验的意识和教育，在一段时间内占据制高点并改变文化。

本指南的其余部分组织如下：本简介介绍了测试Web应用程序的先决条件和测试范围。它还涵盖了成功测试和测试技术的原则。第3章介绍了OWASP测试框架，并解释了与软件开发生命周期各个阶段相关的技术和任务。第4章介绍了如何通过代码检查和渗透测试来测试特定漏洞（例如，SQL注入）。

测量安全性：不安全软件的经济学
软件工程的基本原则是你无法控制你无法衡量的东西[1]。安全测试也不例外。不幸的是，衡量安全性是一个非常困难的过程。这里不会详细介绍这个主题，因为它本身需要一个指南（有关介绍，请参阅[2]）。

应该强调的一个方面是安全性测量涉及特定的技术问题（例如，某个漏洞的普遍程度）以及这些问题如何影响软件的经济性。大多数技术人员至少会理解基本问题，或者他们可能对漏洞有更深入的了解。遗憾的是，很少有人能够将这些技术知识转化为货币术语，并量化应用程序所有者业务漏洞的潜在成本。在此之前，CIO将无法获得准确的安全投资回报，并随后为软件安全性分配适当的预算。
虽然估算不安全软件的成本可能看起来是一项艰巨的任务，但在这方面已经做了大量工作。例如，2002年6月，由于软件测试不充分，美国国家标准学会（NIST）发布了一项关于不安全软件对美国经济成本的调查[3]。有趣的是，他们估计更好的测试基础设施可以节省超过三分之一的成本，或每年约220亿美元。最近，学术研究人员研究了经济学与安全性之间的联系。有关这些工作的更多信息，请参见[4]。

本文档中描述的框架鼓励人们在整个开发过程中测量安全性。然后，他们可以将不安全软件的成本与其对业务的影响联系起来，从而开发适当的业务流程并分配资源来管理风险。请记住，测量和测试Web应用程序比其他软件更重要，因为Web应用程序通过Internet向数百万用户公开。

什么是测试？
在Web应用程序的开发生命周期中，需要测试许多东西，但测试实际上意味着什么？Merriam-Webster字典将测试描述为：

进行测试或证明。
进行测试。
根据测试分配站立或评估。
出于本文档的目的，测试是将系统或应用程序的状态与一组标准进行比较的过程。在安全行业中，人们经常测试一组既不明确也不完整的心理标准。因此，许多外人将安全测试视为一种黑色艺术。本文档的目的是改变这种看法，并使没有深入安全知识的人更容易在测试中发挥作用。

为何进行测试？
本文档旨在帮助组织了解测试程序的内容，并帮助他们确定在Web应用程序上构建和运行测试程序所需采取的步骤。该指南提供了制作全面的Web应用程序安全程序所需元素的广泛视图。本指南可用作参考指南和方法，以帮助确定现有实践与行业最佳实践之间的差距。本指南允许组织与业界同行进行比较，了解测试和维护软件所需的资源量，或准备审计。本章不涉及如何测试应用程序的技术细节，因为其目的是提供典型的安全组织框架。

什么时候测试？
今天的大多数人都不会测试软件，直到它已经被创建并处于其生命周期的部署阶段（即，代码已经创建并实例化为工作的Web应用程序）。这通常是一种非常无效且成本过高的做法。防止安全漏洞出现在生产应用程序中的最佳方法之一是通过在每个阶段中包含安全性来改进软件开发生命周期（SDLC）。SDLC是强加于软件文物开发的结构。如果您的环境中当前没有使用SDLC，那么现在是时候选择一个！下图显示了通用SDLC模型以及在此类模型中修复安全漏洞的（估计）增加的成本。

SDLC.jpg
图1：通用SDLC模型
公司应检查其整体SDLC，以确保安全性是开发过程中不可或缺的一部分。SDLC应包括安全测试，以确保充分覆盖安全性，并且控制在整个开发过程中都是有效的。

测试什么？
将软件开发视为人员，流程和技术的组合可能会有所帮助。如果这些是“创建”软件的因素，那么这些是必须测试的因素是合乎逻辑的。今天，大多数人通常会测试技术或软件本身。

一个有效的测试程序应该有测试的组件：
人 - 确保有足够的教育和意识;
流程 - 确保有足够的政策和标准，人们知道如何遵守这些政策;
* 技术 - 确保该过程在实施过程中有效。
除非采用整体方法，否则仅测试应用程序的技术实现不会发现可能存在的管理或操作漏洞。通过测试人员，策略和流程，组织可以捕获稍后会表现为技术缺陷的问题，从而及早消除错误并确定缺陷的根本原因。同样，仅测试系统中可能存在的一些技术问题将导致不完整且不准确的安全状态评估。

Fidelity National Financial信息安全主管Denis Verdon 在纽约举行的OWASP AppSec 2004大会上对这种误解提出了一个很好的比喻[5]：“如果汽车像应用程序一样构建，安全测试只会产生正面影响汽车不会进行滚动测试，也不会在紧急操作，制动效果，侧面碰撞和防盗性方面进行稳定性测试。“
反馈和意见
与所有OWASP项目一样，我们欢迎提出意见和反馈。我们特别想知道我们的工作正在被使用，并且它是有效和准确的。

测试原理
在开发测试方法以发现软件中的安全漏洞时，存在一些常见的误解。本章介绍了专业人员在对软件执行安全测试时应考虑的一些基本原则。

没有银色子弹
虽然很容易认为安全扫描器或应用程序防火墙会提供许多防御攻击或识别大量问题，但实际上对于不安全的软件问题没有灵丹妙药。应用安全评估软件虽然可用作寻找低调成果的第一步，但在深入评估或提供足够的测试覆盖率方面通常是不成熟和无效的。请记住，安全是一个过程，而不是一个产品。

战略性而非战术性思考
在过去几年中，安全专业人员已经意识到在1990年代信息安全中普遍存在的补丁和渗透模型的谬误。补丁和渗透模型涉及修复报告的错误，但没有对根本原因进行适当的调查。此模型通常与下图所示的漏洞窗口相关联。全球使用的通用软件中漏洞的演变表明该模型的无效性。有关漏洞窗口的更多信息，请参阅[6]。

漏洞研究[7]表明，随着全球攻击者的反应时间，典型的漏洞窗口无法为补丁安装提供足够的时间，因为漏洞被发现与对其开发和释放的自动攻击之间的时间正在减少每年。

在补丁和穿透模型中有几个不正确的假设。许多用户认为补丁会干扰正常操作，并可能破坏现有应用程序。假设所有用户都知道新发布的补丁也是错误的。因此，产品的所有用户都不会应用修补程序，因为他们认为修补可能会干扰软件的工作方式，或者因为他们缺乏有关修补程序存在的知识。

WindowExposure.jpg
图2：漏洞窗口

必须在软件开发生命周期（SDLC）中构建安全性，以防止应用程序中出现重复出现的安全问题。开发人员可以通过制定适合并在开发方法中工作的标准，策略和指南，为SDLC建立安全性。应该使用威胁建模和其他技术来帮助为最危险的系统部分分配适当的资源。
SDLC是王者
SDLC是一个为开发人员所熟知的过程。通过将安全性集成到SDLC的每个阶段，它允许采用整体的应用程序安全方法，利用组织内部已有的程序。请注意，虽然各个阶段的名称可能会根据组织使用的SDLC模型而发生变化，但原型SDLC的每个概念阶段都将用于开发应用程序（即定义，设计，开发，部署，维护）。每个阶段都有安全考虑因素，应该成为现有流程的一部分，以确保具有成本效益和全面的安全计划。

存在几个安全的SDLC框架，它们提供描述性和规范性建议。一个人是否采取描述性或规范性建议取决于SDLC流程的成熟度。从本质上讲，规范性建议显示了安全SDLC应该如何工作，描述性建议显示了它在现实世界中的使用方式。两者都有自己的位置。例如，如果您不知道从哪里开始，则说明性框架可以提供可在SDLC中应用的潜在安全控制菜单。然后，描述性建议可以通过展示对其他组织有效的方法来帮助推动决策过程。描述性安全SDLC包括BSIMM-V; 规范性安全SDLC包含OWASP的开放软件保障成熟度模型（OpenSAMM）和ISO / IEC 27034第1-8部分，
早期测试和经常测试
当在SDLC早期检测到错误时，可以更快地以更低的成本解决问题。在这方面，安全性错误与功能性或基于性能的错误没有什么不同。实现这一目标的关键步骤是向开发和QA团队介绍常见的安全问题以及检测和预防这些问题的方法。虽然新的库，工具或语言可以帮助设计更好的程序（安全漏洞更少），但新的威胁不断出现，开发人员必须意识到影响他们正在开发的软件的威胁。安全测试教育还可以帮助开发人员从攻击者的角度获得适当的思维模式来测试应用程序。这允许每个组织将安全问题视为其现有职责的一部分。
了解安全范围了解
给定项目需要多少安全性非常重要。应该给予要保护的信息和资产一个分类，说明如何处理它们（例如，机密，秘密，绝密）。应与法律委员会进行讨论，以确保满足任何特定的安全要求。在美国，要求可能来自联邦法规，如Gramm-Leach-Bliley法案[8]，或州法律，如加州SB-1386 [9]。对于位于欧盟国家/地区的组织，可能适用特定国家/地区的法规和欧盟指令。例如，指令96/46 / EC4 [10]规定，无论何种应用，都必须谨慎对待应用程序中的个人数据。
培养正确的心态
成功测试应用程序的安全漏洞需要“开箱即用”。正常用例将在用户以预期方式使用应用程序时测试应用程序的正常行为。良好的安全性测试需要超出预期，并且像攻击者一样试图破解应用程序。创造性思维可以帮助确定哪些意外数据可能导致应用程序以不安全的方式失败。它还可以帮助发现Web开发人员所做的假设并不总是正确的以及如何将其颠覆。
理解主题
任何良好的安全计划中的第一个主要计划之一应该是要求准确记录应用程序。架构，数据流图，用例等应该写在正式文档中并提供给我们审查。技术规范和应用程序文档应包括不仅列出所需用例，而且还列出任何特定不允许的用例的信息。最后，最好至少拥有一个基本的安全基础设施，允许监控和趋势对组织的应用程序和网络（例如，IDS系统）的攻击。
使用正确的工具
虽然我们已经说过没有银弹工具，但工具确实在整个安全计划中起着关键作用。有一系列开源和商业工具可以自动执行许多常规安全任务。这些工具可以通过协助安全人员完成任务来简化和加快安全过程。但是，重要的是要准确理解这些工具能够做什么和不能做什么，以便它们不会被超卖或错误地使用。
细节决定成败
至关重要的是，不要对应用程序进行表面的安全审查，并认为它是完整的。这将灌输一种虚假的信心感，这种信心可能与没有首先进行安全审查一样危险。仔细审查调查结果并清除报告中可能存在的任何误报至关重要。报告不正确的安全性查找通常会破坏安全报告其余部分的有效消息。应该注意验证应用程序逻辑的每个可能部分都已经过测试，并且针对可能的漏洞探索了每个用例场景。
使用源代码时可用
虽然黑盒渗透测试结果可以令人印象深刻并且有助于演示生产环境中漏洞的暴露程度，但它们并不是保护应用程序最有效或最有效的方法。动态测试很难测试整个代码库，特别是在存在许多嵌套条件语句的情况下。如果应用程序的源代码可用，则应在安全人员执行审查时向他们提供帮助。可以发现应用程序源中的漏洞，这些漏洞在黑匣子参与期间会被遗漏。
制定指标
良好的安全计划的一个重要部分是能够确定事情是否变得更好。跟踪测试约定的结果非常重要，并开发能够揭示组织内应用程序安全趋势的指标。

好的指标将显示：
如果需要更多的教育和培训;
如果开发团队没有明确理解特定的安全机制;
如果每个月发现的安全相关问题总数正在下降。
可以从可用源代码以自动方式生成的一致度量标准还将有助于组织评估为减少软件开发中的安全性错误而引入的机制的有效性。度量标准不易开发，因此使用OWASP Metrics项目和其他组织提供的标准度量标准是一个很好的起点。
记录测试结果
为了完成测试过程，重要的是要生成正式的记录，记录测试操作采取的操作，执行人员，执行时间以及测试结果的详细信息。明智的做法是就报告的可接受格式达成一致，这对所有相关方都有用，可能包括开发人员，项目管理，业务所有者，IT部门，审计和合规性。

业务所有者应明确报告，确定存在重大风险的位置，并足以获得后续缓解措施的支持。开发人员还应清楚地向开发人员说明受漏洞影响的确切功能以及解决开发人员将理解的语言问题的相关建议。该报告还应允许其他安全测试人员重现结果。编写报告不应该对安全测试人员本身过于繁琐。安全测试人员通常不会因其创造性写作技能而闻名，并且就复杂报告达成一致可能会导致测试结果无法正确记录的情况。使用安全测试报告模板可以节省时间并确保准确一致地记录结果，

测试技术解释
本节概述了构建测试程序时可以采用的各种测试技术。它没有提供这些技术的具体方法，因为第3章介绍了这些信息。本节包含在内，为下一章提出的框架提供背景，并强调应考虑的一些技术的优缺点。特别是，我们将涵盖：

手动检查和评论
威胁建模
代码审查
渗透测试
手动检查和评论
概述
手动检查是人工审核，通常用于测试人员，策略和流程的安全隐患。手动检查还可以包括检查技术决策，例如建筑设计。它们通常通过分析文档或与设计人员或系统所有者进行访谈来进行。

虽然手动检查和人工审查的概念很简单，但它们可以是最有效和最有效的技术之一。通过询问某人如何工作以及为何以特定方式实施，测试人​​员可以快速确定是否有任何安全问题可能是明显的。手动检查和审查是测试软件开发生命周期过程本身的几种方法之一，并确保有适当的策略或技能组合。

与生活中的许多事情一样，在进行人工检查和审查时，建议采用信任 - 验证模型。并非所有显示或告知测试仪的都是准确的。手动审核特别适用于测试人们是否了解安全流程，了解策略以及是否具备设计或实施安全应用程序的适当技能。

其他活动，包括手动审阅文档，安全编码策略，安全要求和架构设计，都应使用人工检查完成。

优点：

不需要支持技术
可以应用于各种情况
灵活
促进团队合作
早在SDLC
缺点：

可能很费时间
支持材料并非始终可用
需要重要的人类思想和技能才能有效
威胁建模
概述
威胁建模已成为一种流行的技术，可帮助系统设计人员考虑其系统和应用程序可能面临的安全威胁。因此，威胁建模可视为应用程序的风险评估。事实上，它使设计人员能够针对潜在漏洞制定缓解策略，并帮助他们将不可避免的有限资源和注意力集中在最需要它的系统部分上。建议所有应用程序都开发并记录威胁模型。威胁模型应尽早在SDLC中创建，并应随着应用程序的发展和开发的进展而重新审视。

为了开发威胁模型，我们建议采用遵循NIST 800-30 [11]风险评估标准的简单方法。这种方法涉及：

分解应用程序 - 使用手动检查过程来了解应用程序的工作方式，资产，功能和连接性。
对资产进行定义和分类 - 将资产分类为有形和无形资产，并根据业务重要性对其进行排名。
探索潜在的漏洞 - 无论是技术，运营还是管理。
探索潜在威胁 - 通过使用威胁场景或攻击树，从攻击者的角度展望潜在攻击媒介的真实视图。
制定缓解策略 - 针对每种被认为切合实际的威胁制定缓解控制措施。
威胁模型本身的输出可能会有所不同，但通常是列表和图表的集合。OWASP代码审查指南概述了应用程序威胁建模方法，该方法可用作测试应用程序的参考，以应对应用程序设计中的潜在安全漏洞。没有正确或错误的方法来开发威胁模型并对应用程序进行信息风险评估。[12]。
优点：

实用的攻击者对系统的看法
灵活
早在SDLC
缺点：

相对较新的技术
好的威胁模型不会自动意味着良好的软件
源代码审查
概述
源代码审查是手动检查Web应用程序源代码以解决安全问题的过程。任何其他形式的分析或测试都无法检测到许多严重的安全漏洞。正如流行的说法“如果你想知道真正发生了什么，请直接找到源代码。”几乎所有的安全专家都认为实际查看代码是无可替代的。所有用于识别安全问题的信息都在代码在某处。与测试第三方封闭式软件（如操作系统）不同，在测试Web应用程序时（特别是如果它们是内部开发的），源代码应该可用于测试目的。

许多无意但重要的安全问题也很难通过其他形式的分析或测试发现，例如渗透测试，使源代码分析成为技术测试的首选技术。使用源代码，测试人员可以准确地确定发生了什么（或应该发生什么），并删除黑盒测试的猜测工作。

特别有助于通过源代码审查发现的问题示例包括并发问题，有缺陷的业务逻辑，访问控制问题，加密弱点以及后门程序，特洛伊木马，复活节彩蛋，定时炸弹，逻辑炸弹和其他形式的恶意码。这些问题通常表现为网站中最有害的漏洞。源代码分析也可以非常有效地查找实现问题，例如未执行输入验证的位置或可能存在失效打开控制过程的位置。但请记住，操作过程也需要进行检查，因为部署的源代码可能与此处分析的源代码不同[13]。
优点：

完整性和有效性
准确性
快速（适合评审员）
缺点：

需要高技能的安全开发人员
可能会错过编译库中的问题
无法轻松检测到运行时错误
实际部署的源代码可能与正在分析的源代码不同
有关代码审查的更多信息，请查看OWASP代码审查项目。
渗透测试
概述
多年来，渗透测试一直是用于测试网络安全性的常用技术。它通常也称为黑盒测试或道德黑客攻击。渗透测试本质上是远程测试正在运行的应用程序以查找安全漏洞的“艺术”，而不了解应用程序本身的内部工作原理。通常，渗透测试团队可以像访问用户一样访问应用程序。测试人员就像攻击者一样，试图查找和利用漏洞。在许多情况下，测试人员将获得系统上的有效帐户。

虽然渗透测试已证明在网络安全性方面很有效，但该技术并不能自然地转化为应用程序。在网络和操作系统上执行渗透测试时，大部分工作涉及查找并利用特定技术中的已知漏洞。由于Web应用程序几乎完全是定制的，因此Web应用程序领域的渗透测试更类似于纯粹的研究。已经开发了渗透测试工具来自动化该过程，但是由于Web应用程序的性质，它们的有效性通常很差。

今天许多人使用Web应用程序渗透测试作为其主要的安全测试技术。虽然它确实在测试程序中占有一席之地，但我们认为它不应被视为主要或唯一的测试技术。加里麦格劳在[14]中总结了渗透测试，他说：“如果你没有通过渗透测试，你知道你确实有一个非常糟糕的问题。如果你通过渗透测试，你不知道你没有一个非常糟糕的问题“。但是，重点渗透测试（即，尝试利用先前评论中检测到的已知漏洞的测试）可用于检测网站上部署的源代码中是否实际修复了某些特定漏洞。
优点：

可以快（因此便宜）
需要比源代码审查相对较低的技能
测试实际暴露的代码
缺点：

在SDLC中太晚了
仅限正面碰撞测试。
平衡方法的必要性
由于有许多技术和方法来测试Web应用程序的安全性，因此很难理解使用哪种技术以及何时使用它们。经验表明，对于究竟应该使用哪种技术来构建测试框架的问题，没有正确或错误的答案。事实上，所有技术都应该用于测试所有需要测试的区域。

虽然很明显没有单一的技术可以有效地覆盖所有安全测试并确保所有问题都得到解决，但许多公司只采用了一种方法。历史上使用的方法是渗透测试。渗透测试虽然有用，但无法有效解决许多需要测试的问题。在软件开发生命周期（SDLC）中，它只是“太晚了”。

正确的方法是一种平衡的方法，包括从手动审查到技术测试的几种技术。平衡的方法应涵盖SDLC所有阶段的测试。这种方法利用了最合适的技术，具体取决于当前的SDLC阶段。

当然，有时候只有一种技术可行。例如，对已创建的Web应用程序进行测试，但测试方无法访问源代码。在这种情况下，渗透测试显然比没有测试好。但是，应鼓励测试方质疑假设，例如无法访问源代码，并探索更完整测试的可能性。

平衡的方法取决于许多因素，例如测试过程的成熟度和企业文化。建议平衡测试框架看起来应该类似于图3和图4中所示的表示。下图显示了覆盖软件开发生命周期的典型比例表示。为了与研究和经验保持一致，公司必须更加重视发展的早期阶段。

ProportionSDLC.png
图3：SDLC中测试工作的比例

下图显示了覆盖在测试技术上的典型比例表示。
ProportionTest.png
图4：根据测试技术的测试努力比例

关于Web应用程序扫描程序的注意事项
许多组织已开始使用自动Web应用程序扫描程序。虽然他们无疑在测试计划中占有一席之地，但需要强调一些基本问题，即为什么认为自动化黑盒测试不会（或将永远）有效。但是，突出显示这些问题不应该阻止使用Web应用程序扫描程序。相反，目的是确保理解限制并适当规划测试框架。

重要提示：OWASP目前正致力于开发Web应用程序扫描仪基准测试平台。以下示例显示了自动黑盒测试无效的原因。
’ 示例1：魔术参数’
想象一个简单的Web应用程序，它接受一个名为“magic”的值对，然后是值。为简单起见，GET请求可能是：http ：//www.host/application？
magic = value为了进一步简化示例，在这种情况下，值只能是ASCII字符a - z（大写或小写）和整数0 - 9。

该应用程序的设计者在测试期间创建了一个管理后门程序，但对其进行了模糊处理，以防止偶然的观察者发现它。通过提交值sf8g7sfjdsurtsdieerwqredsgnfg8d（30个字符），用户将登录并显示一个完全控制应用程序的管理屏幕。HTTP请求现在是：http：
//www.host/application？magic = sf8g7sfjdsurtsdieerwqredsgnfg8d
鉴于所有其他参数都是简单的双字符和三字符字段，因此无法以大约28个字符开始猜测组合。Web应用程序扫描程序需要强制（或猜测）30个字符的整个密钥空间。这是多达30 ^ 28个排列，或数万亿的HTTP请求。那是数字干草堆中的电子。

此示例Magic Parameter检查的代码可能如下所示：
public void doPost（HttpServletRequest request，HttpServletResponse response）
{
String magic =“sf8g7sfjdsurtsdieerwqredsgnfg8d”;
boolean admin = magic.equals（request.getParameter（“magic”））;
if（admin）doAdmin（request，response）;
别的…. //正常处理
}
通过查看代码，漏洞几乎从页面上跳了出来，成为一个潜在的问题。
示例2：错误密码术
密码术广泛用于Web应用程序。想象一下，开发人员决定编写一个简单的加密算法来自动地将用户从站点A签名到站点B. 根据他/她的智慧，开发人员决定如果用户登录到站点A，那么他/她将使用MD5哈希函数生成密钥，该函数包括：哈希{username：date}
当用户被传递到站点B时，他/她将在HTTP重定向中将查询字符串上的密钥发送到站点B. 站点B独立计算哈希值，并将其与请求中传递的哈希值进行比较。如果它们匹配，则站点B以他们声称的用户身份登录用户。

随着该计划的解释，可以解决不足之处。任何计算出该计划（或被告知如何运作，或从Bugtraq下载信息）的人都可以以任何用户身份登录。手动检查（例如审查或代码检查）可以快速发现此安全问题。黑盒Web应用程序扫描程序无法发现此漏洞。它会看到每个用户改变的128位散列，并且由于散列函数的性质，没有以任何可预测的方式改变。
关于静态源代码审查工具的注意事项
许多组织已经开始使用静态源代码扫描程序。虽然他们无疑在综合测试计划中占有一席之地，但有必要强调一些基本问题，即为什么这种方法在单独使用时无效。单独的静态源代码分析无法识别由于设计中的缺陷导致的问题，因为它无法理解构造代码的上下文。源代码分析工具可用于确定由编码错误引起的安全问题，但需要大量的手动工作来验证结果。
获得安全测试要求
要获得成功的测试程序，必须知道测试目标是什么。这些目标由安全要求指定。本节详细讨论了如何通过从适用的标准和法规以及正面和负面的应用程序要求中获取安全测试的要求来记录这些要求。它还讨论了安全要求如何在SDLC期间有效推动安全测试，以及如何使用安全测试数据来有效管理软件安全风险。

测试目标
安全测试的目标之一是验证安全控制是否按预期运行。这通过描述安全控件功能的安全要求进行记录。从较高的层面来说，这意味着要证明数据和服务的机密性，完整性和可用性。另一个目标是验证安全控制是在很少或没有漏洞的情况下实现的。这些是常见的漏洞，例如OWASP Top Ten，以及之前在SDLC期间通过安全评估确定的漏洞，例如威胁建模，源代码分析和渗透测试。

安全要求文档安全要求文档
的第一步是了解业务要求。业务需求文档可以提供有关应用程序的预期功能的初始高级信息。例如，应用程序的主要目的可能是向客户提供金融服务或允许从在线目录中购买商品。业务要求的安全部分应强调保护客户数据以及遵守适用的安全文档（如法规，标准和策略）的必要性。

适用法规，标准和策略的一般清单是Web应用程序的良好初步安全合规性分析。例如，可以通过检查有关业务部门以及应用程序运行所在的国家或州的信息来识别合规性法规。其中一些合规性指南和法规可能转化为安全控制的特定技术要求。例如，在财务应用程序的情况下，遵守FFIEC认证准则[15]要求金融机构通过多层安全控制和多因素身份验证来实施缓解弱认证风险的应用程序。

一般安全要求检查表也需要捕获适用的安全行业标准。例如，对于处理客户信用卡数据的应用程序，符合PCI DSS [16]标准禁止存储PIN和CVV2数据，并要求商家通过加密保护存储和传输中的磁条数据。通过掩蔽显示。可以通过源代码分析验证此类PCI DSS安全要求。

清单的另一部分需要强制执行符合组织信息安全标准和策略的一般要求。从功能需求的角度来看，安全控制的要求需要映射到信息安全标准的特定部分。此类要求的一个示例可能是：“必须由应用程序使用的身份验证控件强制执行六个字母数字字符的密码复杂性。” 当安全要求映射到合规性规则时，安全性测试可以验证合规性风险的暴露程度。如果发现违反信息安全标准和政策，则会导致风险，可以记录并且业务必须管理。由于这些安全合规性要求是可执行的，

安全要求验证
从功能角度来看，安全性要求的验证是安全性测试的主要目标。从风险管理的角度来看，安全要求的验证是信息安全评估的目标。从较高层面来看，信息安全评估的主要目标是确定安全控制方面的差距，例如缺乏基本身份验证，授权或加密控制。更深入的是，安全评估目标是风险分析，例如确定安全控制中的潜在弱点，以确保数据的机密性，完整性和可用性。例如，当应用程序处理个人身份信息（PII）和敏感数据时，要验证的安全要求是遵守公司信息安全策略，要求在传输和存储中加密此类数据。假设加密用于保护数据，加密算法和密钥长度需要符合组织加密标准。这些可能要求只能使用某些算法和密钥长度。例如，可以进行安全性测试的安全性要求是验证仅允许使用允许的密码（例如，SHA-256，RSA，AES）以及允许的最小密钥长度（例如，对称性超过128位，非对称性超过1024）加密）。加密算法和密钥长度需要符合组织加密标准。这些可能要求只能使用某些算法和密钥长度。例如，可以进行安全性测试的安全性要求是验证仅允许使用允许的密码（例如，SHA-256，RSA，AES）以及允许的最小密钥长度（例如，对称性超过128位，非对称性超过1024）加密）。加密算法和密钥长度需要符合组织加密标准。这些可能要求只能使用某些算法和密钥长度。例如，可以进行安全性测试的安全性要求是验证仅允许使用允许的密码（例如，SHA-256，RSA，AES）以及允许的最小密钥长度（例如，对称性超过128位，非对称性超过1024）加密）。

从安全评估的角度来看，可以通过使用不同的工件和测试方法在SDLC的不同阶段验证安全性要求。例如，威胁建模侧重于识别设计过程中的安全漏洞，安全代码分析和评论侧重于在开发过程中识别源代码中的安全问题，而渗透测试侧重于在测试或验证过程中识别应用程序中的漏洞。

在SDLC早期发现的安全问题可以记录在测试计划中，以便稍后通过安全测试进行验证。通过结合不同测试技术的结果，可以获得更好的安全测试用例并提高安全要求的保证级别。例如，当渗透测试和源代码分析的结果相结合时，可以区分真正的漏洞和不可利用漏洞。例如，考虑到SQL注入漏洞的安全性测试，黑盒测试可能首先涉及扫描应用程序以指纹漏洞。可以验证的潜在SQL注入漏洞的第一个证据是生成SQL异常。SQL漏洞的进一步验证可能涉及手动注入攻击向量以修改SQL查询的语法以进行信息泄露。这可能涉及大量的试错分析，直到执行恶意查询。假设测试人员有源代码，她可以从源代码分析中学习如何构建可以利用漏洞的SQL攻击向量（例如，执行将机密数据返回给未授权用户的恶意查询）。

威胁和对策分类法
甲威胁和对策的分类，其中考虑到漏洞的考虑根本原因，是在验证安全控制设计，编码，并内置于减轻这种漏洞的暴露的影响的关键因素。对于Web应用程序，安全控件暴露于常见漏洞（例如OWASP Top Ten）可能是获得一般安全要求的良好起点。更具体地说，Web应用程序安全框架[17]提供了漏洞的分类（例如，分类），这些漏洞可以记录在不同的准则和标准中，并通过安全测试进行验证。

威胁和对策分类的重点是根据威胁和漏洞的根本原因定义安全要求。可以使用STRIDE [18]将威胁分类为欺骗，篡改，否认，信息泄露，拒绝服务和特权提升。根本原因可归类为设计中的安全漏洞，编码中的安全漏洞或由于不安全配置导致的问题。例如，弱身份验证漏洞的根本原因可能是当数据跨越应用程序的客户端和服务器层之间的信任边界时缺乏相互身份验证。在架构设计审查期间捕获不可否认威胁的安全要求允许记录对策的要求（例如，

针对漏洞的威胁和对策分类也可用于记录安全编码的安全要求，例如安全编码标准。身份验证控件中常见编码错误的一个示例包括应用哈希函数来加密密码，而不将种子应用于值。从安全编码的角度来看，这是一个影响用于身份验证的加密的漏洞，其中包含编码错误中的漏洞根本原因。由于根本原因是不安全编码，因此可以在安全编码标准中记录安全要求，并在SDLC的开发阶段通过安全代码审查进行验证。

安全测试和风险分析
安全要求需要考虑漏洞的严重性，以支持风险缓解策略。假设组织维护应用程序中发现的漏洞存储库（即漏洞知识库），可以按类型，问题，缓解，根本原因报告安全问题，并将其映射到找到它们的应用程序。此类漏洞知识库还可用于建立度量标准，以分析整个SDLC中安全性测试的有效性。

例如，考虑一个输入验证问题，例如SQL注入，它是通过源代码分析识别出来的，并报告了编码错误根本原因和输入验证漏洞类型。通过使用多个SQL注入攻击向量探测输入字段，可以通过渗透测试来评估此类漏洞的暴露程度。此测试可能会验证在访问数据库之前是否过滤了特​​殊字符并减轻了漏洞。通过结合源代码分析和渗透测试的结果，可以确定漏洞的可能性和暴露程度，并计算漏洞的风险评级。通过报告调查结果中的漏洞风险评级（例如，测试报告），可以决定缓解策略。例如，

通过考虑利用常见漏洞的威胁情景，可以识别应用程序安全控制需要进行安全性测试的潜在风险。例如，OWASP Top Ten漏洞可以映射到诸如网络钓鱼，隐私侵权，识别盗窃，系统危害，数据更改或数据破坏，财务损失和声誉丢失等攻击。这些问题应记录为威胁情景的一部分。通过考虑威胁和漏洞，可以设计一组模拟此类攻击场景的测试。理想情况下，组织漏洞知识库可用于派生安全风险驱动的测试用例，以验证最可能的攻击方案。例如，如果身份盗窃被认为是高风险，

推导功能和非功能测试要求
功能安全要求
从功能安全要求的角度来看，适用的标准，政策和法规既需要一种安全控制，也需要控制功能。这些要求也称为“积极要求”，因为它们说明了可以通过安全测试验证的预期功能。积极要求的示例是：“应用程序将在六次登录尝试失败后锁定用户”或“密码必须至少为六个字母数字字符”。正面要求的验证包括断言预期的功能，并且可以通过重新创建测试条件并根据预定义的输入运行测试来进行测试。然后将结果显示为失败或通过条件。

为了通过安全测试验证安全性要求，安全性需求需要由功能驱动，并且需要突出显示预期的功能（什么）和隐式实现（如何）。验证的高级安全性设计要求的示例可以是：

保护传输和存储中的用户凭据和共享机密
屏蔽显示中的任何机密数据（例如，密码，帐户）
在一定次数的登录尝试失败后锁定用户帐户
由于登录失败，请勿向用户显示特定的验证错误
仅允许使用字母数字的密码，包括特殊字符和最小长度为六个字符，以限制攻击面
通过验证旧密码，新密码和用户对质询问题的回答，仅允许对经过身份验证的用户进行密码更改功能，以防止通过密码更改强制强制输入密码。
密码重置表单应验证用户的用户名和用户的注册电子邮件，然后通过电子邮件将临时密码发送给用户。发出的临时密码应该是一次性密码。密码重置网页的链接将发送给用户。密码重置网页应验证用户临时密码，新密码以及用户对质询问题的回答。
风险驱动的安全要求
安全测试还需要风险驱动，即他们需要验证应用程序是否存在意外行为。这些也称为“否定要求”，因为它们指定了应用程序不应该执行的操作。

负面要求的例子是：

应用程序不应允许更改或销毁数据
恶意用户不应将应用程序泄露或滥用于未经授权的金融交易。
负面要求更难以测试，因为没有预期的行为要寻找。这可能需要威胁分析师提出不可预见的输入条件，原因和影响。这是安全测试需要由风险分析和威胁建模驱动的地方。关键是将威胁情景和对策的功能记录为减轻威胁的因素。

例如，在身份验证控件的情况下，可以从威胁和对策角度记录以下安全要求：

加密存储和传输中的身份验证数据，以降低信息泄露和身份验证协议攻击的风险
使用非可逆加密来加密密码，例如使用摘要（例如，HASH）和种子来防止字典攻击
在达到登录失败阈值后锁定帐户并强制执行密码复杂性以降低暴力破解密码攻击的风险
验证凭据时显示通用错误消息，以降低帐户获取或枚举的风险
相互验证客户端和服务器以防止不可否认和中间人（MiTM）攻击
威胁树和攻击库等威胁建模工具可用于推导负面测试场景。威胁树将承担根攻击（例如，攻击者可能能够读取其他用户的消息）并识别安全控制的不同漏洞（例如，由于SQL注入漏洞而导致数据验证失败）和必要的对策（例如，实施数据）验证和参数化查询，可以验证有效减轻此类攻击。