Tabla de contenido

1. TESTING GUIDE FOREWORD.................................................................................................2

Tailoring and Prioritizing.................................................................................................................2
The Role of Automated Tools...........................................................................................................2
2. INTRODUCTION..........................................................................................................................2
The OWASP Testing Project............................................................................................................2
What is Testing?...........................................................................................................................2
Why Perform Testing?..................................................................................................................2
When to test?................................................................................................................................2
What to test?.................................................................................................................................2
Principles of Testing.........................................................................................................................2
Testing Techniques Explained..........................................................................................................2
Manual Inspections & Reviews....................................................................................................2
Threat Modeling...........................................................................................................................2
Source Code Review....................................................................................................................2
Penetration Testing.......................................................................................................................2
The Need for a Balanced Approach.............................................................................................2
A Note about Web Application Scanners.....................................................................................2
A Note about Static Source Code Review Tools..........................................................................2
Deriving Security Test Requirements...............................................................................................2
Security Requirements Documentation........................................................................................2
Security Requirements Validation................................................................................................2
Threats and Countermeasures Taxonomies..................................................................................2
Security Testing and Risk Analysis..............................................................................................2
Deriving Functional and Non-Functional Test Requirements..........................................................2
Functional security requirements.................................................................................................2
Risk-Driven Security Requirements.............................................................................................2
Deriving Security Requirements from Use and Misuse Cases.....................................................2
Security Tests Integrated in Development and Testing Workflows..................................................2
Security Testing During Development.........................................................................................2
Security Test Data Analysis and Reporting......................................................................................2
3. THE OWASP TESTING FRAMEWORK...................................................................................2
Overview..........................................................................................................................................2
Purpose and Benefits....................................................................................................................2
 Framework Characteristics...........................................................................................................2
Key Activities in the Framework..................................................................................................2
Phase 1: Before Development Begins..............................................................................................2
Phase 2: During Definition and Design............................................................................................2
Phase 3: During Development..........................................................................................................2
Phase 4: During Deployment...........................................................................................................2
Phase 5: Maintenance and Operations..............................................................................................2
4. WEB APPLICATION SECURITY TESTING............................................................................2

1. TESTING GUIDE FOREWORD

 We need a consistent, repeatable and defined approach to testing web applications.

 Many software development organizations do not include security testing as part of their
standard software development process.
 Security testing, by itself, isn’t a particularly good stand-alone measure of how secure an
application is, because there are an infinite number of ways that an attacker might be able to
make an application break, and it simply isn’t possible to test them all.
 The Development Guide will show your project how to architect and build a secure
application, the Code Review Guide will tell you how to verify the security of your
application’s source code, and this Testing Guide will show you how to verify the security
of your running application. I highly recommend using these guides as part of your
application security initiatives.

Tailoring and Prioritizing

• Developers should use this guide to ensure that they are producing secure code. These tests
should be a part of normal code and unit testing procedures.
• Software testers and QA should use this guide to expand the set of test cases they apply to
applications. Catching these vulnerabilities early saves considerable time and effort later.
• Security specialists should use this guide in combination with other techniques as one way
to verify that no security holes have been missed in an application.
• Project Managers should consider the reason this guide exists and that security issues are
manifested via bugs in code and design.

Try to focus on the security holes that are a real risk to your business. Try to contextualize risk in
terms of the application and its use cases.
“Tools do not make software secure! They help scale the process and help enforce policy.”
The Role of Automated Tools
Most importantly, these tools are generic - meaning that they are not designed for your custom code,
but for applications in general. That means that while they can find some generic problems, they do
not have enough knowledge of your application to allow them to detect most flaws. In my
experience, the most serious security issues are the ones that are not generic, but deeply intertwined
in your business logic and custom application design.

2. INTRODUCTION
The OWASP Testing Project

Writing the Testing Guide was challenging due to the need for consensus and content development
that allows practical application across different environments and cultures. Shifting the focus of
web application testing from penetration testing to integration within the software development life
cycle was another significant challenge.
Despite these difficulties, the project outcomes are highly satisfactory. Industry experts and security
professionals, including those from major companies, have validated the testing framework. This
framework aids organizations in testing their web applications to build reliable and secure software,
highlighting weaknesses and integrating appropriate testing techniques and technologies.
While not everyone may agree with all the decisions made, OWASP aims to influence culture
change over time through awareness and education based on consensus and experience.

