OWASP: Top 10 Web Application Vulnerabilities

Web applications are part of our daily lives. We use and consult them at work and home, for information and entertainment. Their use has become so widespread that they have become a staple of our lives. From the point of view of companies, web applications are, in some cases, their channel of connection with the world and, in others, the fundamental pillar of their business. Therefore, it is essential for software developers to be aware of the most common web application vulnerabilities. And implement more secure coding.

Taking into account the relevance of the web for users, companies, institutions, and developers, the OWASP Foundation periodically publishes the Top 10 web application vulnerabilities. In this way, it systematizes, updates, and conceptualizes the main risks. It has established itself as a basic standard in the field of cybersecurity worldwide.

To this end, OWASP carries out complex research to test applications, detect the most common cyber risks and compile the best security practices. The OWASP Top 10 web application vulnerabilities categorize the risks and propose a series of actions. These can be implemented by professionals to protect their developments and curb the dangers. In addition, examples of attack scenarios are incorporated.

The last OWASP Top 10 web application vulnerabilities were published in 2021. This report provides a comprehensive overview of the main security risks that developers and companies have to deal with today. In the following, we will explore each category of vulnerabilities one by one.

1. Access control flaws in OWASP

In the previous Top 10 web application vulnerabilities of 2017, this risk ranked fifth. However, in the latest research conducted by OWASP, this risk, tested in 94% of the applications analyzed, showed an incidence rate of 3.81%.

This category refers to weaknesses detected in the implementation of authentication and authorization controls. Or, to put it another way, the mission of an application’s access control is to ensure that users cannot perform actions for which they lack permissions.

When programming any web resource, developers must take into account an access control scheme and a permissions system. In this line, the implementation of validation mechanisms is required when accessing each resource. In this way, it is possible to verify that the user has been assigned the role he/she needs to execute an action related to that resource.

Manipulation of the value of identifiers

Óscar Mallo, Cybersecurity Advisor at Tarlogic, highlights a paradigmatic example of this vulnerability: the manipulation of the value of identifiers in the parameters of a URL.

Through this malicious action, it is possible to access information elements that are unrelated to the authenticated user. For example, if the URL that defines access to the resource that allows viewing private information about a user contains a UserId parameter whose value is 1000, it could be modified to define the value 1002. If the application does not correctly implement access control measures, it would be possible to retrieve another user’s information in an unauthorized manner.

This operation opens the door for a person with a low-security role to gain access to the information and resources of another person with a high-security role within the organization.

Concerning e-commerce, which is becoming increasingly relevant at the socio-economic level, this type of breach could have very serious consequences for the business. An attack could lead to manipulation of the platform’s prices, leading to successful fraud.

Assignment of essential minimum privileges

How can this vulnerability be prevented when programming? Oscar Mallo argues that “when defining authorization controls, the principle of least privilege assignment should be followed by default. This minimizes the possibility of information breaches. In addition, Mallo continues, “any sensitive action on an information entity must have an associated authorization control that guarantees access or modification only to the appropriate users”.

OWASP reminds us that access control is only effective in server-side code. Since, in them, attackers cannot modify the access control check and metadata. They therefore recommend:

• Deny access by default, except in cases of public resources.
• Implement access control mechanisms once and reuse them on all web application resources.
• Access controls should prevent the user from creating, reading, updating, or deleting any records.
• Disable webserver directory listing and ensure that file metadata is not present in web roots.
• Log access control failures and alert administrators if necessary.
• Limit the rate of API and controller access, to limit the damage generated by automated attack tools.
• Session IDs should be invalidated on the server when the session ends.

2. Cryptographic flaws

This type of risk moves up one place in the ranking of the Top 10 web application vulnerabilities of 2017. This category systematizes flaws linked to cryptography. And which can expose sensitive data and compromise systems as a whole.

They are therefore vulnerabilities linked to the absence of secure communications protocols. In other words, encrypted. The root of this problem lies in the use of:

• Obsolete and/or insecure encryption schemes.
• Weak encryption keys.

Using strong and fully up-to-date encryption algorithms

Cybersecurity is an area in which it is essential to keep constantly up to date, as new risks and innovations arise every day. When it comes to cryptography, this is even more relevant. It is not enough for cryptography to be present. It must also be of high quality and fully up to date. To be able to respond successfully to evolving attacks.

