The OWASP Top 10 - A closer view on Web Applications security

Introduction

The OWASP Top 10 serves as a foundational guide for developers and web application security, offering a widely accepted overview of the paramount security threats facing web applications. Enterprises are advised to embrace this resource and initiate measures to mitigate these risks in their web applications.

Incorporating the OWASP Top 10 can be viewed as a highly potent initial move in transforming the software development culture within your organization, ultimately yielding code that is more robust and secure.

In this post you will see a summary or a short view of all Top 10 OWASP recommendations for improving security on web applications, and if you are interested on have a full information about this, you could visit the main source here.

What is the objective of OWASP, why this top 10

The objective of the OWASP (Open Web Application Security Project) Top 10 project is to raise awareness about application security by identifying some of the most critical risks that organizations face.

Specifically, OWASP aims to educate and equip developers, organizations, and the wider community with the knowledge, tools, and resources needed to design, develop, and maintain secure web applications. They do this by providing freely available documentation, tools, and standards that promote best practices in web application security.

Additionally, OWASP fosters a collaborative and open environment for individuals and organizations to share expertise and work together in identifying and addressing security challenges in web applications.

The actual top 10

Lets review the OWASP Top 10:

A01:2021-Broken Access Control

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits. Common access control vulnerabilities include things like violation of the principle of least privilege or deny by default, where access should only be granted for particular capabilities, roles, or users, but is available to anyone or bypassing access control checks by modifying the URL, internal application state, or the HTML page, or by using an attack tool modifying API requests, also metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token, or a cookie or hidden field manipulated to elevate privileges or abusing JWT invalidation.

Access control is only effective in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata. In order to prevent Broken Access Control you could except for public resources, deny by default, implement access control mechanisms once and re-use them throughout the application, including minimizing Cross-Origin Resource Sharing (CORS) usage, and add a rate limiter to the API and controller access to minimize the harm from automated attack tooling.

A02:2021-Cryptographic Failures

This involves the improper handling of sensitive data (like passwords or financial information) without proper encryption or protection, making it accessible to attackers.

The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws.

The actions you could do are for example classify data processed, stored, or transmitted by an application, don't store sensitive data unnecessarily, and encrypt all sensitive information at rest.

A03:2021-Injection

This refers to vulnerabilities where an attacker can inject malicious code (like SQL, OS, or LDAP commands) into a web application. This can lead to unauthorized access, data breaches, or even complete system compromise. Take care of User-supplied data that is not validated, filtered, or sanitized by the application, or look at dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.

Preventing injection requires keeping data separate from commands and queries, for example use a safe API, like Object Relational Mapping Tools (ORMs), which avoids using the interpreter entirely and provides a parameterized interface, use positive server-side input validation, escape special characters using the specific escape syntax for that interpreter and use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.

A04:2021-Insecure Desing

There is a difference between insecure design and insecure implementation. We differentiate between design flaws and implementation defects for a reason, they have different root causes and remediation. A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks.

If you ask how to prevent, the answer is for example establish and use a secure development lifecycle with AppSec professionals to help evaluate and design security and privacy-related controls, establish and use a library of secure design patterns or paved road ready to use components, use threat modeling for critical authentication, access control, business logic, and key flows, integrate security language and controls into user stories and integrate plausibility checks at each tier of your application.

A05:2021-Security Misconfiguration

This vulnerability is more common than you think and is present if the application is missing appropriate security hardening across any part of the application stack or improperly configured permissions on cloud services, unnecessary features are enabled or installed like unnecessary ports, services, pages, accounts, or privileges, default accounts and their passwords are still enabled and unchanged and error handling reveals stack traces or other overly informative error messages to users.

A06:2021-Vulnerable and Outdated Components

This vulnerability is related to missundertanding about the actual software of you application, so if you do not know the versions of all components you use as well as nested dependencies or if the software is vulnerable, unsupported, or out of date, if you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use, and if software developers do not test the compatibility of updated, upgraded, or patched libraries.

A07:2021-Identification and Authentication Failures

This occurs when security mechanisms for user authentication and session management are not implemented correctly. It can lead to unauthorized access to sensitive information.

Confirmation of the user's identity, authentication, and session management is critical to protect against authentication-related attacks. For example permits automated attacks such as credential stuffing, permits brute force or other automated attacks, permits default, weak, or well-known passwords or also exposes session identifier in the URL.

A08:2021-Software and Data Integrity Failures

Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks. An insecure CI/CD pipeline can introduce the potential for unauthorized access, malicious code, or system compromise. Finally, numerous applications currently incorporate an automatic update feature. In this scenario, updates are obtained without undergoing thorough integrity checks and are subsequently integrated into the previously trusted application. This opens up the possibility for malevolent actors to potentially introduce their own updates for widespread distribution and execution across all installations.

For prevention, use digital signatures to verify the software or data is from the expected source and has not been altered, ensure libraries and dependencies, such as npm or Maven, are consuming trusted repositories, use software supply chain security tool, such as OWASP Dependency Check or OWASP CycloneDX and check if your CI/CD pipeline has proper segregation, configuration, and access control to ensure the integrity of the code flowing through the build and deploy processes.

A09:2021-Security Logging and Monitoring Failures

Without logging and monitoring, breaches cannot be detected. Insufficient logging, detection, monitoring, and active response occurs any time:

When logging and monitoring fall short, it leads to various shortcomings. These include the failure to log significant events like logins, failed logins, and high-value transactions. Additionally, warnings and errors may generate either no logs or ones that are insufficient or unclear. Even penetration testing and scans by security tools may not trigger alerts, leaving the application unable to promptly detect, escalate, or alert for active attacks.

To prevent these deficiencies, developers and DevSecOps teams should implement specific controls based on the application's risk level. These measures encompass ensuring that all login, access control, and server-side input validation failures are logged with enough user context for identifying suspicious or malicious accounts. Additionally, logs should be generated in a format compatible with log management solutions, and encoded properly to prevent attacks on the logging or monitoring systems.

A10:2021-Server-Side Request Forgery

Server Side Request Forgery flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list.

As modern web applications provide end-users with convenient features, fetching a URL becomes a common scenario. As a result, the incidence of SSRF is increasing. Also, the severity of SSRF is becoming higher due to cloud services and the complexity of architectures.

In this case, the actions that could be executed are for example: Segment remote resource access functionality in separate networks to reduce the impact of SSRF, enforce “deny by default” firewall policies or network access control rules to block all but essential intranet traffic, ¡Sanitize and validate all client-supplied input data!, enforce the URL schema, port, and destination with a positive allow list, don't send raw responses to clients, disable HTTP redirections, and be aware of the URL consistency to avoid attacks such as DNS rebinding and “time of check, time of use” race conditions.