What is Testing?
Testing in the Security Industry:
Often, security testing is done against a set of mental criteria that are not well-defined or complete.
This leads to the perception of security testing as a "black art."

Purpose of the Document:

The document aims to change the perception of security testing.
It seeks to make security testing accessible to people without in-depth security knowledge.

Why Perform Testing?

Purpose of the Document:
Helps organizations understand the components of a testing program for web applications.
Identifies steps to build and operate a testing program.
Comprehensive Security Program:
Provides a broad view of elements needed for a comprehensive web application security program.
Serves as a reference guide and methodology for aligning existing practices with industry best
practices.

Benchmarking and Resource Understanding:

Allows organizations to compare themselves with industry peers.
Helps understand the resources needed to test and maintain software.
Assists in preparing for audits.

When to test?
Current Ineffective Practices:
Testing often occurs only during the deployment phase, which is ineffective and costly.

Integrating Security in SDLC:

One of the best methods to prevent security bugs is to integrate security into each phase of the
Software Development Life Cycle (SDLC).
An SDLC is a structured framework for software development.

Adopting an SDLC:
If an SDLC is not in use, organizations should adopt one to improve their development process.
Security as an Integral Part:
Companies should ensure that security is an integral part of the SDLC.
Security tests should be included to ensure comprehensive coverage and effective controls
throughout development.

What to test?
Holistic Approach to Testing:
Software development involves people, process, and technology.
Effective testing must address all three factors to ensure comprehensive coverage.

Components of an Effective Testing Program:

People: Ensure adequate education and awareness.
Process: Ensure adequate policies and standards and verify adherence.
Technology: Verify the effectiveness of process implementation.

Importance of Comprehensive Testing:

Testing only the technical aspects will miss management or operational vulnerabilities.
A holistic approach helps identify root causes of defects and eradicates bugs early.

Analogy for Incomplete Testing:

Testing only some technical issues is like safety testing cars for frontal impact only, ignoring other
crucial safety aspects (e.g., roll testing, brake effectiveness, side impact, theft resistance).

Principles of Testing
Importance of SDLC:
Integrating security into each SDLC phase allows for a holistic approach to application security.
Each phase (define, design, develop, deploy, maintain) has specific security considerations.
Secure SDLC Frameworks:
Secure SDLC frameworks provide both descriptive (real-world usage) and prescriptive (how it
should work) advice.
Examples include BSIMM-V (descriptive) and OWASP’s OpenSAMM and ISO/IEC 27034
(prescriptive).

Early and Frequent Testing:

Detecting bugs early in the SDLC reduces cost and effort.
Educating development and QA teams about security issues is crucial.

Scope of Security:
Projects should classify information and assets to determine required security measures.
Legal requirements must be met, varying by region (e.g., Gramm-Leach-Bliley Act in the USA,
Directive 96/46/EC in the EU).
Mindset and Understanding:
Security testing requires thinking "outside of the box" and considering an attacker's perspective.
Accurate documentation of the application’s architecture and use cases is essential.

Use of Tools:
Tools are important but should not be relied upon exclusively.
Understanding the capabilities and limitations of tools is necessary to avoid misuse.

Detailed Review:
Superficial security reviews can instill a false sense of security.
Findings must be carefully reviewed to eliminate false positives.

Source Code Access:

Source code review can reveal vulnerabilities missed by black box testing.
Dynamic testing alone cannot cover the entire code base effectively.

Developing Metrics:
Metrics help track security trends and assess the effectiveness of security measures.
Metrics should indicate training needs, understanding of security mechanisms, and the trend of
security issues.

Documenting Test Results:

Test results should be formally documented, detailing actions taken, findings, and
recommendations.
Reports should be clear and useful for business owners, developers, and other stakeholders.
Using a test report template can ensure consistency and save time.

Testing Techniques Explained

Manual Inspections & Reviews
Overview:
Manual inspections involve human reviews that test the security implications of people, policies,
and processes, as well as technology decisions like architectural designs.
They typically involve analyzing documentation or conducting interviews with designers or system
owners.
These inspections can identify security concerns by understanding the rationale behind certain
implementations.

Advantages:
No Supporting Technology Required: Can be conducted without additional tools or technology.
Versatile: Can be applied to a wide range of situations and aspects of the software development
process.
Promotes Teamwork: Encourages collaboration and communication among team members.
Early Application: Can be used early in the Software Development Life Cycle (SDLC) to catch
issues before they become ingrained.
Disadvantages:
Time-Consuming: Can require significant time and effort, particularly for large and complex
systems.
Material Availability: Supporting materials such as documentation might not always be available.
Human Skill Requirement: Requires significant human expertise and analytical skills to be
effective.

