OWASP安全测试指南版本4.2EN：从原理到实践，全面了解Web安全测试方法

需积分: 1 40 浏览量更新于2024-01-01 收藏 9.7MB PDF 举报

OWASP安全测试指南版本4.2EN是一份由OWASP（开放Web应用程序安全项目）编写的关于web安全测试的指南。它提供了一系列关于安全测试的原则、技术和方法，并强调了安全测试作为开发流程中不可或缺的一部分。本指南重点介绍了手动检查和评审、威胁建模、源代码审查和渗透测试等测试技术，并强调了平衡方法的必要性。此外，它还提供了有关如何确定安全测试需求、将安全测试整合到开发和测试工作流程中以及安全测试数据分析和报告的指导。在本指南中，第0章是前言，由Eoin Keary编写。他介绍了OWASP的使命和该项目的背景，并解释了本指南的目的和范围。第1章是扉页，用来展示和说明该指南的简介和版权信息。第2章是介绍，主要介绍了OWASP测试项目的背景和目标，并阐述了测试的原则和技术。其中，2.1节介绍了OWASP测试项目的背景和目标，强调了该项目对安全测试的重要性。2.2节介绍了测试的原则，包括全面性、一致性和可重复性等原则。2.3节解释了一些常见的测试技术，如黑盒测试、白盒测试和灰盒测试等。2.4节讲述了手动检查和评审的重要性，并提供了一些常用的手动检查和评审方法。2.5节介绍了威胁建模的概念和应用，并解释了如何进行威胁建模。2.6节讨论了源代码审查的重要性，并指导了如何进行源代码审查。2.7节介绍了渗透测试的概念和方法，并提供了一些常用的渗透测试技术。2.8节强调了平衡方法的必要性，即在安全测试中要综合使用各种技术和方法，以达到最佳效果。2.9节讲述了如何确定安全测试需求，包括依赖分析、风险评估和功能矩阵等方法。2.10节介绍了将安全测试整合到开发和测试工作流程中的方法和建议。2.11节讲述了安全测试数据分析和报告的重要性，并提供了一些常用的数据分析和报告方法。第3章是OWASP测试框架，该框架为安全测试提供了一个综合的方法和流程。它包括测试准备、测试执行和测试评估三个阶段，并详细介绍了各个阶段的步骤和所需的工具和资源。此外，该框架还提供了一些常用的测试用例和示例，供用户参考和学习。总之，OWASP安全测试指南版本4.2EN提供了关于web安全测试的全面指导，涵盖了各个方面的测试技术和方法。它不仅强调了安全测试作为开发流程中的重要组成部分，还提供了一些实用的工具和资源。这个指南对于所有希望提高web应用程序安全性的人员，特别是开发人员和安全测试人员，都是一个重要的参考资源。

Web Security Testing Guide v4.2

Unless a holistic approach is adopted, testing just the technical implementation of an application will not uncover

management or operational vulnerabilities that could be present. By testing the people, policies, and processes, an

organization can catch issues that would later manifest themselves into defects in the technology, thus eradicating bugs

early and identifying the root causes of defects. Likewise, testing only some of the technical issues that can be present

in a system will result in an incomplete and inaccurate security posture assessment.

Denis Verdon, Head of Information Security at Fidelity National Financial, presented an excellent analogy for this

misconception at the OWASP AppSec 2004 Conference in New York:

If cars were built like applications … safety tests would assume frontal impact only. Cars would not be roll tested,

or tested for stability in emergency maneuvers, brake effectiveness, side impact, and resistance to theft.

How To Reference WSTG Scenarios

Each scenario has an identiﬁer in the format WSTG-<category>-<number> , where: ‘category’ is a 4 character upper

case string that identiﬁes the type of test or weakness, and ‘number’ is a zero-padded numeric value from 01 to 99. For

example: WSTG-INFO-02 is the second Information Gathering test.

The identiﬁers may change between versions therefore it is preferable that other documents, reports, or tools use the

format: WSTG-<version>-<category>-<number> , where: ‘version’ is the version tag with punctuation removed. For

example: WSTG-v42-INFO-02 would be understood to mean speciﬁcally the second Information Gathering test from

version 4.2.