This is because algorithms, as José Rabal, Security Advisor at Tarlogic, argues, become obsolete over time.

To prevent these weaknesses, OWASP recommends:

• Classify the data processed, stored, or transmitted by an application, identify particularly sensitive data, and apply security controls based on this classification.
• Avoid storing sensitive data that is not needed or delete it as soon as possible.
• Encrypt all stored sensitive data.
• Use key management appropriate to the needs of the web application.
• Encrypt data in transit with secure protocols, prioritizing encryption by the server.
• Disable caching of responses that include sensitive information.
• Store passwords using strong, adaptive hashing functions.
• Use authenticated encryption.
• Generate keys randomly cryptographically and store them in memory as byte arrays. Also, ensure that cryptographic randomness is used appropriately and is not predictable or low entropy.
• Avoid obsolete cryptographic functions and schemes.
• Independently verify that the cryptographic configuration is efficient and secure. For example, employing a web security audit.

3. Injection vulnerabilities

Although this category drops from first place in the Top 10 vulnerabilities in web applications to third place, it is still a relevant vulnerability with an incidence rate of 3.37%.

Through injection vulnerabilities, attackers can take advantage of the lack of correct filtering or sanitization of input data to alter the code of the application functions. In this way, actions are executed or information is returned unexpectedly. This type of vulnerability is usually associated with a high impact on the security of the web application.

OWASP considers that a website is vulnerable to an injection attack when:

• The data entered by the user is not validated, filtered, or sanitized.
• Dynamic queries are used directly in the interpreter.
• Hostile data is used within search parameters to extract sensitive records.
• Hostile data is processed or concatenated directly.

José Rabal proposes a very graphic example to understand this type of vulnerability. An application has a search field for users by name. However, the attacker, instead of typing a name, enter a specially manipulated string to alter the underlying query and get the application to return, in addition to the user’s basic data, especially sensitive information about the user that the system did not expect to provide.

Securely linking input parameters

Tarlogic‘s cybersecurity experts believe that the best way to mitigate these types of weaknesses is by following these tips:

1. Make use of the functions included in the API itself or the application framework. To securely bind the input parameters provided by the user.
2. If option 1 cannot be implemented, appropriate filters to the values provided by the users must be implemented on the server-side. In such a way as to ensure that they cannot unexpectedly alter the behavior of the actions performed by the application.

The OWASP report argues that to prevent injection attacks it is essential to systematically keep data separate from commands and queries. To do so, they recommend:

• Use a secure API that avoids using the interpreter altogether, and implement a parameterized interface.
• Use positive validation of server-side inputs.
• For residual dynamic queries, use interpreter-specific character escaping syntax. SQL structures, such as table and column names, cannot be escaped, hence this problem is common in report writing software.
• Use LIMIT and other SQL controls in queries. To avoid mass disclosure of rows of information if SQL injection occurs.

4. Insecure design

This category is newly created and encompasses the different risks associated with design and web architecture defects. In other words, it groups all the weaknesses resulting from the lack of application of secure design methodologies.

Insecure design is difficult to remedy once the development has been carried out. Both because of the complexity of the task and because of the additional cost involved. In this sense, OWASP points out a difference that must be taken into account. An insecure design is not the same as an insecure implementation.

A secure design can be burdened by implementation flaws that give rise to security risks. Whereas the weaknesses inherent in an insecure design cannot be mitigated by a perfect implementation. Since security controls have not been created to defend against specific attacks. A key contributing factor to an insecure design is the organization’s inability to determine what level of security design is needed.

Secure development lifecycle models

Óscar Mallo and José Rabal argue that the best way to address insecure design vulnerabilities at their root is to apply secure software development lifecycle models. These models are used to raise misuse cases during the design phase of a system. And, thus, avoid common mistakes.

This measure is also pointed out by OWASP as the best way to prevent the risks associated with insecure design. Since it helps to evaluate and design controls related to the security and privacy of the web application. Other actions that can be taken to ensure that the design is secure include:

• Establish and use a secure design pattern library.
• Use threat modeling for critical authentication, access control, and key flows.
• Integrate security language and controls into user stories.
• Integrate controls at each level of the web application.
• Write integration tests to validate that all critical flows are resilient against the threat model. In addition, as noted above, use cases can be collected for each tier of the application.
• Segregate the layers of tiers according to exposure and protection needs. As well as the tenants in the different tiers.
• Limit resource consumption per user or service.

5. Incorrect security configuration

The architecture of a web application is based on a large number of elements, which present various configuration options. Servers, frameworks, data management systems, CMS, plugins, APIs… All these elements can be part of the architecture that supports the application. And give rise to security vulnerabilities if they have an incorrect configuration or a default configuration that does not comply with the appropriate security standards.

This weakness was detected in 4% of the web applications tested in the OWASP research. This has caused it to move up one position in respect to the Top 10 vulnerabilities in web applications in 2017.

Hardening, segmentation, and best practices

Tarlogic Security‘s cybersecurity consultants recommend four basic actions to mitigate security misconfiguration vulnerabilities:

1. Implement a hardening process. This can be used to apply appropriate configurations to all components of the architecture.
2. Perform, as far as possible, a segmentation between the different components of the web architecture. This can prevent a vulnerability that originates in one of them from being able to lead to lateral movements by attackers and affect other components.
3. Apply security policies that support a defense in depth of the components.
4. Review all the documentation on good security practices related to the different elements that make up the architecture. OWASP plays a fundamental role here, as a standard recognized by the global cybersecurity community, based on best practices in the sector.

Precisely, this foundation recommends, to prevent this type of vulnerability, the actions proposed from Tarlogic and other tasks such as:

• Develop a minimal platform, without unnecessary components, as well as remove or not install features and frameworks that are not accurate.
• Having a task to review and update the appropriate configurations of all security notes, updates, and patches.
• Design an automated process to verify the effectiveness of configurations and settings in all environments.

6. Vulnerable and obsolete components

Their name leaves little room for doubt. This type of vulnerability is caused by the use of software or components within an application or web infrastructure that are obsolete or have known vulnerabilities.

How can an organization know that its web application is at risk because of vulnerable or obsolete components? OWASP outlines six scenarios that allow companies to detect this problem:

• The versions of all components being used in the web application are not known. Both client-side and server-side.
• The software is vulnerable, unsupported, or outdated.
• Vulnerabilities are not scanned regularly.
• The underlying platform and frameworks are not patched or updated.
• Software developers do not check compatibility between updated or patched libraries.
• Failure to ensure the security of all component configurations.

DevSecOps: securing all phases of the lifecycle

To mitigate this vulnerability, an organization can rely on DevSecOps, a management approach focused on monitoring, analyzing, and applying security measures at all stages of a software’s lifecycle.

This would ensure that the components that make up the web application infrastructure are continuously evaluated. And the necessary security measures are implemented to prevent them from becoming vulnerable or obsolete.

The component management and monitoring model should allow:

• Eliminate unused modules, files, and features.
• Continuously inventory component versions, both server-side and client-side.
• Employ component analysis tools to automate the process.
• Obtain resources only from official sources.
• Control components that are not maintained or for which security patches are not created for older versions.

The ultimate goal is for the organization to have a permanent monitoring plan to implement the necessary security measures to prevent the appearance of vulnerabilities.

7. Identification and authentication flaws

This category was named Broken Authentication in the 2017 Top 10 web application vulnerabilities. And it took second place in that ranking. This time, the OWASP team decided to group authentication and identification flaws into a single category, with these types of vulnerabilities being detected in 2.55% of the applications tested.

As Óscar Mallo and José Rabal point out, these mechanisms are a vital element for application security. They guarantee the identity of users.

This very important category includes vulnerabilities that would allow or facilitate the impersonation of users, as a result of incorrect management of session identifiers, or the elements linked to authentication in the application. Among the most relevant identification and authentication failures we can highlight:

• The absence or incorrect implementation of multiple authentication factors.
• Insecure credential recovery processes.
• Scarce measures against brute force attacks.
• Incorrect renewal of session identifiers for each valid logon.

Multifactor authentication and security measures

To prevent the emergence of identification and authentication failures, which open the door to malicious attacks against web applications, OWASP recommends:

• Implement multifactor authentication to prevent automated brute-force attacks and reuse of stolen credentials.
• Do not implement default credentials.
• Implement controls to detect weak passwords and test new or changed passwords.
• Ensure that registration, credential recovery, and API paths are fortified against account enumeration attacks.
  Limit and space out failed login attempts.
• Use an integrated and secure server-side session manager.
• Prevent the session identifier from being in the URL, store it securely and invalidate it once the session ends or the period of inactivity is extended.

8. Software and data integrity failures

This type of failure is linked to the failure to protect code and infrastructure from integrity breaches. This category is a new addition to the Top 10 web application vulnerabilities. And it serves to put the spotlight on weaknesses related to:

• Malicious attacks on software supply chains.
• Untrusted plugins, libraries, repositories, and content delivery networks.
• Insecure CI/CD channels, through which malicious code can be introduced or the system can be compromised.
• Auto-update functionalities where updates are downloaded without a secure integrity verification system in place. Through this access path, cybercriminals can upload their malicious updates for distribution and execution on all installations.

Protecting supply chains and performing testing tasks

To prevent the emergence of such weaknesses, OWASP recommends the following actions:

• Use digital signatures or similar mechanisms to verify the provenance of software or data.
• Ensure that libraries consume trusted repositories.
• Use security tools to protect software supply chains. These should verify that components do not contain vulnerabilities.
• Confirm that the CI/CD pipeline has secure access control and configuration to ensure code integrity.
• Ensure that serialized data that lacks signature or encryption is sent only to trusted customers. To prevent tampering.

9. Failures in security logging and monitoring

As Óscar Mallo and José Rabal point out, the traceability of events occurring in the application is essential. Firstly, to block threats. And secondly, to investigate security incidents that have taken place and thus prevent them from happening again and to be able to determine which possible assets have been compromised.

Hence, this category aims to help professionals detect, escalate and respond to active breaches. Failures in logging, detection, monitoring, and active response to attacks can occur when:

• Auditable events, such as logins or high-value transactions are not logged.
• Warnings and errors do not generate log messages or are inadequate.
• Application and API logs are not monitored.
• Logs are only stored locally.
• Penetration tests do not trigger security alerts.
• The web application is unable to detect, escalate and alert attacks in real-time.

Log generation and backups

Tarlogic‘s cybersecurity experts recommend, successfully address these vulnerabilities:

1. Make use of your log generation capabilities.
2. Monitor the generation capabilities already available to the elements of the architecture. Or, failing that, add additional components to ensure that this task is carried out efficiently.
3. Periodically generate backup copies of the logs. As well as storing them in locations that guarantee their availability at all times. Despite the possible incidents that can materialize.

10. Server-side request forgery

This type of vulnerability occurs when an attacker can force the server to make connections to targets that were not initially intended. In this way, the attacker takes advantage of the server’s privileged position in the infrastructure to:

• Evade firewalls.
• Force connections to internal network elements.
• Interact with resources that were initially restricted.

This last category of the Top 10 is newly created and does not respond so much to data obtained after testing applications, but to the results of the OWASP survey of cybersecurity experts from around the world.

Although the data do not show a high incidence of this type of vulnerability, professionals consider that they are highly relevant and that their future impact will be greater. Both in terms of the number of attacks and, above all, in terms of their severity, as a result of the rise of cloud services and the complexity of architectures.

Acting on the network and application layers

To prevent this type of security risk, developers must put in place defense controls at the network and application layers. Concerning the former, it is possible to:

• Segment access to remote resources into separate networks.
• Apply default deny-by-default firewall policies or access control rules to block non-essential intranet traffic.

While for the application layer you should:

• Sanitize and validate the input data supplied by the client.
• Enforce the scheme, port, and domain with a whitelist of allowed values.
• Prevent sending responses to clients without prior processing of the information.
• Disable HTTP redirects.
• Ensure URL consistency to prevent attacks.

In short, the OWASP Top 10 web application vulnerabilities have become a standard for everyday use in web development. A ranking that systematizes and categorizes the main security risks. A guide for professionals around the world. A meticulous work whose objective is to contribute to making the web applications we use more secure. And be prepared to face malicious attacks.