Threat Modeling
Overview:
A process to help system designers identify potential security threats and develop mitigation
strategies.
Involves decomposing the application, classifying assets, exploring vulnerabilities and threats, and
creating mitigation strategies.
Follows standards like NIST 800-30 for risk assessment.

Advantages:
Attacker's Perspective: Provides a practical view of potential security threats from an attacker’s
perspective.
Flexibility: Can be adapted to different systems and situations.
Early SDLC Integration: Can be integrated early in the SDLC to preemptively address security
concerns.

Disadvantages:
New Technique: Still a relatively new approach in the industry.
No Guarantee: A well-developed threat model doesn’t automatically result in secure software.

Source Code Review

Overview:
Involves manually inspecting the source code of an application to identify security vulnerabilities
that may not be detected through other forms of testing.
Highly regarded for its ability to uncover concurrency problems, business logic flaws, access
control issues, and more.
Advantages:
Effectiveness: Highly effective at identifying a wide range of security issues.
Accuracy: Provides precise insights into the actual implementation of the code.
Efficiency: Can quickly identify issues, especially for experienced reviewers.
Disadvantages:
Skill Requirement: Requires highly skilled security developers.
Scope Limitations: May miss issues in compiled libraries and cannot easily detect runtime errors.
Source Code Discrepancies: The code being reviewed might differ from what is deployed.

Penetration Testing
Overview:
A method of testing the security of a running application by simulating attacks from an outsider's
perspective, without knowing the inner workings of the application.
Often used to find and exploit vulnerabilities, providing insights into the security posture of the
application.
Advantages:
Speed: Can be conducted relatively quickly and is often less expensive than other techniques.
Lower Skill Requirement: Requires a lower skill set compared to source code review.
Real-World Testing: Tests the application in its deployed state, providing a realistic assessment of
its security.
Disadvantages:
Timing: Typically performed late in the SDLC, which can be too late to address some issues cost-
effectively.
Limited Scope: Often focuses on immediate, visible issues rather than deep, systemic
vulnerabilities.
Key Points
Each technique has its unique advantages and disadvantages, making them suitable for different
stages of the SDLC and various aspects of security testing.
A comprehensive security testing program often combines multiple techniques to ensure a thorough
assessment.
The choice of techniques should be based on the specific needs of the project, available resources,
and the stage in the development process.

The Need for a Balanced Approach

Understanding the Challenge
Diverse Techniques: Numerous techniques exist for testing web application security, making it
challenging to determine which ones to use and when.
No One-Size-Fits-All Solution: There's no definitive answer regarding which techniques should be
employed. Instead, all techniques should be considered to cover the necessary areas adequately.
Pitfalls of Single Approaches
Overreliance on Penetration Testing: Many companies historically rely solely on penetration testing,
which, while useful, is often insufficient to address all security concerns, especially when applied
late in the SDLC.
Advocating for a Balanced Approach
Diversification of Techniques: A balanced approach integrates various techniques, from manual
reviews to technical testing, covering all phases of the SDLC.
Flexibility Depending on Circumstances: While a mix of techniques is ideal, circumstances may
dictate the use of a single approach, such as penetration testing when source code access is
unavailable.
Encouraging Critical Thinking: Testing parties should challenge assumptions and explore
possibilities for more comprehensive testing, even in constrained circumstances.
Tailoring to Specific Factors
Factors Influencing Approach: The maturity of the testing process and corporate culture impact the
choice of techniques.
Emphasis on Early Stages: Research and experience highlight the importance of prioritizing testing
efforts in the early stages of development.
Recommended Balanced Framework
Representation: A balanced testing framework should be proportional to the various phases of the
SDLC.
Emphasis on Early Stages: Companies should allocate more resources and emphasis to testing in the
early stages of development to catch issues sooner.
Key Points
A balanced approach to security testing involves integrating multiple techniques and adapting to
circumstances.
Overreliance on any single technique, such as penetration testing, may leave critical security issues
unaddressed.
Flexibility and critical thinking are essential in navigating testing challenges and maximizing the
effectiveness of security testing efforts.

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 believed that automating black box testing is not (or will ever be)
effective. However, highlighting these issues should not discourage the use of web application
scanners. Rather, the aim is to ensure the limitations are (…).
Example 1: Magic Parameters
In this scenario, a web application includes a hidden administrative backdoor accessible by
submitting a specific "magic" parameter value in the URL query string. The backdoor allows
unauthorized access to administrative functionalities. While this vulnerability is easily identifiable
through manual code inspection, it presents a significant challenge for automated web application
scanners due to the sheer number of possible parameter combinations that need to be brute-forced to
discover the hidden backdoor.
Example 2: Bad Cryptography
In this example, a developer implements a flawed cryptography scheme to authenticate users
between two web applications. The scheme involves generating a key using an insecure MD5 hash
function based on the user's username and date. This approach leads to predictable and easily
manipulable keys, allowing attackers to forge authentication tokens and impersonate any user.
While manual inspection would quickly reveal this security flaw, automated web application
scanners would likely overlook it, as they might only see changing hash values without
understanding the vulnerability in the key generation process.
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 program, 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 ensure a successful testing program, it is essential to understand the testing objectives, which are
defined by the security requirements. This section explores how to document these requirements for
security testing by deriving them from relevant standards, regulations, and both positive and
negative application requirements. It also explains how security requirements guide security testing
throughout the Software Development Life Cycle (SDLC) and how security test data can be used to
manage software security risks effectively.
Testing Objectives
Security testing aims to achieve two main objectives. Firstly, it verifies that security controls
function as intended, as outlined in security requirements that detail the functionality of these
controls. This includes ensuring the confidentiality, integrity, and availability of data and services.
Secondly, it validates that security controls are implemented with minimal vulnerabilities, covering
common vulnerabilities like the OWASP Top Ten and those identified during the SDLC through
assessments such as threat modeling, source code analysis, and penetration testing.

