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.
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:
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:
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:
SELECT * FROM Users WHERE name = 'someuser' AND password = 'passwd'
SELECT * FROM Users WHERE name = 'user' OR 1 = 1 --' AND password = 'passwd'
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.
Broken authentication refers to the insecure implementation of authentication methods and session management. Some signs of broken authentication include:
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.
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:
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.
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:
]>&weakparser;
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:
net/myapp/myaccount?user=userA
to
someinsecuresite.net/myapp/myaccount?user=userB
net/myapp/super-secret-admin-page
and view privileged information that normally requires authentication.
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.
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:
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";}
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.
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:
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.
