OWASP测试指南第四版：英文版

需积分: 10 149 浏览量更新于2024-07-22 收藏 2.08MB PDF 举报

"OWASP测试指导(英文版)" 是一份由Open Web Application Security Project (OWASP)发布的开源文档，旨在帮助专业人士提升应用软件的安全性。该文档是OWASP项目的一部分，由Matteo Meucci和Andrew Muller领导，并遵循创作共享（Creative Commons CC Attribution Share-Alike）许可协议。用户可以在OWASP官方网站上免费获取此资源。 OWASP是一个全球性的、非营利的社区，专注于提高应用软件的安全性。其目标是使应用安全变得“可见”，以便个人和组织能够基于充分的信息来决策应用安全风险。任何人都可以参与OWASP并利用其开放的材料，这些材料均根据自由和开放软件许可证发布。OWASP基金会是一个501(c)(3)非盈利慈善机构，确保 OWASP 的工作持续可用并得到支持。本书的图标表示了不同版本的质量级别： - ALPHA：代表“Alpha质量”的书内容是一个工作草案，内容非常粗糙且处于开发阶段，直到进入下一阶段发布。 - BETA：代表“Beta质量”的书内容是下一个级别的，内容仍在发展中，直到下一次出版。 - RELEASE：代表“Release质量”的书内容是书籍生命周期中的最高质量级别，意味着内容已经过充分的审查和完善。 OWASP测试指导书第四版可能涵盖了多个方面，包括但不限于： 1. **应用安全测试方法**：如何对Web应用程序进行安全性测试，包括黑盒测试、白盒测试和灰盒测试。 2. **威胁模型和攻击向量**：详细解释常见的网络攻击，如SQL注入、跨站脚本（XSS）、跨站请求伪造（CSRF）等，以及如何识别和防止这些威胁。 3. **身份验证和授权测试**：检查登录和权限控制机制的强度，以防止未授权访问。 4. **加密和数据保护**：讨论加密算法的选择和实现，以及敏感数据的存储和传输安全。 5. **输入验证和输出编码**：如何有效防止恶意输入和防止数据注入攻击。 6. **错误处理和日志记录**：最佳实践以避免信息泄露，并确保有效的日志记录以追踪潜在问题。 7. **应用程序安全设计原则**：提供安全设计模式和反模式，以在软件开发生命周期的早期阶段就考虑安全因素。 8. **安全配置**：服务器和应用程序的配置最佳实践，以减少暴露的风险。 9. **安全更新和补丁管理**：如何及时应用安全更新和补丁，保持系统的安全状态。 10. **移动和Web服务安全**：针对移动应用和API的独特安全挑战和测试方法。这份指南对于那些想要深入理解应用安全测试的初学者，或者希望提高现有测试流程的专业人士来说，是非常有价值的资源。通过学习和应用其中的知识，可以有效地发现并修复应用中的安全漏洞，降低安全风险。

Testing Guide Introduction

software such as operating systems, when testing web applica-

tions (especially if they have been developed in-house) the source

code should be made available for testing purposes.

Many unintentional but significant security problems are also ex-

tremely difficult to discover with other forms of analysis or test-

ing, such as penetration testing, making source code analysis the

technique of choice for technical testing. With the source code, a

tester can accurately determine what is happening (or is supposed

to be happening) and remove the guess work of black box testing.

Examples of issues that are particularly conducive to being found

through source code reviews include concurrency problems, flawed

business logic, access control problems, and cryptographic weak-

nesses as well as backdoors, Trojans, Easter eggs, time bombs,

logic bombs, and other forms of malicious code. These issues of-

ten manifest themselves as the most harmful vulnerabilities in

web sites. Source code analysis can also be extremely efficient to

find implementation issues such as places where input validation

was not performed or when fail open control procedures may be

present. But keep in mind that operational procedures need to be

reviewed as well, since the source code being deployed might not

be the same as the one being analyzed herein [13].

Advantages:

• Completeness and effectiveness

• Accuracy

• Fast (for competent reviewers)

Disadvantages:

• Requires highly skilled security developers

• Can miss issues in compiled libraries

• Cannot detect run-time errors easily

• The source code actually deployed might differ from the one

being analyzed

For more on code review, checkout the OWASP code review project.

Penetration Testing

Overview

Penetration testing has been a common technique used to test

network security for many years. It is also commonly known as

black box testing or ethical hacking. Penetration testing is essen-

tially the “art” of testing a running application remotely to find

security vulnerabilities, without knowing the inner workings of

