What is the OWASP Top 10?

Resource

Edge Academy

Topic

Edge Security

For developers and administrators of web applications, the OWASP Top 10 is an important fundamental security reference. It provides a foundation from which to build more secure web apps. Here, we’ll look at the list, the organization behind it, the security risks in the top ten, and how a Web Application Firewall (WAF) can help address some of the risk these threats pose.

What is OWASP?

The Open Web Application Security Project a.k.a. OWASP is a non-profit with the goal of improving software security. OWASP in addition to providing education and training, OWASP provides a variety of useful infosec tools like:

  • Zed Attack Proxy (ZAP)– A popular open source Dynamic Application Security Testing (DAST) tool for vulnerability scans and penetration tests.
  • Dependency-Check– A Software Composition Analysis (SCA) tool which helps with the detection of vulnerabilities in dependencies.
  • Dependency-Track– A supply chain component analysis platform designed to integrate in Continuous Integration/Continuous Delivery (CI/CD) environments and identify risks associated with open source and third party components based on a software bill of materials (SBOM).

What is the OWASP Top 10?

The OWASP Top 10 is a list of the ten most critical security risks for web applications. It is designed to be an awareness document for developers and security professionals.  Like the threats facing web apps, the list itself changes from time to time. For example, the 2013 list was updated in 2017 and OWASP collected data from March-May 2020 for the next update.

So, what risks make up the OWASP Top 10 today? Here they are:

1. Injection

Injection attacks occur when data is sent to an interpreter using some input field (e.g. a form or login) in a web app. One of the most common forms of injection is a SQL injection. A textbook example of a SQL injection attack may occur is:

  1. A login prompt does not properly validate or sanitize username inputs
  2. A database stores usernames and passwords in plaintext (don’t do this!) and lacks controls such as SQL LIMIT
  3. Normally, the web app’s login prompt does a SQL statement like
SELECT * FROM Users WHERE name = 'someuser' AND password = 'passwd'
  1. A malicious user inputs the username “user OR 1 = 1” and any password.
  2. The SQL statement becomes
SELECT * FROM Users WHERE name = 'user' OR 1 = 1 --' AND password = 'passwd'
  1. The malicious user gains access to the password protected content

While many apps today prevent against that simple case, it’s important to remember that any area of a web app that accepts input parameters could be subject to an injection attack.

2. Broken authentication

Broken authentication refers to the insecure implementation of authentication methods and session management. Some signs of broken authentication include:

  • Allowing brute force attacks
  • Allowing weak passwords like “password”
  • Storing plaintext passwords or passwords hashed with a weak or broken hash function
  • Improper handling, rotation, and invalidation of session IDs and authentication tokens

To limit the risk of a breach leaking credentials, when a user creates a password, it should be both salted and hashed before it is stored. Storing passwords in plaintext is the textbook example of not following this best practice, and even public cloud giants like Google have made the mistake.

Additionally, multifactor authentication (MFA) and rate limiting can help address some of the issues associated with broken authentication, such as susceptibility to brute force attacks.

 3. Sensitive data exposure

This broad category covers the unauthorized exposure of sensitive data at rest or in transit. Often APIs don’t properly encrypt and transmit sensitive data like passwords, account numbers, healthcare data, and other Personally Identifiable Information (PII) which leads risk of compromise.

A basic man-in-the-middle (MITM) attack using SSL striping provides us with an example of how sensitive data breaches can occur:

  1. An attacker compromises a WiFi hotspot
  2. User connects to the compromised hotspot
  3. The user attempts to connect to https://someinsecuresite.net
  4. The attacker uses a proxy to forward the user’s request via HTTPS to the server
  5. The attacker strips away the encryption and returns replies to the user via HTTP

Now the attacker sees everything the user sends to the someinsecuresite.net in plaintext. The somesecuresite.net web server has no idea the traffic is compromised, as the requests received from the attacker’s server use HTTPS. The user is unaware of the attack because it seems as though the responses are coming directly from someinsecuresite.net.

Enforcing HTTP Strict Transport Security (HSTS) for all pages, especially those that deal sensitive data is one way to reduce the risk of sensitive data exposure. Similarly, avoiding the use of weak encryption like SSL v3.0 or TLS 1.0 help increase security for your users. Additionally, strong encryption of data at rest can mitigate PII leaks in the event a database is compromised. 

4. XML External Entities (XXE)

Extensible Markup Language (XML) is a common data structure and many web apps can parse XML input. An XXE attack is related to how that parsing occurs. An attacker sends XML data that points to an external entity.

A vulnerable XML parser will then send replies to the external entity potentially exposing sensitive data. For example, suppose an attacker wanted to access /path/to/super/secret/file.txt on a web server with a vulnerable XML parser. The attack may look something like this:

  1. An attacker sends a request that includes this XML 
    <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE eggs[ <!ENTITY weakparser SYSTEM "file:///path/to/super/secret/file.txt"> ]> <movies><filmId>&weakparser;</filmId></movies>
  1. The server replies with an error and the contents of /path/to/super/secret/file.txt

5. Broken access control

While number two on OWASP Top 10 deals with authentication, number 5 relates to what happens afterwards. Access control refers to the limits associated with a given set of user privileges.