Security Requirements Documentation

The process of documenting security requirements begins with understanding the business
requirements. Business requirement documents outline the expected functionality of the application,
such as providing financial services or facilitating online purchases. The security section of these
documents emphasizes the protection of customer data and compliance with relevant regulations,
standards, and policies.
A comprehensive checklist of applicable regulations, standards, and policies aids in conducting
preliminary security compliance analysis for web applications. This includes identifying
compliance regulations based on the business sector and geographical location. Compliance
guidelines often translate into specific technical requirements for security controls, such as
implementing multi-factor authentication to mitigate weak authentication risks in financial
applications, as mandated by FFIEC guidelines.
Furthermore, the checklist enforces general requirements for compliance with the organization's
information security standards and policies. Functional requirements for security controls must
align with specific sections of these standards. For example, authentication controls may be
required to enforce a password complexity policy.
Security tests validate compliance with these requirements, identifying any violations that pose
risks to the organization. Since security compliance requirements are enforceable, they must be
thoroughly documented and validated through security tests.

Security Requirements Validation

Security requirements validation is essential both from a functionality and risk management
perspective. It involves ensuring that security controls operate effectively to maintain the
confidentiality, integrity, and availability of data.
During the Software Development Life Cycle (SDLC), various testing methodologies validate
security requirements. Threat modeling identifies flaws in design, while secure code analysis and
reviews uncover issues in source code. Penetration testing identifies vulnerabilities during testing or
validation.
Early identification of security issues allows for documentation in a test plan, facilitating validation
with security tests later on. Combining results from different testing techniques enhances security
test cases and increases assurance levels. For example, a SQL injection vulnerability can be
validated through a combination of black-box testing and source code analysis, enabling the
identification of true vulnerabilities and effective mitigation strategies.

Threats and Countermeasures Taxonomies

A threat and countermeasure classification system is crucial for ensuring that security controls
effectively address vulnerabilities. In web applications, common vulnerabilities like the OWASP
Top Ten serve as a foundation for deriving general security requirements.
Threat and countermeasure categorization aims to define security requirements based on identified
threats and root causes of vulnerabilities. Using frameworks like STRIDE, threats can be
categorized into Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and
Elevation of privilege. Root causes may include flaws in design, coding errors, or insecure
configurations.

This categorization helps document security requirements for various aspects, including architecture
design and secure coding standards. For instance, common coding errors in authentication controls,
such as inadequate hashing practices, can be identified and addressed through secure coding
standards and code reviews during the development phase of the Software Development Life Cycle
(SDLC).

Security Testing and Risk Analysis

