Your Gateway to Exciting Quality Assurance!

OWASP top 10 security testing approach

testing approach
The OWASP Top 10 is a powerful resource for understanding and managing application security risks. It represents a broad consensus on the most critical web application security flaws that developers and testers should focus on. By adopting the OWASP Top 10 approach to security testing, organizations can improve their ability to find and fix security vulnerabilities in their web apps and APIs.

In this post, we’ll provide a comprehensive guide to using the OWASP Top 10 methodology for security testing. We’ll cover:
  • What is the OWASP Top 10 and why it matters
  • How to use the OWASP Top 10 for security testing
  • Detailed analysis of testing for each vulnerability category
  • Tips for prioritizing and interpreting results
  • How to integrate OWASP Top 10 testing into your SDLC

What is the OWASP Top 10?

The OWASP Top 10 list represents a broad consensus on the most important web application security risks. It is put together by a team of security experts from around the world who contribute their expertise to identify the top vulnerabilities typically found in real-world applications.

The Top 10 list is updated every few years to reflect the changing threat landscape and new vulnerabilities that emerge. The current list dates from 2021 and contains the following vulnerability categories:
  • A01:2021 – Broken Access Control
  • A02:2021 – Cryptographic Failures
  • A03:2021 – Injection
  • A04:2021 – Insecure Design
  • A05:2021 – Security Misconfiguration
  • A06:2021 – Vulnerable and Outdated Components
  • A07:2021 – Identification and Authentication Failures
  • A08:2021 – Software and Data Integrity Failures
  • A09:2021 – Security Logging and Monitoring Failures
  • A10:2021 – Server-Side Request Forgery (SSRF)

The OWASP Top 10 represents the basics of web app security testing. If you’re new to app sec, focusing on these top risks is the best way to start improving your security posture.

Why the OWASP Top 10 Matters for Security Testing

Here’s why the OWASP Top 10 is so important for security testing:
It helps set minimum security standards. Many application security policies and compliance frameworks incorporate or are aligned with the OWASP Top 10. It provides a baseline of testing coverage.
It helps drive better software development. The OWASP Top 10 gives developers a concrete list of security flaws to avoid in their code. This leads to more secure software.
It helps benchmark application security. By tracking how many OWASP Top 10 issues you find during testing, you can benchmark security over time and compare against industry averages.

In short, the OWASP Top 10 represents an application security testing checklist grounded in real-world data. By aligning your program with OWASP, you can focus on the risks that matter most.

How to Use OWASP Top 10 for Security Testing

Now, let’s look at how to apply the OWASP Top 10 during security testing activities. The key steps include:

Step 1: Map Test Coverage to OWASP Top 10
Start by creating a test plan that maps your available testing techniques and tools to the OWASP Top 10. The goal is to have coverage for intentionally testing each of the vulnerability categories.

For example, you may use:
  • Automated scanners to detect injection flaws, security misconfiguration, and other coding errors.
  • Manual penetration testing to validate broken access control, cryptographic issues, and authentication problems.
  • Code review focused on input validation, access control, and logging/monitoring flaws.

Step 2: Perform OWASP Top 10 Focused Testing
With your test plan mapped to the OWASP Top 10, execute each testing activity and rigorously document results. Look for evidence of vulnerabilities in each OWASP category during testing.
Make sure to cover all parts of the application, including backend components, APIs, front-end, etc. Also test authentication, access controls, and business logic flows.

Step 3: Prioritize and Interpret Results
With results in hand, prioritize remediation based on risk:
  • Identify vulnerabilities that allow remote code execution, leakage of sensitive data, or complete system compromise. These should be fixed immediately.
  • Vulnerabilities that could be exploited to bypass access controls or compromise user accounts also require urgent attention.
  • Flaws like poor error handling, logging issues, or security misconfigurations may be lower risk. Still address these, but focus on the critical risks first.

Also look for overlapping or amplified risk where multiple lower risk vulnerabilities could chain together for more impact.

Step 4: Re-test and Track Metrics
Retest applications after fixes to verify the top priority vulnerabilities are properly addressed. Track your OWASP findings metrics over time to monitor improvement.
Measuring things like percentage of applications tested for each OWASP category, number of vulnerabilities discovered, and average time to remediate helps benchmark security program effectiveness.

Step 5: Integrate into Development Processes
Finally, integrate OWASP Top 10 testing into your application development lifecycle. For example:
  • Train developers on the OWASP Top 10 so they can avoid these flaws while coding.
  • Perform QA testing focused on the Top 10 during development sprints.
  • Make OWASP Top 10 testing a requirement at release gates before production deployment.
Building these steps into your SDLC helps catch and fix bugs earlier, reducing cost and risk.

Detailed Testing Guidance for Each OWASP Top 10 Vulnerability Category

Now that we’ve covered the overall process, let’s dig into testing guidance and examples for each category in the OWASP Top 10.

A01:2021 – Broken Access Control
Broken Access Control flaws allow attackers to exploit poor authorization and access control checks to access unauthorized functionality and data. Some examples include:
  • Bypassing access control checks by modifying URLs, cookies, hidden form fields, etc.
  • Users accessing data of other users or restricted files they should not have access to.
  • Elevation of privilege. A lower privileged user gaining higher level permissions they should not have.