the application itself. Typically, the penetration test team would

have access to an application as if they were users. The tester acts

like an attacker and attempts to find and exploit vulnerabilities. In

many cases the tester will be given a valid account on the system.

While penetration testing has proven to be effective in network

security, the technique does not naturally translate to applica-

tions. When penetration testing is performed on networks and

operating systems, the majority of the work is involved in finding

and then exploiting known vulnerabilities in specific technologies.

As web applications are almost exclusively bespoke, penetration

testing in the web application arena is more akin to pure research.

Penetration testing tools have been developed that automate the

process, but with the nature of web applications their effective-

ness is usually poor.

Many people today use web application penetration testing as

their primary security testing technique. Whilst it certainly has its

place in a testing program, we do not believe it should be consid-

ered as the primary or only testing technique. Gary McGraw in [14]

summed up penetration testing well when he said, “If you fail a

penetration test you know you have a very bad problem indeed. If

you pass a penetration test you do not know that you don’t have

a very bad problem”. However, focused penetration testing (i.e.,

testing that attempts to exploit known vulnerabilities detected in

previous reviews) can be useful in detecting if some specific vul-

nerabilities are actually fixed in the source code deployed on the

web site.

Advantages:

• Can be fast (and therefore cheap)

• Requires a relatively lower skill-set than source code review

• Tests the code that is actually being exposed

Disadvantages:

• Too late in the SDLC

• Front impact testing only.

The Need for a Balanced Approach

With so many techniques and approaches to testing the security of

web applications it can be difficult to understand which techniques

to use and when to use them. Experience shows that there is no

right or wrong answer to the question of exactly what techniques

should be used to build a testing framework. In fact all techniques

should probably be used to test all the areas that need to be tested.

Although it is clear that there is no single technique that can be

performed to effectively cover all security testing and ensure that

all issues have been addressed, many companies adopt only one

approach. The approach used has historically been penetration

testing. Penetration testing, while useful, cannot effectively ad-

dress many of the issues that need to be tested. It is simply “too

little too late” in the software development life cycle (SDLC).

The correct approach is a balanced approach that includes several

techniques, from manual reviews to technical testing. A balanced

approach should cover testing in all phases of the SDLC. This ap-

proach leverages the most appropriate techniques available de-

pending on the current SDLC phase.

Of course there are times and circumstances where only one tech-

nique is possible. For example, a test on a web application that has

already been created, but where the testing party does not have

access to the source code. In this case, penetration testing is clearly

better than no testing at all. However, the testing parties should be

encouraged to challenge assumptions, such as no access to source

code, and to explore the possibility of more complete testing.

A balanced approach varies depending on many factors, such as

the maturity of the testing process and corporate culture. It is rec-

ommended that a balanced testing framework should look some-

thing like the representations shown in Figure 3 and Figure 4. The

following figure shows a typical proportional representation over-

laid onto the software development life cycle. In keeping with re-

search and experience, it is essential that companies place a higher

emphasis on the early stages of development.

Testing Guide Introduction

DEFINE

DESIGN

DEVELOP

DEPLOY

MAINTAIN

Figure 3: Proportion of Test Effort in SDLC

Figure 4: Proportion of Test Effort According to Test Technique

‘Example 1: Magic Parameters’

Imagine a simple web application that accepts a name-value pair of

“magic” and then the value. For simplicity, the GET request may be:

http://www.host/application?magic=value

To further simplify the example, the values in this case can only be AS-

CII characters a – z (upper or lowercase) and integers 0 – 9.

The designers of this application created an administrative backdoor

during testing, but obfuscated it to prevent the casual observer from

discovering it. By submitting the value sf8g7sfjdsurtsdieerwqreds-

gnfg8d (30 characters), the user will then be logged in and presented

with an administrative screen with total control of the application. The

HTTP request is now:

http://www.host/application?magic= sf8g7sfjdsurtsdieerwqredsgnf-

g8d

Given that all of the other parameters were simple two- and

three-characters fields, it is not possible to start guessing combina-

tions at approximately 28 characters. A web application scanner will

need to brute force (or guess) the entire key space of 30 characters.

That is up to 30^28 permutations, or trillions of HTTP requests. That

is an electron in a digital haystack.

The code for this exemplar Magic Parameter check may look like the

following:

public void doPost( HttpServletRequest request, HttpServle-

tResponse response)

{

String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”;

boolean admin = magic.equals( request.getParameter(“mag-

ic”));

if (admin) doAdmin( request, response);

else …. // normal processing

}