Specific examples of broken access control OWASP mentions include:

  • Using a modified URL to bypass access controls. For example, if userA can access userB’s account information simply by changing a link from 
    net/myapp/myaccount?user=userA

    to

    someinsecuresite.net/myapp/myaccount?user=userB
  • Privilege escalation. For example, a vulnerability or misconfiguration that allows a user to perform admin actions.
  • Unauthenticated access to privileged pages. For example, if an unauthenticated user is able to browse to 
    net/myapp/super-secret-admin-page

    and view privileged information that normally requires authentication.

  • Manipulation of metadata. Examples include replaying or manipulating access control tokens or cookies and abuse of JSON Web Token invalidation.
  • CORS (Cross-Origin Resource Sharing) misconfiguration. A common example of CORS misconfiguration is allowing requests from “localhost” to interact with production web applications.

6. Security misconfiguration

OWASP reports that security misconfiguration as the most common issue on their list. By default, many packages ship with insecure defaults and web developers and administrators need to harden them. Additionally, modification of configurations to get a specific function to work may lead to an unintended security flaw.

For example, allows access to an admin panel with a default password by default, the credentials need to be changed before production deployment. Similarly, unnecessary services and ports should be disabled or blocked.

The big takeaway from this OWASP Top 10 entry is:  make sure to securely configure your app’s components AND be diligent in applying security patches and upgrades.

7. Cross-site Scripting (XSS)

Cross-site scripting a.k.a. XSS is a common security issue facing web apps. XSS attacks place client-side scripts into web content. They can enable attackers to steal data, hijack a user’s session, or display modified content on a web page. There are several different types of XSS attacks including:

  • Reflected XSS – This simple form of an XSS attack is also known as a non-persistent XSS attack. It generally uses a malicious URL pointing to a legitimate site. In the attack, the URL includes special characters (e.g. HTML control characters) that vulnerable pages then execute.
  • Stored XSS – These attacks are also referred to as stored XSS. In the case of stored XSS, the malicious data provided by an attacker is saved server-side. The result is the compromised content being displayed to all users that visit the page.
  • Document Object Model (DOM)- based XSS– DOM-based XSS attacks are unique in that the exploit generally never touches the server. Front-end code like JavaScript is exploited to execute malicious scripts.

8. Insecure deserialization

Serialization is the process used to convert data objects into a specific format for purposes suck as streaming or data storage. Serialized data can be binary or plaintext data (like JSON or XML). Deserialization is the process of reversing serialization and converting the serialized data back to a data object.

The serialization/deserialization process can become a problem when untrusted sources of serialized data are in the mix. An attacker may include specific operations in the serialized data, and if the attack is successful, the server will execute them in the deserialization process. This means insecure deserialization can be used for attacks ranging from DDoS to privilege escalation.

OWASP provides a good example of insecure deserialization by using a vulnerable PHP-based forum application as an example. Suppose the app uses a super cookie that stories a user ID, user role, and password hash information.
An attacker could modify the cookie to grant themselves elevated privileges, like this:

Before:

a:1:{s:1:"MalicousUser";i:1;s:2:"guest"; i:1;s:1:" fe7pmk43i1wstgqvsyask27g44yxn7qhl6zgkr7ivho1e6lv903xc9sbiq4b6mtx";}

After:

a:1:{s:1:"SuperAdmin";i:1;s:2:"admin"; i:1;s:1:" fe7pmk43i1wstgqvsyask27g44yxn7qhl6zgkr7ivho1e6lv903xc9sbiq4b6mtx";}

9. Using components with known vulnerabilities

This risk is exactly what the name suggests: the use of vulnerable components within a web app. Modern web apps depend on a variety of frameworks, libraries, and modules. If any of these underlying components have security vulnerabilities, those can place the entire app at risk. Like with number six on the OWASP Top 10, applying security patches and upgrades can go a long way here.

10. Insufficient logging and monitoring

Rapid detection of attempted threats or confirmed breaches are a big part of preventing or mitigating damage. Malicious activity often has a unique pattern and effective monitoring can help detect it quickly. In many cases, undetected breaches lead to more widespread damage which is why this risk made the list. In fact, according to OWASP, most studies suggest the time it takes to detect a data breach exceeds 200 days.

Some common examples of insufficient logging and monitoring include:

  • Not logging high-value events like logins and failed logins
  • No messaging or ambiguous errors and log messages for warning-level or higher events
  • Only storing logs locally on the server
  • Security scans do not trigger notifications or alerts
  • No real-time alerting for attacks

How a WAF can help address the OWASP Top 10

There is no single silver-bullet to keep your web application safe from the threats in the OWASP Top 10. You’ll need to ensure security is taken into account in code, in infrastructure configuration, and in the third-party components you use.

That said, a Web Application Firewall can take a lot of the footwork out of securing your web app. For example, the Infosec Institute recommends using a WAF to protect against insecure deserialization. Similarly, the OWASP definition of a WAF calls out the common use cases of mitigating attacks like XSS and SQL Injections.

So, how exactly can a WAF help in these cases? Properly configured WAFs can detect and block potentially malicious requests. For example, a request that appears to be a SQL injection or XSS attack will be stopped before it ever reaches your web application.

Further, StackPath’s WAF includes a core ruleset designed specifically to address the OWASP Top 10.

To address the challenges of logging, monitoring and threat detection, the StackPath WAF comes with built-in WAF event management and stats. These real-time insights with granular data on security events enable you to take a proactive approach to web application security.

Related