The OWASP Top 10: What They Are and How to Test Them

Web applications often handle vast amounts of data, from personal user details to sensitive corporate information. As these applications grow in complexity and importance, they also become primary targets for threat actors.

Cybercriminals frequently attack web applications and exploit common weaknesses that help them achieve their nefarious aims, such as stealing data, corporate espionage, or simply causing disruption for the sake of it.

With the rise of agile development and continuous delivery, there’s pressure to release new features quickly. As a result, dev teams sometimes overlook security in favor of speed and flexibility.

The OWASP Top 10 is a crucial resource that represents a broad consensus about the most important security risks to web applications.

This article takes a deep dive into the OWASP Top 10 and advises on how to test your web applications for susceptibility to these security risks.

The OWASP Top 10 Latest Edition

The OWASP (Open Web Application Security Project) Top 10 started back in 2003 as a way to highlight the most critical web application vulnerabilities based on real-world data and expert consensus.

As web-based applications became integral to digitally transformed business operations, an increasing need for improved security also arose.

Over the years, the OWASP Top 10 has undergone periodic revisions to stay relevant to the evolving threat landscape. Its data-driven approach, combined with expert insights, makes it a benchmark for understanding, testing, and improving web application security.

Recognized not only for its educational value but also for its role in shaping security practices and standards, the OWASP Top 10 is essential for building secure web applications.

Here’s a run-through of the most recent OWASP Top 10 (from 2021).

1. Broken Access Control

Broken access control refers to placing insufficient restrictions on what authenticated users are allowed to do in an app. These flaws in the implementation of user permissions and rights allow users to perform actions or access data beyond their intended privileges. An example of broken access control is where a standard user simply manipulates a URL to access admin functionalities in the app without proper privileges.

To test a web app for broken access control security risks, consider the following strategies:

• Create multiple test accounts, each with different roles, and try to perform out-of-scope actions.
• Try to hijack or swap session tokens to see if one user can impersonate another or elevate their access.
• Try to modify parameters in the URL, hidden fields, or API requests to access objects not meant for standard users.

The most important preventative measure is to design and implement a robust role-based access control (RBAC) system. Ensure that each user role has the minimum necessary permissions (least privilege principle). Enforce these roles consistently throughout the application, both on the front end and back end.

2. Cryptographic Failures

This security risk relates to the problem of the improper implementation or usage of cryptography, such as using outdated algorithms or incorrect key management configurations. Skilled hackers can trivially bypass weak or misconfigured cryptography to tamper with a web app or access sensitive data.

To test for this risk:

• Audit cryptographic practices for deprecated methods or algorithms.
• Test key management practices.
• Ensure the app uses secure, updated cryptographic libraries.

3. Injection

Injection flaws in web applications allow attackers to craft malicious inputs that can trick an app into executing unintended commands. The most well-known type is SQL injection, where hackers manipulate a web app’s database queries.

Earlier this year, a popular plugin used by over 930,000 WordPress websites was found to have PHP object injection flaws.

To test your web app for injection risks:

• Use static code analysis to identify potential vulnerabilities.
• Test the app dynamically with various injection payloads.
• Make sure the app validates and sanitizes user inputs.

4. Insecure Design

Insecure design in web applications means architectural and foundational choices that inherently lack security considerations. These risky choices may render an app vulnerable to attack, regardless of individual code-level security measures.

The testing strategies for insecure design are more nuanced and include:

• Conducting threat modelling to understand the application’s design, how data flows, and potential areas of weakness.
• Performing a comprehensive review of the application’s architecture and assessing if security controls are built into the foundational layers, including authentication, authorization, and data validation.
• Ensuring that development, testing, and production environments are distinct and segregated.

5. Security Misconfiguration

Security misconfiguration in web applications occurs when security settings and controls are improperly implemented, left at default values, or overlooked entirely. The risks of misconfigurations include unprotected files, directories, or databases that facilitate unintended access to valuable data or system capabilities.

Hurried deployments and a lack of security awareness are the primary causes of these risks.

To test your web applications for security misconfigurations:

• Regularly review and audit application, database, server, and network configurations manually.
• Use automated scanners and security tools that can detect common misconfigurations.
• Monitor error messages for sensitive information leakages, such as paths, server details, or database information.
• Ensure that no default credentials (username/password) are active in the app.

6. Vulnerable and Outdated Components