Security testing and risk analysis are crucial components of ensuring robust security measures in
software applications. Security requirements should consider the severity of vulnerabilities to
formulate an effective risk mitigation strategy.
Organizations can leverage a vulnerability knowledge base to report and analyze security issues,
categorizing them by type, root cause, and mitigation efforts. This knowledge base enables the
establishment of metrics to assess the effectiveness of security tests throughout the Software
Development Life Cycle (SDLC).
By combining results from source code analysis and penetration testing, organizations can assess
the likelihood and exposure of vulnerabilities, leading to the calculation of risk ratings. These
ratings guide decisions on prioritizing remediation efforts based on the severity of vulnerabilities.
Considering potential threat scenarios, such as those outlined in the OWASP Top Ten
vulnerabilities, helps identify risks that require security testing. By simulating these attack
scenarios, organizations can validate the effectiveness of security controls. A well-maintained
vulnerability knowledge base facilitates the derivation of security risk-driven test cases to validate
the most likely attack scenarios, enabling organizations to mitigate high-risk threats effectively.

Deriving Functional and Non-Functional Test Requirements

Functional security requirements
known as "positive requirements", define the expected functionality of security controls, influenced
by applicable standards and regulations. These requirements, such as blocking users after multiple
failed attempts or defining the complexity of passwords, are validated through tests that recreate
specific conditions to verify their operation. Examples include protecting credentials in transit and
storage, locking accounts after multiple failed login attempts, and allowing password changes only
to multi-validated authenticated users.

Risk-Driven Security Requirements

Security tests must be driven by risk analysis to validate the application against unexpected
behaviors, referred to as "negative requirements." These specify what the application should not do,
such as preventing data alteration or unauthorized financial transactions. Negative requirements are
challenging to test due to the lack of expected behavior, requiring threat analysts to devise
unforeseeable input conditions.
Examples of Negative Requirements:
• Prevent data alteration or destruction.
• Prevent misuse for unauthorized financial transactions.
To address these, security testing should document threat scenarios and countermeasures to mitigate
risks. For instance, authentication security requirements include encrypting data, locking accounts
after failed attempts, and using generic error messages.

Deriving Security Requirements from Use and Misuse Cases

Understanding application functionality through use cases helps define what the application should
do. Misuse cases describe how an attacker could exploit the application, providing a way to identify
potential flaws. By analyzing both use and misuse scenarios, critical security requirements and
necessary controls can be documented to mitigate risks.
Steps to Derive Security Requirements:
• Functional Scenario: User authenticates with username and password.
• Negative Scenario: Attacker exploits vulnerabilities to guess valid usernames and brute
force passwords.
• Graphical Representation: Use and misuse cases depict user actions and potential threats,
leading to countermeasures.
• Elicit Security Requirements: Define requirements such as password complexity, account
lockout policies, and generic error messages.
These requirements should be documented and tested to ensure effective risk mitigation.

Security Tests Integrated in Development and Testing Workflows

Security Testing During Development

1. Importance and Methods:

Static Analysis: Developers should use static code analysis tools to identify potential vulnerabilities
in the source code early.
Dynamic Testing: Security unit tests can be employed to verify the runtime behavior of components
and ensure they function securely.
Secure Code Review: Senior developers, often security experts, should lead secure code reviews to
validate code before integration into the application build.

2. Workflow and Responsibility:

Validation: Before integrating new or modified code into the application build, results from static
and dynamic analyses should be reviewed.
Approval Process: Senior developers validate the security of the code and decide if it's ready for
integration. This process can be managed through workflow tools, which also track fixes for
security bugs.

Security Testing During Testing Phase

**1. Integrated System Testing:

Levels of Testing: After development, the application undergoes integrated and system-level testing,
where its overall security is assessed.
Types of Testing:
White Box Testing: Involves source code analysis to identify vulnerabilities.
Black Box Testing: Includes penetration testing without knowledge of the internal workings of the
application.
Gray Box Testing: Uses partial knowledge of the application’s internal details to test its security.
Responsibility: Typically, testing engineers, not developers, perform these tests. They have
specialized knowledge in security testing and use documented security test cases.
**2. Operational and Validation Testing:
User Acceptance Testing (UAT): In the UAT environment, which closely mirrors production, testers
perform security assessments to identify and mitigate vulnerabilities that could be exploited by
attackers.
Final Validation: Security issues found at this stage are discussed and addressed according to risk
management procedures before the application is deployed.

Developer's Security Tests

---------------------------------------
**1. Coding Phase:

Unit Testing: Developers should incorporate security into their unit tests to validate compliance
with secure coding standards.
Security Test Suites: Developers should build security test cases into their existing unit testing
frameworks, derived from use and misuse cases.
Static and Dynamic Analysis: Utilize tools integrated into IDEs for continuous security validation
during development.
**2. Framework and Tools:

Tools: Unit testing frameworks like Junit, Nunit, and CUnit can be adapted for security testing.
Focus Areas: Security tests at the unit level should cover input validation, access control,
encryption, session management, and error handling.
Documentation: Procedures and security test cases should be documented to guide the testing of
components, particularly for common vulnerabilities.

Functional Testers' Security Tests

------------------------------------------------------
**1. Integrated System Tests:
Defense-in-Depth: Security at different layers is validated, ensuring components integrate securely
and potential vulnerabilities are tested.
Simulated Attacks: Real attack scenarios are tested, validating whether vulnerabilities can be
exploited by attackers.

**2. Manual and Advanced Techniques:

Initial Tests: Basic security tests can be performed manually, including injecting attack vectors and
checking for vulnerabilities like SQL injection.
Advanced Tools: More complex tests might involve tools and techniques such as fuzz testing,
reverse engineering, and fault injection.

**3. User Acceptance Testing (UAT):

Configuration Testing: In UAT, testing focuses on the security configuration of the operational
environment, identifying potential high-risk vulnerabilities related to system setup and deployment.

In summary, security testing should be integrated throughout the software development lifecycle,
from development through to system integration and user acceptance testing. Developers should use
both static and dynamic analysis tools during development, while testing engineers should perform
thorough security assessments at the system level. Effective security testing includes unit tests,
secure code reviews, penetration testing, and validation in the operational environment.

Security Test Data Analysis and Reporting

3. THE OWASP TESTING FRAMEWORK

Overview
This section outlines a flexible testing framework designed to enhance software security across
various stages of the software development life cycle (SDLC). The framework is intended as a
reference that organizations can adapt to their specific needs and integrate into their development
processes.
Purpose and Benefits
Cost Efficiency: Addressing security early in the SDLC is economically advantageous. Issuing
security bulletins and patches is costly for both vendors and customers. By integrating security
testing throughout the development process, organizations can reduce the need for expensive post-
release fixes.
Beyond Penetration Testing: While penetration testing has its place, it is limited in scope and relies
heavily on the tester’s skill. A comprehensive approach involves testing security throughout the
development stages rather than waiting until the application is fully developed.

Framework Characteristics
Non-Prescriptive: The framework is designed to be adaptable, allowing organizations to tailor it to
fit their development methodology and culture.
Strategic Approach: It focuses on building a complete, end-to-end testing process that covers all
phases of development, from initial planning to maintenance, rather than only tactical or specific
areas of testing.

Key Activities in the Framework

Before Development Begins:

Planning and preparing the testing environment.
Defining security requirements and testing criteria.

During Definition and Design:

Integrating security requirements into the design.
Reviewing design documents for potential security issues.

During Development:
Conducting static and dynamic analysis of the code.
Implementing secure coding practices.
Performing security unit tests and secure code reviews.

During Deployment:
Testing the integrated system for security vulnerabilities.
Conducting penetration testing and validating security controls in a staging environment.

Maintenance and Operations:

Regularly updating and testing security controls.
Monitoring the application for new vulnerabilities and addressing them promptly.

Adaptability to Development Methodologies

The framework is compatible with various development methodologies, including Rational Unified
Process, extreme and Agile development, and traditional waterfall methodologies. It offers a generic
model that can be customized to align with an organization's specific process.
Overall, this framework emphasizes the importance of integrating security testing throughout the
SDLC, rather than relying solely on post-development penetration testing, to improve the security
quality of software efficiently.

Phase 1: Before Development Begins

Define a Secure SDLC: Establish an SDLC that incorporates security considerations at every stage.
Review Policies and Standards: Ensure the existence of clear, documented policies and standards
for secure coding and development practices relevant to the technologies in use.
Develop Measurement and Metrics Criteria: Plan and define metrics to monitor and measure
security-related defects, providing visibility into both process and product quality.

Phase 2: During Definition and Design