By looking in the code, the vulnerability practically leaps off the page

as a potential problem.

Example 2: Bad Cryptography

Cryptography is widely used in web applications. Imagine that a devel-

oper decided to write a simple cryptography algorithm to sign a user

in from site A to site B automatically. In his/her wisdom, the developer

decides that if a user is logged into site A, then he/she will generate

a key using an MD5 hash function that comprises: Hash { username :

date }

When a user is passed to site B, he/she will send the key on the query

string to site B in an HTTP re-direct. Site B independently computes

the hash, and compares it to the hash passed on the request. If they

match, site B signs the user in as the user they claim to be.

As the scheme is explained the inadequacies can be worked out. Any-

one that figures out the scheme (or is told how it works, or downloads

the information from Bugtraq) can log in as any user. Manual inspec-

tion, such as a review or code inspection, would have uncovered this

security issue quickly. A black-box web application scanner would not

have uncovered the vulnerability. It would have seen a 128-bit hash

that changed with each user, and by the nature of hash functions, did

not change in any predictable way.

PROCESS REVIEWS

& MANUAL INSPECTIONS

CODE REVIEW

SECURITY TESTING

The following figure shows a typical proportional representation

overlaid onto testing techniques.

A Note about Web Application Scanners

Many organizations have started to use automated web application

scanners. While they undoubtedly have a place in a testing program,

some fundamental issues need to be highlighted about why it is be-

lieved that automating black box testing is not (or will ever be) effec-

tive. However, highlighting these issues should not discourage the use

of web application scanners. Rather, the aim is to ensure the limita-

tions are understood and testing frameworks are planned appropri-

ately.

Important: OWASP is currently working to develop a web application

scanner bench marking platform. The following examples show why

automated black box testing is not effective.

Testing Guide Introduction

A Note about Static Source Code Review Tools

Many organizations have started to use static source code scanners.

While they undoubtedly have a place in a comprehensive testing pro-

gram, it is necessary to highlight some fundamental issues about why

this approach is not effective when used alone. Static source code

analysis alone cannot identify issues due to flaws in the design, since

it cannot understand the context in which the code is constructed.

Source code analysis tools are useful in determining security issues

due to coding errors, however significant manual effort is required to

validate the findings.

Deriving Security Test Requirements

To have a successful testing program, one must know what the test-

ing objectives are. These objectives are specified by the security re-

quirements. This section discusses in detail how to document require-

ments for security testing by deriving them from applicable standards

and regulations, and from positive and negative application require-

ments. It also discusses how security requirements effectively drive

security testing during the SDLC and how security test data can be

used to effectively manage software security risks.

Testing Objectives

One of the objectives of security testing is to validate that security

controls operate as expected. This is documented via security re-

quirements that describe the functionality of the security control. At a

high level, this means proving confidentiality, integrity, and availability

of the data as well as the service. The other objective is to validate

that security controls are implemented with few or no vulnerabilities.

These are common vulnerabilities, such as the OWASP Top Ten, as

well as vulnerabilities that have been previously identified with secu-

rity assessments during the SDLC, such as threat modelling, source

code analysis, and penetration test.

Security Requirements Documentation

The first step in the documentation of security requirements is to

understand the business requirements. A business requirement

document can provide initial high-level information on the expected

functionality of the application. For example, the main purpose of an

application may be to provide financial services to customers or to al-

low goods to be purchased from an on-line catalog. A security section

of the business requirements should highlight the need to protect the

customer data as well as to comply with applicable security docu-

mentation such as regulations, standards, and policies.

A general checklist of the applicable regulations, standards, and pol-

icies is a good preliminary security compliance analysis for web ap-

plications. For example, compliance regulations can be identified by

checking information about the business sector and the country or

state where the application will operate. Some of these compliance

guidelines and regulations might translate into specific technical re-

quirements for security controls. For example, in the case of financial

applications, the compliance with FFIEC guidelines for authentication

[15] requires that financial institutions implement applications that

mitigate weak authentication risks with multi-layered security con-

trol and multi-factor authentication.

Applicable industry standards for security need also to be captured by

the general security requirement checklist. For example, in the case

of applications that handle customer credit card data, the compliance

with the PCI DSS [16] standard forbids the storage of PINs and CVV2

data and requires that the merchant protect magnetic strip data in

storage and transmission with encryption and on display by mask-

ing. Such PCI DSS security requirements could be validated via source

code analysis.

Another section of the checklist needs to enforce general require-

ments for compliance with the organization’s information security

