Software Security Testing软件安全测试

Security testing has recently moved beyond the realm of network port scanning to include

probing software behavior as a critical aspect of system behavior (see the sidebar). Unfortunately, testing software security is a commonly misunderstood task..   

安全性测试最近已超越了网络端口扫描的境界，以包括试探软件行为作为一个关键技术的方法来衡量系统安全，不幸的是，软件安全测试经常被错误理解。

Security testing done properly goes deeper than simple black-box probing on the presentation layer (the sort performed by so-called application security tools)—and even beyond the functional testing of security apparatus.Testers must use a risk-based approach,grounded in both the system’s architectural reality and the attacker’s mindset, to gauge software security adequately. By identifying risks in the system and creating tests driven by those risks, a software security tester can properly focus on areas of

测试使用得当深入较简单的暗箱操作，探索对表现层（排序演出由所谓的应用安全工具） ，甚至超出了功能测试的安全器具。测试人员必须使用基于风险的办法，根植于这两个系统的建筑现实和攻击者的心态，是衡量软件保障充分。通过确定风险，在制度，以及创造考验驱使这些风险，一个软件安全测试仪能够妥善重点地区代码，其中一个是攻击有可能取得成功。这一办法提供更高层次的软件安全保证比尽可能与古典黑盒测试。

Software security is about making software behave in the presence of a malicious attack, even though in the real world, software failures usually happen spontaneously—that is,without intentional mischief. Not surprisingly, standard software testing literature is only concerned with what happens when software fails,regardless of intent. The difference between software safety and software security is therefore the presence of an intelligent adversary bent on breaking the system.

软件安全是有关决策软件的行为存在一个恶毒的攻击，即使在现实世界中，软件故障，通常发生自发性-那就是如果没有故意搬弄是非。不令人惊讶的是，标准的软件测试文学是只关注会发生什么软件出现故障时，无论我的意图。差额与软件安全性和软件因此，安全是存在的智能对手一意孤行打破system.code其中的一个攻击是有可能取得成功。这一办法提供了一个更高层次的软件安全保证比尽可能与古典黑盒测试。

Security is always relative to the information and services being protected,the skills and resources of adversaries,and the costs of potential assurance remedies; security is an exercisein risk management. Risk analysis, especially at the design level,can help us identify potential security problems and their impact.1 Once identified and ranked, softwarerisks can then help guide software security testing.

安全总是相对的，以本信息和服务，受到保护，技能和资源的对手，和成本潜力保证办法;保障是一个演习在风险管理。风险分析，特别是在设计水平，可以帮助我们找出潜在的安全问题，而且它们impact.1一旦确定排名，软件风险可以，然后帮助指导软件安全性测试。

A vulnerability is an error that an attacker can exploit. Many types of vulnerabilities exist, and computer security researchers have created taxonomies of them.2 Security vulnerabilities in software systems range from local implementation errors (such as use of the gets() function call in C/C++), through interprocedural interface errors (such as a race condition between an access control check and a file operation),to much higher design-level mistakes (such as error handling and recovery systems that fail in an insecure fashion or object-sharing systems that mistakenly include transitive trust issues). Vulnerabilities typically fall into two categories—bugs at the implementation level and flaws at the design level.

一个漏洞是一个错误，这是一个攻击者可以利用。许多类型的安全漏洞存在，以及电脑安全研究人员已经创造了分类法对them.2安全漏洞在软件系统范围从地方执行错误（如使用该得到（ ）函数请在C / C + + ） ，透过跨过程接口错误（如一个种族之间的情况是一个获得控制检验及文件操作） ，高得多的设计级别的错误（如错误处理和回收系统失败的一种不安全时装或对象共享系统这包括误传递信任问题） 。典型的脆弱性秋季分为两类，一类-臭虫在执行层面和缺陷，在设计level.

Attackers generally don’t care whether a vulnerability is due to a flaw or a bug, although bugs tend tobe easier to exploit. Because attacks are now becoming more sophisticated,the notion of which vulnerabilities actually matter is changing.Although timing attacks, including the well-known race condition,were considered exotic just a few years ago, they’re common now.Similarly, two-stage buffer overflow attacks using trampolines were once the domain of software scientists, but now appear in 0day exploits.

攻击者一般不关心是否有漏洞，是因为他们看到缺点或错误，虽然错误倾向部隆吉易于开采。因为发动这类攻击的，现在变得更加成熟，这一概念，其中的漏洞，其实无论是changing.although定时攻击，其中包括著名的竞赛条件，被认为是异国情调就在几年前，他们正在共同now.similarly ，分两个阶段进行缓冲区溢出攻击利用蹦床一度域名的软件科学家，但现在却出现在0天功勋。

