The OWASP Top 10: 2013 vs. 2017

Every few years, the Open Web Application Security Project (OWASP) releases a list of 10 critical security risks for web applications. This list highlights key issues affecting the modern web and the steps you can take to secure your web apps. OWASP creates these lists with input from the web development and security communities, as well as data collected from over 100,000 live web applications.

Here are the changes introduced in the 2017 edition of the OWASP Top Ten project. You can find the full 2013 and 2017 reports on the OWASP Top Ten Project page. The page also contains links to cheat sheets and reference pages.

New Risks

Three new risks were added this year: XML External Entities (XXE), Insecure Deserialization, and Insufficient Logging and Monitoring.

A4: XML External Entities (XXE)

XXE takes advantage of poorly configured XML parsers to extract data from a server. The attack relies on external entities, which are references to resources outside of the XML document they’re defined in. The XML parser opens the resource and returns its contents, or falls prey to a Denial of Service attack.

How It Works

An attacker creates an XML document that includes an external entity, such as the location of a sensitive file. The attacker sends this document to the server as POST data. The server’s XML parser replaces any references to the entity with the contents of the entity, and if the server includes the XML document in its response, the attacker sees the entity’s contents.

How to Prevent It

Other data formats such as JSON and YAML aren’t vulnerable to XXE attacks. Where XML is required, disable external entities in your XML parser. Alternatively, sanitize any and all XML documents before passing them to the parser. For more information, see the XXE Prevention Cheat Sheet.

A8: Insecure Deserialization

Serialization is the process of converting an object stored in memory into a format suitable for storage or transmission. For example, a web application serializes user session data to the server’s hard drive to track sessions over time. Conversely, deserialization is the process of converting data back into an object. With insecure deserialization, an attacker sends a serialized object to the server and uses the deserialization process to execute arbitrary code or cause a DoS.

How It Works

Imagine that a web app tracks user sessions by serializing a unique ID and sending it to the user’s browser. When the user opens the website, this ID is deserialized on the server and automatically logs the user in if it’s valid. An attacker finds the unique ID stored in her browser and replaces it with arbitrary code. When she opens the website, the server deserializes the object and runs the arbitrary code.

How to Prevent It

The safest route is to avoid serialization entirely and use a pure data format such as JSON or XML. If serialization is necessary, perform strict data type checks on the object before deserializing it. You should also isolate the deserialization process as much as possible by running it with a low-privilege user account or separate from the rest of your application code. For more information, see the Deserialization Cheat Sheet.

A10: Insufficient Logging and Monitoring

Logs and monitors are often underestimated as security tools. While they won’t actively prevent problems, they provide insight into unusual behaviors, failures, and performance trends. Effective monitoring can even notify you of attacks while they’re happening. Because logging is often implemented poorly or not at all, attackers can easily avoid detection.

How It Works

An attacker is trying to brute force her way past a web app’s login page using an automated program. The constant rate of attempts causes the server’s resource usage to peak at 100%. Because the server isn’t being monitored, the spike goes undetected, and because login failures aren’t being logged, the hundreds of thousands of failed login attempts also go undetected.

How to Prevent It

Almost all programming languages include logging frameworks. At a minimum, log any security-related events (such as user authentication and access control errors) with a unique identifier for the user performing the action. Use a centralized log management service to aggregate log data, scan for unusual activity, and send alerts when it detects certain patterns. For more information, see the Logging Cheat Sheet.

Templarbit can help you monitor web application activity, start with a free account.

Removed Risks

Two items were removed from this year’s top 10: Cross-Site Request Forgeries (CSRFs) and Unvalidated Redirects and Forwards.

A8: Cross-Site Request Forgeries (CSRFs)

Most browsers cache login data and will automatically log you in to websites you’ve already visited. However, this also means that anyone who controls your browser has access to those cached credentials. CSRFs take advantage of this to perform actions on websites on your behalf without your knowledge.

Why It Was Removed

While CSRFs are still relevant, it’s becoming easier to mitigate them. An increasing number of web application frameworks include built-in CSRF protection, and existing applications can verify the origin of the request by comparing its HTTP headers. Browsers are also gaining CSRF protections through the SameSite attribute, which blocks cookies from loading when the user accesses a website through another website.

A10: Unvalidated Redirects and Forwards

Many web apps use redirects and forwards to send users to other areas of the application after the user performs an action. For example, a login page might redirect a logged in user to his or her user profile page. If the redirection page accepts untrusted input (such as a URL) as the destination, an attacker could redirect the user from the original site to a malicious site without the user’s knowledge.

Why It Was Removed

This attack only works when a web application accepts user input as the redirection URL. To prevent this, remove the user-supplied parameter and specify the destination URL in your application logic. Alternatively, sanitize the user’s input and check it against a whitelist of allowed URLs. You might also add a page dedicated to redirections that warns the user when a link takes them to an external website. For more information, see the Unvalidated Redirects and Forwards Cheat Sheet.

More Changes

Two risks from the 2013 report (Insecure Direct Object References and Missing Function Level Access Control) were merged into a single risk: Broken Access Control.

The 2017 report also added more details on Cross-Site Scripting (XSS).

A5: Broken Access Control

Broken access control is the combination of two risks in the 2013 report: Insecure Direct Object References and Missing Function Level Access Control. Broken access control is any situation where a user can perform actions outside of her intended permission set. For example, an online forum should block anonymous users from accessing member-only pages even if they know the page’s URL. With improperly configured access controls, the user gains access to those pages simply by entering the correct URL.

Why They Were Merged

Both of the items in the 2013 report involve an attacker gaining access to areas of a web app that she shouldn’t otherwise have access to. An insecure direct object reference involves an attacker accessing an object by changing the value of a parameter. Missing function level access controls is what actually allows the attacker to access this object by failing to validate the user’s privileges. Because these vulnerabilities are so similar, the 2017 report merged them into a single risk.

A7: Cross-Site Scripting (XSS)

XSS is the second most prevalent issue in the OWASP Top 10, affecting two-thirds of all web applications. XSS uses vulnerable web apps as vectors to deliver malicious scripts to users. Users download and run the script without realizing it’s from an attacker. The hacker can then access the user’s browser to steal sensitive data and perform malicious activity. .

XSS is one of the most widespread vulnerabilities on the Web because it’s both easy to exploit and difficult to prevent. Any weba app that allows user input is vulnerable to XSS unless additional steps are taken to detect and prevent it. This includes scanning all user input for potentially dangerous strings, such as HTML and JavaScript tags. The sheer number of potential vectors has made XSS one of the most common and dangerous exploits.

Why It Was Changed

The 2017 report splits XSS into three categories:

• Reflected XSS: Users enter unsanitized HTML or JavaScript and the browser renders it, executing any embedded scripts.
• Stored XSS: Similar to a reflected attack, except the web app stores the input and allows other users to access it at a later time.
• DOM XSS: The attack occurs in the Document Object Model (DOM) instead of the returned HTML server response , making it very hard to detect the malicious execution.

The 2017 report provides additional mitigation solutions, specifically using frameworks with built-in XSS mitigation and encoding user input. It also recommends enabling a Content Security Policy (CSP) for browsers that support it. For more information, see the XSS Prevention Cheat Sheet.

Templarbit is Content-Security-Policies on autopilot. With libraries for Ruby, Python, Node.js and Golang the integration only takes a couple of minutes and you’re ready to protect your web application. You can start with a free account.