Review Security Requirements: Define and test security requirements to ensure clarity and
completeness, addressing aspects like user management, authentication, data confidentiality, and
compliance.
Review Design and Architecture: Document and test the design and architecture to ensure they meet
security requirements. Identify potential flaws early, such as improper placement of authorization
decisions or data validation.
Create and Review UML Models: Develop and review UML models to confirm the application’s
workings and address any security weaknesses with alternative approaches.
Create and Review Threat Models: Conduct threat modeling to develop realistic threat scenarios
and ensure appropriate mitigations are in place. Revisit design and architecture if necessary to
address uncovered threats.
Phase 3: During Development
Code Walkthrough: Perform a high-level walkthrough of the code with developers and system
architects to understand code logic and flow. This is not a detailed review but aims to grasp the
overall structure.
Code Reviews: Conduct static code reviews using checklists for business requirements, technical
exposures, language-specific issues, and industry regulations. This phase is crucial for identifying
security defects and ensuring the code adheres to best practices.

Key Points
Non-Prescriptive Framework: This framework is flexible and can be adapted to fit various
development methodologies and organizational cultures.
End-to-End Security: Security is integrated at each phase of development rather than relying solely
on post-development testing, leading to better overall software security.
Early Identification: Identifying security issues early in the design and development phases is more
cost-effective and easier to address than fixing them post-deployment.

Phase 4: During Deployment

Application Penetration Testing

Conduct penetration testing after deployment to verify that the application is secure and to identify
any missed vulnerabilities. This testing acts as a final safeguard before the application goes live.

Configuration Management Testing

Assess the deployment configuration of the infrastructure to ensure no aspects remain at default
settings, which could pose security risks. Even if the application itself is secure, improper
configurations can introduce vulnerabilities.

Phase 5: Maintenance and Operations

Operational Management Reviews

Implement a management process to oversee the operational aspects of both the application and its
infrastructure. This involves continuous monitoring and management to maintain security integrity.
Periodic Health Checks:
Perform regular health checks (monthly or quarterly) on the application and infrastructure to detect
and mitigate new security risks. This ensures ongoing compliance with security standards and the
maintenance of security levels.
Change Verification:
After changes are approved, tested in QA, and deployed, verify that these changes have not
compromised security. This step should be integrated into the change management process to
maintain the application’s security posture.

4. WEB APPLICATION SECURITY TESTING

Identity Management Testing
Testing Role Definitions (OTG-IDENT-001)
Overview
In modern enterprises, defining system roles is common for managing users and authorizations to
system resources. Typically, system implementations include at least two roles:
Administrators: This role provides access to privileged and sensitive functionality and information.
Regular users: This role provides access to standard business functionality and information.
Well-developed roles should align with the business processes supported by the application.
It's important to remember that strict authorization is not the only way to manage access to system
objects. In more trusted environments, where confidentiality is not critical, softer controls like
application workflow and audit logging can support data integrity without restricting user access or
creating complex role structures. The Goldilocks principle applies to role engineering: defining too
few broad roles can expose unnecessary functionality, while too many tightly tailored roles can
restrict necessary access.
Test Objectives
The objective is to validate that the system roles within the application sufficiently define and
separate each system and business role, ensuring appropriate access to system functionality and
information.
How to Test
Role-Permission Matrix: Develop a matrix comparing roles versus permissions, either
independently or with the help of system developers or administrators.
Enumerate all roles that can be provisioned.
Explore the permissions that can be applied to objects, including any constraints.
Validate an existing matrix if provided, or generate it if absent, ensuring it meets the application's
access policy.
Tools
Manual testing is the most thorough and accurate approach. However, spidering tools can also be
helpful. Log in with each role in turn and spider the application, ensuring the logout link is excluded
from spidering.
Remediation
To address issues, consider the following forms of remediation:
Role Engineering
Mapping Business Roles to System Roles
Separation of Duties

Testing User Registration Process (OTG-IDENT-002)

Overview
User registration processes vary in their level of automation and the identity requirements they
impose. Some systems automate user registration to manage large user bases efficiently, while
others, especially corporate applications, might handle provisioning manually. The goal is to align
identity requirements with the business and security needs of the system.

Test Objectives

Identity Requirements Alignment: Ensure that user registration identity requirements match
business and security expectations.
Registration Process Validation: Confirm the effectiveness and security of the registration process.
How to Test
Identity Requirements Validation:
• Determine if anyone can register.
• Identify if registrations are manually vetted or automatically provisioned.
• Check if the same person or identity can register multiple times.
• Assess if users can register for various roles or permissions.
• Evaluate the proof of identity required for registration.
• Verify if registered identities are authenticated.
Registration Process Validation:
• Assess if identity information can be easily forged.
• Check if identity information exchange can be manipulated during registration.
Example
WordPress: Requires only an accessible email address for registration.
Google: Requires name, date of birth, country, mobile phone number, email address, and
CAPTCHA response. Email and mobile number are verified, offering stricter identity requirements
compared to WordPress.
Tools
An HTTP proxy can be useful for testing the registration process.