standards and policies. From the functional requirements perspec-

tive, requirements for the security control need to map to a specific

section of the information security standards. An example of such re-

quirement can be: “a password complexity of six alphanumeric char-

acters must be enforced by the authentication controls used by the

application.” When security requirements map to compliance rules a

security test can validate the exposure of compliance risks. If violation

with information security standards and policies are found, these will

result in a risk that can be documented and that the business has to

manage. Since these security compliance requirements are enforce-

able, they need to be well documented and validated with security

tests.

Security Requirements Validation

From the functionality perspective, the validation of security require-

ments is the main objective of security testing. From the risk man-

agement perspective, the validation of security requirements is the

objective of information security assessments. At a high level, the

main goal of information security assessments is the identification of

gaps in security controls, such as lack of basic authentication, autho-

rization, or encryption controls. More in depth, the security assess-

ment objective is risk analysis, such as the identification of potential

weaknesses in security controls that ensure the confidentiality, in-

tegrity, and availability of the data. For example, when the application

deals with personal identifiable information (PII) and sensitive data,

the security requirement to be validated is the compliance with the

company information security policy requiring encryption of such

data in transit and in storage. Assuming encryption is used to protect

the data, encryption algorithms and key lengths need to comply with

the organization encryption standards. These might require that only

certain algorithms and key lengths could be used. For example, a se-

curity requirement that can be security tested is verifying that only

allowed ciphers are used (e.g., SHA-256, RSA, AES) with allowed min-

imum key lengths (e.g., more than 128 bit for symmetric and more

than 1024 for asymmetric encryption).

From the security assessment perspective, security requirements can

be validated at different phases of the SDLC by using different arti-

facts and testing methodologies. For example, threat modeling focus-

es on identifying security flaws during design, secure code analysis

and reviews focus on identifying security issues in source code during

development, and penetration testing focuses on identifying vulnera-

bilities in the application during testing or validation.

Security issues that are identified early in the SDLC can be document-

ed in a test plan so they can be validated later with security tests. By

combining the results of different testing techniques, it is possible to

derive better security test cases and increase the level of assurance

of the security requirements. For example, distinguishing true vulner-

abilities from the un-exploitable ones is possible when the results of

penetration tests and source code analysis are combined. Considering

the security test for a SQL injection vulnerability, for example, a black

box test might first involve a scan of the application to fingerprint the

vulnerability. The first evidence of a potential SQL injection vulnerabili-

ty that can be validated is the generation of a SQL exception. A further

Testing Guide Introduction

validation of the SQL vulnerability might involve manually injecting

attack vectors to modify the grammar of the SQL query for an infor-

mation disclosure exploit. This might involve a lot of trial-and-error

analysis until the malicious query is executed. Assuming the tester

has the source code, she might learn from the source code analysis

on how to construct the SQL attack vector that can exploit the vul-

nerability (e.g., execute a malicious query returning confidential data

to unauthorized user).

Threats and Countermeasures Taxonomies

A threat and countermeasure classification, which takes into con-

sideration root causes of vulnerabilities, is the critical factor in ver-

ifying that security controls are designed, coded, and built to miti-

gate the impact of the exposure of such vulnerabilities. In the case

of web applications, the exposure of security controls to common

vulnerabilities, such as the OWASP Top Ten, can be a good starting

point to derive general security requirements. More specifically, the

web application security frame [17] provides a classification (e.g.

taxonomy) of vulnerabilities that can be documented in different

guidelines and standards and validated with security tests.

The focus of a threat and countermeasure categorization is to define

security requirements in terms of the threats and the root cause of

the vulnerability. A threat can be categorized by using STRIDE [18]

as Spoofing, Tampering, Repudiation, Information disclosure, Denial

of service, and Elevation of privilege. The root cause can be catego-

rized as security flaw in design, a security bug in coding, or an issue

due to insecure configuration. For example, the root cause of weak

authentication vulnerability might be the lack of mutual authenti-

cation when data crosses a trust boundary between the client and

server tiers of the application. A security requirement that captures

the threat of non-repudiation during an architecture design review

allows for the documentation of the requirement for the counter-

measure (e.g., mutual authentication) that can be validated later on

with security tests.

A threat and countermeasure categorization for vulnerabilities can

also be used to document security requirements for secure coding

such as secure coding standards. An example of a common coding

error in authentication controls consists of applying an hash func-

tion to encrypt a password, without applying a seed to the value.

From the secure coding perspective, this is a vulnerability that af-

fects the encryption used for authentication with a vulnerability