Design-level vulnerabilities are the hardest defect category to handle, but they’re also the most prevalent and critical. Unfortunately, ascertaining whether a program has design-level vulnerabilities requires great expertise, which makes finding such flaws not only difficult, but particularly hard to automate.

设计级别系统漏洞最难的缺陷类别来处理，但他们也是最流行和关键的。不幸的是，确定是否计划设计级别的漏洞，需要伟大的专业知识，这使得寻找这种缺陷不仅难度，但特别努力实现自动化。

Examples of design-level problems include error handling in object-oriented systems, object sharing and trust issues, unprotected data channels (both internal and external),incorrect or missing access control mechanisms, lack of auditing/logging or incorrect logging, and ordering and timing errors (especially in multithreaded systems). These sorts of flaws almost always lead to security risk.

实例设计层次问题包括错误处理在对象导向系统，对象共享与信任问题，未受保护的数据渠道（内部和外部）不正确或失踪的访问控制机制，缺乏审计/采伐或不正确采伐，并订购和定时错误（尤其是在多线程系统） 。这些各种各样的缺陷，几乎总是导致安全风险。Risk managemen and security testing

风险管理和安全测试

Software security practitioners perform many different tasks to manage software security risks, including

软件安全测试人员执行许多不同的尝试来控制软件安全风险，包括：

         creating security abuse/misusecases; 创建安全滥用/错用

         • listing normative security requirements;例举标准化的安全需求

         • performing architectural riskanalysis;履行架构安全生命周期

         building risk-based security testplans;建立以风险为基础的安全测试计划

         wielding static analysis tools; 驾轻就熟的使用静态分析工具

         performing security tests;执行安全测试

         performing penetration testing in the final environment; 在用户环境执行渗透测试

         cleaning up after security breaches 在安全测试后进行清理

Three of these are particularly closely linked—architectural risk analysis, risk-based security test planning, and security testing—because a critical aspect of security testing relies on probing security risks. Last issue’s installment1 explained how to approach a software security risk analysis, the end product being a set of security-related risks ranked by business or mission impact. (Figure 1 shows where we are in our series of articles about software security’s place in the software development life cycle.)。

架构风险分析，基于风险的安全测试计划，与安全测试，这三个方面是紧密相连的，因为安全测试的一个重要方面就取决于探索安全风险。最后一个问题的提出解释了如何实施软件的安全风险分析，（分析的）最终产品是由业务或任务影响所划分的一系列与安全相关的风险。 （图1显示了在软件开发生命周期中，关于软件安全的位置我们正处于那一阶段）

The pithy aphorism, “software security is not security software” provides an important motivator for security testing. Although security features such as cryptography, strong authentication,and access control play a critical role in software security, security itself is an emergent property of the entire system, not just the security mechanisms and features. A buffer overflow is a security problem regardless of whether it exists in a security feature or in the noncritical GUI. Thus, security testing must necessarily nvolve two diverse approaches:

 

1. testing security mechanisms to ensure that their functionality is properly implemented, and

2. performing risk-based security testing motivated by understanding and simulating the attacker’s approach.

有一句经典的格言："软件的安全性并不是指安全软件",它给安全测试提供了一个重要的启发。虽然安全性（例如密码学、强力认证与访问控制等）在软件安全方面有重要的作用，但是软件安全本身对整个系统就是一个新兴的特性，而不仅仅是指安全机制与安全特性。不管是在安全性方面还是在不重要的公共用户界面方面（GUI），一次缓存溢出，就是一个安全问题。因此安全测试必须包括以下两个不同的测试方法：

1.测试安全机制以确保它们的功能正确实现

2.执行基于风险的安全测试的动机是了解和模拟攻击者的入侵。

Many developers erroneously believe that security involves only the addition and use of various ecurity features, which leads to the incorrect belief that “adding SSL” is tantamount to securing an application. Software security practitioners bemoan the over-reliance on “magic crypto fairy dust” as a reaction to this problem. Software testers charged with security testing often fall prey to the same thinking.

许多开发者错误的认为安全性仅仅涉及各类安全特征的使用和增补，这一观点导致不正确的信仰："引进SSL"相当于确保一个应用程序。软件安全务实者抱怨过分依赖“”作为对这一问题的回应。承担安全测试的软件测试者常常成为这种思想的牺牲品。

How to approach security testing 如何对待安全测试

Like any other form of testing, security testing involves determining who should do it and what activities they should undertake.

像任何其它形式的测试一样，安全测试同样涉及到决定谁去执行测试以及他们应该承担怎样的任务。

Who