If identiﬁers are used without including the <version> element then they should be assumed to refer to the latest Web

Security Testing Guide content. Obviously as the guide grows and changes this becomes problematic, which is why

writers or developers should include the version element.

Linking

Linking to Web Security Testing Guide scenarios should be done using versioned links not stable or latest which

will deﬁnitely change with time. However, it is the project team’s intention that versioned links not change. For example:

https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-

Information_Gathering/02-Fingerprint_Web_Server.html . Note: the v42 element refers to version 4.2.

Feedback and Comments

As with all OWASP projects, we welcome comments and feedback. We especially like to know that our work is being

used and that it is effective and accurate.

Principles of Testing

There are some common misconceptions when developing a testing methodology to ﬁnd security bugs in software.

This chapter covers some of the basic principles that professionals should take into account when performing security

tests on software.

There is No Silver Bullet

While it is tempting to think that a security scanner or application ﬁrewall will provide many defenses against attack or

identify a multitude of problems, in reality there is no silver bullet to the problem of insecure software. Application

security assessment software, while useful as a ﬁrst pass to ﬁnd low-hanging fruit, is generally immature and ineffective

at in-depth assessment or providing adequate test coverage. Remember that security is a process and not a product.

Think Strategically, Not Tactically

Security professionals have come to realize the fallacy of the patch-and-penetrate model that was pervasive in

information security during the 1990’s. The patch-and-penetrate model involves ﬁxing a reported bug, but without

proper investigation of the root cause. This model is usually associated with the window of vulnerability, also referred to

as window of exposure, shown in the ﬁgure below. The evolution of vulnerabilities in common software used worldwide

has shown the ineffectiveness of this model. For more information about windows of exposure, see Schneier on

Security.

Web Security Testing Guide v4.2

Vulnerability studies such as Symantec’s Internet Security Threat Report have shown that with the reaction time of

attackers worldwide, the typical window of vulnerability does not provide enough time for patch installation, since the

time between a vulnerability being uncovered and an automated attack against it being developed and released is

decreasing every year.

There are several incorrect assumptions in the patch-and-penetrate model. Many users believe that patches interfere

with normal operations or might break existing applications. It is also incorrect to assume that all users are aware of

newly released patches. Consequently not all users of a product will apply patches, either because they think patching

may interfere with how the software works, or because they lack knowledge about the existence of the patch.

Figure 2-2: Window of Vulnerability

It is essential to build security into the Software Development Life Cycle (SDLC) to prevent reoccurring security

problems within an application. Developers can build security into the SDLC by developing standards, policies, and

guidelines that ﬁt and work within the development methodology. Threat modeling and other techniques should be

used to help assign appropriate resources to those parts of a system that are most at risk.

The SDLC is King

The SDLC is a process that is well-known to developers. By integrating security into each phase of the SDLC, it allows

for a holistic approach to application security that leverages the procedures already in place within the organization. Be

aware that while the names of the various phases may change depending on the SDLC model used by an

organization, each conceptual phase of the archetype SDLC will be used to develop the application (i.e., deﬁne,

design, develop, deploy, maintain). Each phase has security considerations that should become part of the existing

process, to ensure a cost-effective and comprehensive security program.

There are several secure SDLC frameworks in existence that provide both descriptive and prescriptive advice. Whether

a person takes descriptive or prescriptive advice depends on the maturity of the SDLC process. Essentially, prescriptive

advice shows how the secure SDLC should work, and descriptive advice shows how it is used in the real world. Both

have their place. For example, if you don’t know where to start, a prescriptive framework can provide a menu of

potential security controls that can be applied within the SDLC. Descriptive advice can then help drive the decision

process by presenting what has worked well for other organizations. Descriptive secure SDLCs include BSIMM; and

the prescriptive secure SDLCs include OWASP’s Open Software Assurance Maturity Model (OpenSAMM), and ISO/IEC

27034 Parts 1-7, all published (except part 4).

Test Early and Test Often

Web Security Testing Guide v4.2

When a bug is detected early within the SDLC it can be addressed faster and at a lower cost. A security bug is no

different from a functional or performance-based bug in this regard. A key step in making this possible is to educate the

development and QA teams about common security issues and the ways to detect and prevent them. Although new