root cause in a coding error. Since the root cause is insecure coding

the security requirement can be documented in secure coding stan-

dards and validated through secure code reviews during the devel-

opment phase of the SDLC.

Security Testing and Risk Analysis

Security requirements need to take into consideration the severity

of the vulnerabilities to support a risk mitigation strategy. Assuming

that the organization maintains a repository of vulnerabilities found

in applications (i.e, a vulnerability knowledge base), the security

issues can be reported by type, issue, mitigation, root cause, and

mapped to the applications where they are found. Such a vulnera-

bility knowledge base can also be used to establish a metrics to an-

alyze the effectiveness of the security tests throughout the SDLC.

For example, consider an input validation issue, such as a SQL in-

jection, which was identified via source code analysis and report-

ed with a coding error root cause and input validation vulnerabil-

ity type. The exposure of such vulnerability can be assessed via a

penetration test, by probing input fields with several SQL injection

attack vectors. This test might validate that special characters are

filtered before hitting the database and mitigate the vulnerability.

By combining the results of source code analysis and penetration

testing it is possible to determine the likelihood and exposure of the

vulnerability and calculate the risk rating of the vulnerability. By re-

porting vulnerability risk ratings in the findings (e.g., test report) it is

possible to decide on the mitigation strategy. For example, high and

medium risk vulnerabilities can be prioritized for remediation, while

low risk can be fixed in further releases.

By considering the threat scenarios of exploiting common vulner-

abilities it is possible to identify potential risks that the application

security control needs to be security tested for. For example, the

OWASP Top Ten vulnerabilities can be mapped to attacks such as

phishing, privacy violations, identify theft, system compromise,

data alteration or data destruction, financial loss, and reputation

loss. Such issues should be documented as part of the threat

scenarios. By thinking in terms of threats and vulnerabilities, it

is possible to devise a battery of tests that simulate such attack

scenarios. Ideally, the organization vulnerability knowledge base

can be used to derive security risk driven tests cases to validate

the most likely attack scenarios. For example, if identity theft is

considered high risk, negative test scenarios should validate the

mitigation of impacts deriving from the exploit of vulnerabilities

in authentication, cryptographic controls, input validation, and au-

thorization controls.

Deriving Functional and Non Functional

Test Requirements

Functional Security Requirements

From the perspective of functional security requirements, the ap-

plicable standards, policies and regulations drive both the need for

a type of security control as well as the control functionality. These

requirements are also referred to as “positive requirements”, since

they state the expected functionality that can be validated through

security tests. Examples of positive requirements are: “the ap-

plication will lockout the user after six failed log on attempts” or

“passwords need to be a minimum of six alphanumeric characters”.

The validation of positive requirements consists of asserting the

expected functionality and can be tested by re-creating the testing

conditions and running the test according to predefined inputs. The

results are then shown as as a fail or pass condition.

In order to validate security requirements with security tests, se-

curity requirements need to be function driven and they need to

highlight the expected functionality (the what) and implicitly the

implementation (the how). Examples of high-level security design

requirements for authentication can be:

• Protect user credentials and shared secrets in transit and in

storage

• Mask any confidential data in display (e.g., passwords, accounts)

• Lock the user account after a certain number of failed log in

attempts

• Do not show specific validation errors to the user as a result of a

failed log on

• Only allow passwords that are alphanumeric, include special

characters and six characters minimum length, to limit the attack

surface

Testing Guide Introduction

• Allow for password change functionality only to authenticated

users by validating the old password, the new password, and the

user answer to the challenge question, to prevent brute forcing of

a password via password change.

• The password reset form should validate the user’s username and

the user’s registered email before sending the temporary

password to the user via email. The temporary password issued

should be a one time password. A link to the password reset web

page will be sent to the user. The password reset web page should

validate the user temporary password, the new password, as well

as the user answer to the challenge question.

Risk Driven Security Requirements

Security tests need also to be risk driven, that is they need to vali-

date the application for unexpected behavior. These are also called

“negative requirements”, since they specify what the application

should not do.

Examples of negative requirements are:

• The application should not allow for the data to be altered or

destroyed

• The application should not be compromised or misused for

unauthorized financial transactions by a malicious user.

Negative requirements are more difficult to test, because there is

no expected behavior to look for. This might require a threat ana-

lyst to come up with unforeseeable input conditions, causes, and

effects. This is where security testing needs to be driven by risk

analysis and threat modeling. The key is to document the threat

scenarios and the functionality of the countermeasure as a factor