Vulnerable and outdated components in web applications refer to third-party libraries, plugins, frameworks, and other software modules that have known security vulnerabilities but have not been updated or patched by the developers.

Web applications that rely on vulnerable components inherit their weaknesses, which provides a potential path for threat actors to exploit.

To test web applications for vulnerable/outdated components:

• Maintain an up-to-date inventory of all third-party components, libraries, plugins, and frameworks used in your application, including their versions and dependencies.
• Cross-reference your component inventory with vulnerability databases like the National Vulnerability Database (NVD) or CVE details.
• Use automated tools like OWASP’s Dependency-Check to scan project dependencies and compare them against known vulnerability databases.

7. Identification and Authentication Failures

Flawed authentication mechanisms, such as weak password policies, lack of multi-factor authentication, or improperly implemented session management enable attackers to impersonate legitimate users or bypass authentication checks altogether.

These failures pave the way for unauthorized data access, identity theft, and potential takeover of user accounts.

To test for this OWASP Top 10 risk:

• Check for minimum password length/complexity requirements and try common or default passwords to see if the app accepts them.
• Check if sessions expire appropriately after inactivity or after a user logs out.
• Try to manipulate or replay cookies to see if you can impersonate a session.
• Try manipulating URLs, query parameters, or hidden fields to bypass authentication checks.

8. Software and Data Integrity Failures

Software and data integrity failures occur when an application has an inability to ensure the authenticity and trustworthiness of data and application code. Integrity is about ensuring that data and code remain unaltered and genuine from their original state.

Failures in software and data integrity introduce the risk of unauthorized modifications that lead to fraudulent transactions or malicious code being inserted into the application.

To test for these failures, consider:

• Tampering with transmitted data and observing if the application accepts the tampered data without any checks.
• Manipulating application files or libraries and seeing if the application detects unauthorized changes.
• Checking for the absence of checksums, digital signatures, or other verification mechanisms that would validate the integrity of data or software components.

9. Security Logging and Monitoring Failure

This risk relates to the insufficient recording of activities in an app or the inability to proactively detect and respond to malicious actions in real time.

A lack of detailed logs or the absence of monitoring creates blind spots that prevent timely detection of unauthorized access, data breaches, or other malicious activities.

To assess if a web application has these risks:

• Regularly review logs to ensure that they capture relevant security events, such as failed login attempts, access to sensitive data, or system configuration changes.
• Ensure all critical components, such as databases, servers, and application endpoints, are monitored.
• Review configurations of monitoring tools to ensure they are set up to capture all relevant security events.

10. Server-Side Request Forgery (SSRF)

Server-Side Request Forgery (SSRF) is a security vulnerability in which an attacker manipulates a web application into making unwanted requests to internal resources or third-party systems on behalf of the server.

This risk facilitates lateral movements in network infrastructures and enables attackers to interface with backend services or exfiltrate data.

To test for SSRF:

• Experiment with different URL schemes (like file://, dict://, sftp://, etc.) to attempt to access non-HTTP resources.
• Emulate web front-end requests to hit a back-end API, but modify the requests with http://localhost/admin or http://127.0.0.1/admin to see if any unexpected data is returned.
• Identify areas of implicit trust between hosts, such as local database servers trusting web servers.
• Look for detailed error messages that might indicate an SSRF vulnerability. For instance, if you enter an internal IP and the error reveals details about an internal resource, that’s a potential sign of risk.

The Importance of Regular Web Application Security Testing

As the OWASP Top 10 consistently highlights, vulnerabilities in web applications expose organizations to significant risks, from data breaches to reputational damage. It’s not just about knowing these vulnerabilities, but actively testing for them on a regular basis.

With each code update, infrastructure change, or new feature addition, potential security gaps can emerge. Continuous vigilance is essential, and that is only possible with regular tests that go beyond the annual pen tests that many companies perform as a box-ticking exercise.

Unlike traditional one-off penetration tests, pen testing as a service (PTaaS) offers continuous testing of web applications to identify vulnerabilities before malicious actors can exploit them. Outpost24’s PTaaS platform combines the depth and precision of manual penetration testing with vulnerability scanning to secure web applications at scale.

The solution offers direct access to a highly skilled team of in-house testers, ensuring the most accurate view of your vulnerabilities including business logic errors and backdoors that automated scanners missed. Maximize your application security program without slowing down development.

Learn more about Outpost24’s PTaaS solution.

Sponsored and written by Outpost24.

Original Source