How to Test:
  • Try to access restricted pages as an unauthenticated user by modifying parameters like IDs.
  • Check for vulnerabilities like IDOR (Insecure Direct Object Reference) that allow accessing other user’s data.
  • Test auto-complete features to ensure they don’t reveal unauthorized data.
  • Check pagination controls – attackers can sometimes access out of bounds data.
  • Try to create new administrative accounts or elevate privileges of existing accounts.
  • Spider and fuzz all parameters to find hidden endpoints.

A02:2021 - Cryptographic Failures
Flaws in encryption, hashing, certificates, keys, and other cryptography related functions can lead to compromise of data and accounts:
  • Weak or custom encryption algorithms used instead of industry standard ones.
  • Invalid SSL certificates accepted without verification.
  • Unprotected cryptographic keys embedded in code or stored improperly.
  • Poor key management like reuse, weak generation, or lack of rotation.

How to Test:
  • Check there is no use of weak homemade encryption functions or algorithms.
  • Verify certificate validation on all SSL connections.
  • Look for hardcoded keys and passwords in code and configurations.
  • Test key lengths match cryptographic recommendations (e.g. 2048 bit+ RSA keys).
  • Check for proper key generation, storage, and rotation policies.

A03:2021 - Injection
Injection flaws allow attackers to pass malicious code into a system to trigger unintended behavior or access unauthorized data. Types include:
  • SQL injection – inserting rogue SQL queries.
  • OS command injection – running system level commands.
  • LDAP injection – malicious LDAP queries.
  • Server Side Template Injection (SSTI) – injecting template logic.

How to Test:
  • Fuzz all inputs and parameters – forms, URLs, headers, cookies, APIs.
  • Try entering special chars like single quotes, semicolons to break out of data context.
  • Attempt to extract data by chaining payloads using UNION SELECT and piggyback queries.
  • Test for blind injection by triggering time delays or making conditional responses.
  • Try to inject OS commands like pinging localhost or listing directory contents.
  • Check for SSTI by entering template syntax like {{7*7}} in input fields.

A04:2021 - Insecure Design
Insecure design flaws stem from not following best practices for authentication, session management, access control and other critical areas. Examples:
  • Storing passwords in plain text or with weak hashes.
  • Not implementing sufficient anti-automation protections like rate limiting, captchas, locking accounts.
  • Permitting weak passwords, no MFA, insecure password reset flows.
  • Lack of encryption for sensitive data.
  • Unsafe client-side data storage like HTML5 localStorage.

How to Test:
  • Check password hashes using cracking tools to spot weak algorithms.
  • Flood login forms and password reset flows with automation scripts to find flaws.
  • Review data persistence mechanisms like encrypting data at rest.
  • Examine remember me / forgot password token generation and storage.
  • Check for reliance on client side security controls like HTML form validation.

A05:2021 - Security Misconfiguration
Misconfigured security settings, overly permissive defaults, unnecessary services enabled create opportunities for exploitation:
  • Unnecessary ports left open, default accounts with unchanged passwords.
  • Error messages revealing stack traces and sensitive system details.
  • Unsecured cloud storage buckets permissions allow anonymous access.
  • User able to access old debug/test pages never removed.

How to Test:
  • Scan all ports to look for unneeded services with vulnerabilities.
  • Check cloud storage permissions to confirm private.
  • Walk through site as unauthenticated outsider to find anything missed.
  • Examine error handling revealing too much information.
  • Review permissions and access controls to spot overly permissive settings.

A06:2021 - Vulnerable and Outdated Components
Apps and APIs depending on outdated third party components with known vulnerabilities can be exploited:
  • Unpatched vulnerabilities in libraries and dependencies like Log4j or Spring Framework.
  • Out of support software like OSes, frameworks, apps no longer receiving fixes.
  • Lack of monitoring/alerting around new third party vulnerabilities.

How to Test:
  • Maintain a manifest of all third party libraries/components used.
  • Monitor sources like NVD for vulnerabilities in components.
  • Regularly update/patch components or restrict to actively supported versions.
  • Dynamic scanning to detect use of vulnerable components.
  • Review dependency trees and licenses to identify risks.

A07:2021 - Identification and Authentication Failures
Flawed authentication flows and session management often lead to account takeovers:
  • Permitting weak, default or duplicate passwords.
  • Broken MFA implementation - SMS intercept, 2FA bypass.
  • Session management flaws - exposure of session IDs, lack of rotation and revocation.
  • Password reset and remember me flaws allowing account takeover.

How to Test:
  • Password spraying attacks - repeatedly try common passwords on many accounts.
  • Test account lockout mechanisms - intentionally trigger lockouts.
  • Intercept MFA tokens sent over SMS/email and try to bypass.
  • Check remember me functionality tied to IP address or properly rotates tokens.
  • Capture session IDs and try using them from other systems.

A08:2021 - Software and Data Integrity Failures
Code and data integrity issues compromise security:
  • Lack of binary hardening like ASLR, buffer overflow protections.
  • Missing code signature validation checks and enforcement.
  • Lack of tamper protections for data like hashes or digital signatures.
  • Run programs with excessive privileges allowing changes to code and configs.

