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.


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.


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.




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.


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.



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


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的工作常常被中断,这使得问题恶化。


  • 0
  • 3
    觉得还不错? 一键收藏
  • 0


  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助




当前余额3.43前往充值 >
领取后你会自动成为博主和红包主的粉丝 规则
钱包余额 0