to mitigate a threat.

For example, in the case of authentication controls, the following

security requirements can be documented from the threats and

countermeasure perspective:

• Encrypt authentication data in storage and transit to mitigate risk

of information disclosure and authentication protocol attacks

• Encrypt passwords using non reversible encryption such as using

a digest (e.g., HASH) and a seed to prevent dictionary attacks

• Lock out accounts after reaching a log on failure threshold and

enforce password complexity to mitigate risk of brute force

password attacks

• Display generic error messages upon validation of credentials to

mitigate risk of account harvesting or enumeration

• Mutually authenticate client and server to prevent non-repudiation

and Man In the Middle (MiTM) attacks

Threat modeling tools such as threat trees and attack libraries can

be useful to derive the negative test scenarios. A threat tree will

assume a root attack (e.g., attacker might be able to read other us-

ers’ messages) and identify different exploits of security controls

(e.g., data validation fails because of a SQL injection vulnerability)

and necessary countermeasures (e.g., implement data validation

and parametrized queries) that could be validated to be effective

in mitigating such attacks.

Deriving Security Test Requirements Through Use and Misuse

Cases

A prerequisite to describing the application functionality is to un-

derstand what the application is supposed to do and how. This can

be done by describing use cases. Use cases, in the graphical form

as commonly used in software engineering, show the interactions

of actors and their relations. They help to identify the actors in the

application, their relationships, the intended sequence of actions

for each scenario, alternative actions, special requirements, pre-

conditions and and post-conditions.

Similar to use cases, misuse and abuse cases [19] describe unin-

tended and malicious use scenarios of the application. These mis-

use cases provide a way to describe scenarios of how an attacker

could misuse and abuse the application. By going through the in-

dividual steps in a use scenario and thinking about how it can be

maliciously exploited, potential flaws or aspects of the application

that are not well-defined can be discovered. The key is to describe

all possible or, at least, the most critical use and misuse scenarios.

Misuse scenarios allow the analysis of the application from the at-

tacker’s point of view and contribute to identifying potential vulner-

abilities and the countermeasures that need to be implemented to

mitigate the impact caused by the potential exposure to such vul-

nerabilities. Given all of the use and abuse cases, it is important to

analyze them to determine which of them are the most critical ones

and need to be documented in security requirements. The identifi-

cation of the most critical misuse and abuse cases drives the doc-

umentation of security requirements and the necessary controls

where security risks should be mitigated.

To derive security requirements from use and misuse case [20] it is

important to define the functional scenarios and the negative sce-

narios and put these in graphical form. In the case of derivation of

security requirements for authentication, for example, the following

step-by-step methodology can be followed.

Step 1: Describe the Functional Scenario: User authenticates by

supplying a username and password. The application grants access

to users based upon authentication of user credentials by the appli-

cation and provides specific errors to the user when validation fails.

Step 2: Describe the Negative Scenario: Attacker breaks the au-

thentication through a brute force or dictionary attack of pass-

words and account harvesting vulnerabilities in the application.

The validation errors provide specific information to an attacker to

guess which accounts are actually valid registered accounts (user-

names). Then the attacker will try to brute force the password for

such a valid account. A brute force attack to four minimum length

all digit passwords can succeed with a limited number of attempts

(i.e., 10^4).

Step 3: Describe Functional and Negative Scenarios With Use and

Misuse Case: The graphical example in Figure below depicts the

derivation of security requirements via use and misuse cases. The

functional scenario consists of the user actions (enteringa user-

name and password) and the application actions (authenticating

the user and providing an error message if validation fails). The mis-

use case consists of the attacker actions, i.e. trying to break authen-

tication by brute forcing the password via a dictionary attack and by

guessing the valid usernames from error messages. By graphically

representing the threats to the user actions (misuses), it is possible

to derive the countermeasures as the application actions that mit-

igate such threats.

剩余223页未读，继续阅读

!@#$%^&

粉丝: 3
资源: 2

OWASP测试指南第四版：英文版

OWASP测试指南：Web应用渗透测试详解

OWASP测试指南2008：Web应用安全检测

OWASP测试指南：Web应用安全评估

OWASP安全测试指南v4（英文版）

owasp测试指南v4-中文版.zip

owasp测试指南 v4.0

OWASP测试指南：WEB应用渗透测试详解

OWASP测试指南：3.0全面详解与渗透测试方法

OWASP测试指南V3.0：Web应用渗透测试手册

OWASP测试指南V3.0：Web应用渗透测试详解

最新资源