How to Test:
  • Check for unsafe C/C++ functions vulnerable to buffer overflows.
  • Test that application code is properly signed and signature validated.
  • Look for evidence of memory protections like ASLR and stack canaries enabled.
  • Examine data like credentials are hashed and salts used.
  • Verify least privilege principle - services run with minimum permissions.

A09:2021 - Security Logging and Monitoring Failures
Inability to detect, respond or learn from breaches due to poor logging and monitoring:
  • Not logging authentication events, access control changes and other key security events.
  • Insecure logging transmission over unencrypted channels.
  • Logs stored unprotected allowing tampering or deletion.
  • Lack of alerting thresholds and monitoring to spot attacks.

How to Test:
  • Check logs capture sufficient detail during signups, transactions and privilege changes.
  • Examine how logs are transmitted - encrypted connections, authenticated loggers.
  • Validate tamper protections of centralized log repositories.
  • Test alerting rules fire on expected attack scenarios like repeated authorization failures.
  • Verify access to logs is restricted to security team.

A10:2021 – Server-Side Request Forgery (SSRF)
Server side request forgery tricks backend servers into making unintended requests to internal systems or external locations:
  • User input passed unsanitized to functions reaching out to other systems.
  • API endpoints can be manipulated to connect to localhost, cloud services, open ports.
  • Attackers pivot from app servers to pivot deeper into internal network.

How to Test:
  • Fuzz all server side requests - APIs, webhooks, etc. - to look for SSRF flaws.
  • Manipulate input values controlling IP address, ports, protocols.
  • Test for open ports allowing connections to AWS metadata service.
  • Try proprietary protocols like gopher:// if HTTP blocked.
  • Input filter bypass like IP blacklist, obfuscation, localslop ip values.

Prioritizing and Interpreting OWASP Top 10 Results

Finding vulnerabilities is just the first step. Properly prioritizing remediation and interpreting results also matters. Here are some key points:
  1. Prioritize the Critical Risks:The risks like remote code execution, leakage of highly sensitive data, and flaws enabling total system compromise should be fixed immediately. Verified exploitable issues get top priority.
  2. Consider Likelihood and Impact: Factors like remote versus local attack vectors, anonymous versus authenticated access, trust boundaries crossed change severity. Think like an attacker.
  3. Don’t Rely on Automated Tools Alone: Scanner results require manual verification and interpretation based on the application's functionality and business logic.
  4. Understand Technical and Business Risk: Look at technical security concerns as well as the business impacts like financial, reputational, compliance problems.
  5. Watch for Amplified Risk: Multiple lower risk issues together can multiply impact. For example, broken access controls combined with injection flaws.
  6. Track Trends: Monitoring the types of flaws over time shows if progress is being made and where to focus.
  7. Get Visibility to the Source Code: Access to source code during review allows deeper validation and remediation of issues.
By properly prioritizing and interpreting results based on OWASP Top 10 testing, you get the most value in improving your application security.

Integrating OWASP Top 10 into Your Application Security Program

Here are some ways to integrate OWASP Top 10 testing into your application security program:
  1. Bake into Secure Development Practices:Train developers on OWASP Top 10. Create cheat sheets. Discourage use of risky APIs prone to vulnerabilities.
  2. Make OWASP Top 10 Part of Your Security Testing Standards: Standard security test types should map to finding OWASP Top 10 issues.
  3. Include in Your Application Security Requirements: Add OWASP Top 10 coverage to all application security requirements, policies, and standards.
  4. Build into Security Gates: Require OWASP Top 10 testing results before approvals at development gates – e.g. new development, design reviews, pre-production releases.
  5. Track as a KPI: Metrics like percentage of applications passing OWASP Top 10 testing, critical vulnerabilities found and fixed provide visibility into progress.
  6. Prioritize Around OWASP Top 10: Use the OWASP Top 10 as the framework for prioritizing your remediation efforts based on risk.
  7. Train According to OWASP Top 10: Educate developers, testers, managers and others on identifying these priority risks during activities.

By aligning people, process, and technology to the OWASP Top 10, you get the most effective application security program.
The OWASP Top 10 represents the minimum standard for testing the most common and dangerous web application security flaws. This comprehensive guide covered:
  • The key value and purpose of the OWASP Top 10
  • How to leverage the Top 10 for security testing
  • Detailed testing guidance for each category
  • Prioritizing and interpreting results
  • Integrating OWASP Top 10 testing into your SDLC
Use the OWASP Top 10 as your blueprint for building a balanced application security program. Combine automated scanning, manual penetration testing, code review, developer training, and rigorous security gates anchored to the Top 10. This provides cost-effective assurance for finding and fixing the flaws that matter most.
Stay tuned for future posts that will dive into each OWASP Top 10 risk category in more detail. I’ll provide code examples, case studies, recommended tools, and remediation best practices.
Let me know if you have any other topics related to the OWASP Top 10 methodology you would like covered. I aim to provide the most comprehensive and practical guidance for building security into the development lifecycle.