OWASP Top 10 Vulnerabilities

OWASP top 10 vulnerabilities 2021

OWASP Top 10 Vulnerabilities 2021 is nothing but an Applications run in the cloud should conform to best practice guidance and guidelines for the assessment and ongoing management of vulnerabilities.

As mentioned earlier, the implementation of an application risk-management program addresses not only vulnerabilities but also all risks associated with applications.

The most common software vulnerabilities are found in the Open Web Application Security Project (OWASP) Top 10

The OWASP Top 10 Vulnerabilities 2021

Injection: Includes injection flaws such as SQL, OS, LDAP, and other injections. These occur when untrusted data is sent to an interpreter as part of a command or query. If the interpreter is successfully tricked, it will execute the unintended commands or access data without proper authorization.

Broken authentication and session management: Application functions related to authentication and session in management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens or to exploit other implementation flaws to assume other users’ identities.

Cross-site scripting (XSS): XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping.

XSS allows attackers to execute scripts in the victim’s browser, which can hijack user sessions, deface websites, or redirect the user to malicious sites.

Insecure direct object references: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key.

Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

Security misconfiguration: Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform.

Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

Sensitive data exposure: Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials.

Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection, such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

Missing function-level access control: Most web applications verify function-level access rights before making that functionality visible in the UI.

However, applications need to perform the same access control checks on the server when each function is accessed.

If requests are not verified, attackers will be able to forge requests to access functionality without proper authorization.

Cross-site request forgery (CSRF): A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application.

This allows the attacker to force the victim’s browser to generate requests that the vulnerable application thinks are legitimate requests from the victim.

Using components with known vulnerabilities: Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover.

Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

Invalidated redirects and forwards: Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages.

Without proper validation, attackers can redirect victims to phishing or malware sites or use forwards to access unauthorized pages.”6

To address these vulnerabilities, organizations must have an application risk management program in place, which should be part of an ongoing managed process.

One possible approach to building such a risk-management process can be derived from the NIST “Framework for Improving Critical

Infrastructure Cybersecurity.”7 Initially released in February 2014 as version 1.0, the framework started as Executive Order 13636, issued in February 2013.8 OWASP Top 10 Vulnerabilities 2021.

The framework is composed of three parts:

  1. Framework Core: Cybersecurity activities and outcomes divided into five functions: identity, protect, detect, respond, and recover
  1. Framework Profile: To help the company align activities with business requirements, risk tolerance, and resources
  1. Framework Implementation Tiers: To help organizations categorize where they are with their approach

Building from those standards, guidelines, and practices, the framework provides a common taxonomy and mechanism for organizations to do the following:

  1. Describe their current cybersecurity posture
  1. Describe their target state for cybersecurity
  1. Identify and prioritize opportunities for improvement within the context of a continuous and repeatable process
  1. Assess progress toward the target state
  1. Communicate among internal and external stakeholders about cybersecurity risk

A good first step in understanding how the framework can help inform and improve your existing application security program is to go through it with an application security–focused lens.

You will now examine the first function in the Framework Core, Identify (ID), and its categories Asset Management (ID.AM) and Risk Assessment (ID.RA)

ID.AM contains the following subcategories:

  1. ID.AM-2: Software platforms and applications within the organization are inventoried.
  1. ID.AM-3: Organizational communication and data flows are mapped.
  1. ID.AM-5: Resources (such as hardware, devices, data, and software) are prioritized based on their classification, criticality, and business value. ID.RA contains the following subcategories:
  1. ID.RA-1: Asset vulnerabilities are identified and documented.
  1. ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk.

According to Diana Kelley, executive security advisor at IBM Security,

There is a lot in the Framework that would map nicely to a risk-based software security program.

Classifying applications on criticality and business value can be brought to a deeper and more precise level when the threat model and vulnerability profile of that application is understood and validated with testing.”

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top