libraries, tools, or languages can help design programs with fewer security bugs, new threats arise constantly and

developers must be aware of the threats that affect the software they are developing. Education in security testing also

helps developers acquire the appropriate mindset to test an application from an attacker’s perspective. This allows

each organization to consider security issues as part of their existing responsibilities.

Test Automation

In modern development methodologies such as (but not limited to): agile, devops/devsecops, or rapid application

development (RAD) consideration should be put into integrating security tests in to continuous integration/continuous

deployment (CI/CD) workﬂows in order to maintain baseline security information/analysis and identify “low hanging

fruit” type weaknesses. This can be done by leveraging dynamic application security testing (DAST), static application

security testing (SAST), and software composition analysis (SCA) or dependency tracking tools during standard

automated release workﬂows or on a regularly scheduled basis.

Understand the Scope of Security

It is important to know how much security a given project will require. The assets that are to be protected should be

given a classiﬁcation that states how they are to be handled (e.g., conﬁdential, secret, top secret). Discussions should

occur with legal council to ensure that any speciﬁc security requirements will be met. In the USA, requirements might

come from federal regulations, such as the Gramm-Leach-Bliley Act, or from state laws, such as the California SB-1386.

For organizations based in EU countries, both country-speciﬁc regulation and EU Directives may apply. For example,

Directive 96/46/EC4 and Regulation (EU) 2016/679 (General Data Protection Regulation) make it mandatory to treat

personal data in applications with due care, whatever the application.

Develop the Right Mindset

Successfully testing an application for security vulnerabilities requires thinking “outside of the box.” Normal use cases

will test the normal behavior of the application when a user is using it in the manner that is expected. Good security

testing requires going beyond what is expected and thinking like an attacker who is trying to break the application.

Creative thinking can help to determine what unexpected data may cause an application to fail in an insecure manner.

It can also help ﬁnd any assumptions made by web developers that are not always true, and how those assumptions

can be subverted. One reason that automated tools do a poor job of testing for vulnerabilities is that automated tools do

not think creatively. Creative thinking must be done on a case-by-case basis, as most web applications are being

developed in a unique way (even when using common frameworks).

Understand the Subject

One of the ﬁrst major initiatives in any good security program should be to require accurate documentation of the

application. The architecture, data-ﬂow diagrams, use cases, etc. should be recorded in formal documents and made

available for review. The technical speciﬁcation and application documents should include information that lists not

only the desired use cases, but also any speciﬁcally disallowed use cases. Finally, it is good to have at least a basic

security infrastructure that allows the monitoring and trending of attacks against an organization’s applications and

network (e.g., intrusion detection systems).

Use the Right Tools

While we have already stated that there is no silver bullet tool, tools do play a critical role in the overall security

program. There is a range of Open Source and commercial tools that can automate many routine security tasks. These

tools can simplify and speed up the security process by assisting security personnel in their tasks. However, it is

important to understand exactly what these tools can and cannot do so that they are not oversold or used incorrectly.

The Devil is in the Details

It is critical not to perform a superﬁcial security review of an application and consider it complete. This will instill a false

sense of conﬁdence that can be as dangerous as not having done a security review in the ﬁrst place. It is vital to

carefully review the ﬁndings and weed out any false positives that may remain in the report. Reporting an incorrect

security ﬁnding can often undermine the valid message of the rest of a security report. Care should be taken to verify

Web Security Testing Guide v4.2

that every possible section of application logic has been tested, and that every use case scenario was explored for

possible vulnerabilities.

Use Source Code When Available

While black-box penetration test results can be impressive and useful to demonstrate how vulnerabilities are exposed

in a production environment, they are not the most effective or efﬁcient way to secure an application. It is difﬁcult for

dynamic testing to test the entire code base, particularly if many nested conditional statements exist. If the source code

for the application is available, it should be given to the security staff to assist them while performing their review. It is

possible to discover vulnerabilities within the application source that would be missed during a black-box engagement.

Develop Metrics

An important part of a good security program is the ability to determine if things are getting better. It is important to track

the results of testing engagements, and develop metrics that will reveal the application security trends within the

organization.

Good metrics will show:

If more education and training are required;

If there is a particular security mechanism that is not clearly understood by the development team;