Because security testing involves two approaches, the question of who should do it has two answers. Standard testing organizations using a traditional approach can perform functional security testing. For example, ensuring that access control mechanisms work as advertised is a classic functional testing exercise.

由于安全测试包括两种方法，所以谁去执行安全测试的问题有两个答案。规范化的测试公司使用传统的方法执行功能性安全测试。例如：确保访问控制机制工作就像广告一样，这是一种经典性的功能测试行为。

On the other hand, traditional QA staff will have more difficulty performing risk-based security testing. The problem is one of expertise. First, security tests (especially those resulting in complete exploit) are difficult to craft because the designer must think like an attacker. Second, security tests don’t often cause direct security exploit and thus present an observability problem. A security test could result in an unanticipated outcome that requires the tester to perform further sophisticated analysis. Bottom line: risk-based security testing relies more on expertise and experience than we would like.

另一方面，传统的QA在执行基于风险安全测试面临更多的困难。这是一个很专业的问题，首先，安全性测试（特别是那些导致完全漏洞的测试）很难巧妙的制作因为设计者一定是站在攻击者的位置思考。其次，安全测试往往不导致直接的安全漏洞，因此也不会呈现出一个可观测到的问题。 一个安全测试可能导致一个不可预料的结果，（这个结果）要求测试人员进一步执行精密的分析。最后一点：基于风险的安全测试更多的依赖于专业知识和经验，而不是我们所认为的。

How

Books like How to Break Software Security and Exploiting Software help educate testing professionals on how to think like an attacker.4,5Nevertheless,software exploits are surprisingly sophisticated these days, and the level of discourse found in books and articles is only now coming into alignment.

像那些如何突破软件安全和开发软件的书帮助培养测试专家像攻击者一样思考。尽管软件开发

White- and black-box testing and analysis methods both attempt to understand software, but they use different approaches depending on whether the analyst or tester has access to source code. White-box analysis involves analyzing and understanding source code and the design.It’s typically very effective in finding programming errors (bugs when automatically scanning code and flaws when doing risk analysis); in some cases, this approach amounts to pattern matching and can even be automated with a static analyzer (the subject of a future installment of this department). One drawback to this kind of testing is that it might report a potential vulnerability where none actually exists (a false positive). Nevertheless, using static analysis methods on source code is a good technique for analyzing certain kinds of software.Similarly, risk analysis is a whitebox approach based on a deep understanding of software architecture.

白盒测试、黑盒测试以及分析报告的方法都试图理解软件，但它们采用不同的方法，这主要取决于分析员或测试员是否访问源代码。白盒测试分析涉及分析和了解源代码以及软件的设计。在查找程序错误时白盒测试是一种非常经典有效的方法。这种方法的一个缺点是：它可能报告一个实际不存在的潜在性弱点。然而，对于分析特定类型的软件，静态分析源码的方法是一个好技术。风险分析同样是白盒测试的方法，它是基于对软件建构的深入理解。

Black-box analysis refers to analyzing a running program by probing it with various inputs. This kind of testing requires only a running program and doesn’t use source-code analysis of any kind. In the security paradigm, malicious input can be supplied to the program in an effortto break it: if the program breaks during a particular test, then we might have discovered a security problem. Black-box testing is possible even without access to binary code—that is, a program can be tested remotely over a network. Ifthe tester can supply the proper input (and observe the test’s effect), then black-box testing is possible.Any testing method can reveal possible software risks and potential exploits. One problem with almost all kinds of security testing (regardless of whether it’s black or white box) is the lack of it—most QA organizations focus on features and spend very little time understanding or probing nonfunctional security risks. Exacerbating the problem, the QA process is often broken in many commercial software houses due to time and budget constraints and the belief that QA is not an essential part of software development.

黑盒分析是指通过探索不同的输入分析一个运行的程序，这一类型的测试仅仅依赖于一个可运行的程序并且不需要使用其他任何类型的源码分析。在安全测试的范例中，为中断程序而恶意的输入值：如果特定的测试中程序中断，那我们可能会发现一个安全问题。即使没有获得二进制代码，黑盒测试也是可以做到的这点，换句话说，程序可以通过网络进行远程测试。如果测试人员能够给出恰当的输入（并且能够观察测试的结果），那黑盒测试可以进行的。

任何测试方法都有可能显示软件风险和潜在的漏洞。几乎所有的安全性测试（不管是黑盒还是白黑盒测试）存在的问题都是因为缺乏它——即大多数QA组织关注功能特性但却花很少的时间了解和探索非功能性安全测试。 在许多商业化的软件机构里由于时间和预算的限制并且他们认为QA并不是软件开发必不可少的一部分，因此QA的工作常常被中断，这使得问题恶化。

未完待续......