Remediation
Implement identity and verification requirements that align with the security needs of the system
and the information the credentials will protect.

Test Account Provisioning Process (OTG-IDENT-003)

Overview
The process of provisioning accounts can be vulnerable if proper identification and authorization
procedures are not applied. This presents a risk where attackers could potentially create valid
accounts without appropriate controls.

Test Objectives

Verify Account Provisioning: Determine which accounts or roles can provision other accounts and
the types of accounts they can provision.
How to Test

Account Provisioning:
• Identify roles with the ability to provision users.
• Evaluate the types of accounts these roles can provision.
• Verify if provisioning requests undergo any verification, vetting, and authorization.
• Assess if de-provisioning requests are similarly verified, vetted, and authorized.
Administrative Capabilities:

• Determine if an administrator can provision other administrators or only regular users.

• Check if any user can provision accounts with higher privileges than their own.
 • Investigate if an administrator or user can de-provision themselves.
• Examine the management of resources owned by de-provisioned users:
• Are files or resources deleted?
• Is access to these resources transferred to another user?

Remediation
Ensure that provisioning and de-provisioning processes include appropriate verification, vetting,
and authorization steps to align with security policies. Manage de-provisioned user resources
effectively to prevent unauthorized access or data loss.

Testing for Account Enumeration and Guessable User Account (OTG-IDENT-

004)

Overview
This test examines whether an application’s authentication mechanism can be exploited to
gather valid usernames. This information can facilitate brute force attacks, where attackers
attempt to find passwords for known usernames. Applications often unintentionally reveal
whether a username exists through their responses to authentication attempts.

Objective
Determine if the authentication mechanism allows the collection of valid usernames by
providing different responses for valid and invalid credentials.

How to Test

1. Testing with Valid Username and Correct Password:

o Submit a valid username and correct password.
o Record the server’s response (e.g., HTTP 200 response and response length).
o Expected Result: Successful authentication with consistent information.
2. Testing with Valid Username and Incorrect Password:
o Submit a valid username with an incorrect password.
o Record the error message and server response.
o Expected Result: Generic error message (e.g., "Authentication failed")
without revealing username existence.
3. Testing with Invalid Username and Incorrect Password:
o Submit an invalid username with an incorrect password.
o Record the server’s response and error message.
o Expected Result: Error message indicating generic failure (e.g., "User not
recognized") without revealing username existence.

Example

 Invalid Username: The server might respond with “User not recognized.”
  Valid Username with Wrong Password: The server might respond with “The
password is not correct.”

Analysis
If responses differ between valid and invalid usernames (e.g., different error messages or
response lengths), the application may inadvertently reveal valid usernames.

Tools

 WebScarab: Monitor HTTP responses for variations in response messages and

lengths during authentication attempts.

Remediation
Ensure that authentication responses do not differentiate between invalid usernames and
incorrect passwords. Provide a uniform error message for all authentication failures to
avoid leaking information about username validity.

Testing for Weak or Unenforced Username Policy (OTG-IDENT-005)

Overview
Usernames often follow predictable patterns, making them easy to guess and potentially
exposing the application to account enumeration attacks. Attackers can exploit these
patterns along with the application’s error messages to discover valid usernames.

Test Objectives

1. Assess Username Structure: Determine if the naming conventions for user

accounts are predictable and susceptible to guessing.
2. Evaluate Error Messages: Check if the application's error messages reveal
whether a username is valid or invalid.

How to Test

1. Identify Username Patterns:

o Analyze the structure of account names (e.g., first initial + last name).
o Determine if the pattern is consistent across usernames.
2. Evaluate Application Responses:
o Test with valid and invalid usernames.
o Observe differences in the application’s responses to valid vs. invalid
usernames.
3. Enumerate Valid Usernames:
o Use variations in responses to identify valid usernames.
o Apply account name dictionaries to systematically test and identify valid
usernames.

Remediation
 Implement generic and consistent error messages for all invalid login attempts (e.g.,
"Invalid credentials") to prevent revealing the validity of usernames.
 Avoid predictable naming conventions for usernames to reduce the risk of account
enumeration.