If the total number of security related problems being found is decreasing.

Consistent metrics that can be generated in an automated way from available source code will also help the

organization in assessing the effectiveness of mechanisms introduced to reduce security bugs in software

development. Metrics are not easily developed, so using a standard such as the one provided by the IEEE is a good

starting point.

Document the Test Results

To conclude the testing process, it is important to produce a formal record of what testing actions were taken, by whom,

when they were performed, and details of the test ﬁndings. It is wise to agree on an acceptable format for the report that

is useful to all concerned parties, which may include developers, project management, business owners, IT

department, audit, and compliance.

The report should clearly identify to the business owner where material risks exist, and do so in a manner sufﬁcient to

get their backing for subsequent mitigation actions. The report should also be clear to the developer in pin-pointing the

exact function that is affected by the vulnerability and associated recommendations for resolving issues in a language

that the developer will understand. The report should also allow another security tester to reproduce the results. Writing

the report should not be overly burdensome on the security tester themselves. Security testers are not generally

renowned for their creative writing skills, and agreeing on a complex report can lead to instances where test results are

not properly documented. Using a security test report template can save time and ensure that results are documented

accurately and consistently, and are in a format that is suitable for the audience.

Testing Techniques Explained

This section presents a high-level overview of various testing techniques that can be employed when building a testing

program. It does not present speciﬁc methodologies for these techniques, as this information is covered in Chapter 3.

This section is included to provide context for the framework presented in the next chapter and to highlight the

advantages or disadvantages of some of the techniques that should be considered. In particular, we will cover:

Manual Inspections & Reviews

Threat Modeling

Code Review

Penetration Testing

Manual Inspections and Reviews

Web Security Testing Guide v4.2

Overview

Manual inspections are human reviews that typically test the security implications of people, policies, and processes.

Manual inspections can also include inspection of technology decisions such as architectural designs. They are

usually conducted by analyzing documentation or performing interviews with the designers or system owners.

While the concept of manual inspections and human reviews is simple, they can be among the most powerful and

effective techniques available. By asking someone how something works and why it was implemented in a speciﬁc

way, the tester can quickly determine if any security concerns are likely to be evident. Manual inspections and reviews

are one of the few ways to test the software development life-cycle process itself and to ensure that there is an

adequate policy or skill set in place.

As with many things in life, when conducting manual inspections and reviews it is recommended that a trust-but-verify

model is adopted. Not everything that the tester is shown or told will be accurate. Manual reviews are particularly good

for testing whether people understand the security process, have been made aware of policy, and have the appropriate

skills to design or implement secure applications.

Other activities, including manually reviewing the documentation, secure coding policies, security requirements, and

architectural designs, should all be accomplished using manual inspections.

Advantages

Requires no supporting technology

Can be applied to a variety of situations

Flexible

Promotes teamwork

Early in the SDLC

Disadvantages

Can be time-consuming

Supporting material not always available

Requires signiﬁcant human thought and skill to be effective

Threat Modeling

Overview

Threat modeling has become a popular technique to help system designers think about the security threats that their

systems and applications might face. Therefore, threat modeling can be seen as risk assessment for applications. It

enables the designer to develop mitigation strategies for potential vulnerabilities and helps them focus their inevitably

limited resources and attention on the parts of the system that most require it. It is recommended that all applications

have a threat model developed and documented. Threat models should be created as early as possible in the SDLC,

and should be revisited as the application evolves and development progresses.

To develop a threat model, we recommend taking a simple approach that follows the NIST 800-30 standard for risk

assessment. This approach involves:

Decomposing the application – use a process of manual inspection to understand how the application works, its

assets, functionality, and connectivity.

Deﬁning and classifying the assets – classify the assets into tangible and intangible assets and rank them

according to business importance.

Exploring potential vulnerabilities - whether technical, operational, or managerial.

Exploring potential threats – develop a realistic view of potential attack vectors from an attacker’s perspective by

using threat scenarios or attack trees.

Creating mitigation strategies – develop mitigating controls for each of the threats deemed to be realistic.

剩余464页未读，继续阅读

jasonwgz

粉丝: 0
资源: 2

OWASP安全测试指南版本4.2EN：从原理到实践，全面了解Web安全测试方法

最新资源