Introduction to the OWASP Top 10 - 2017

Originally published in Intopalo Digital's company blog:
https://www.intopalo.com/blog/2019-10-24-owasp-top-10/
 
This blog entry is about the OWASP Top 10 - 2017 and is primarily intended as an introduction for people commonly involved in software development and acquisition projects. 

The high-level topics are:

1. What is the OWASP Top 10 - 2017
2. Reasons to Use the OWASP Top 10 - 2017
3. The Top 10 Issues Overview

tl;dr: the OWASP Top 10 is a list software vulnerabilities that are commonly overlooked or ignored during development and testing, and that have been successfully exploited with various levels of harm to businesses and users. The OWASP Top 10 should be part of most if not all project requirements specifications, architecture design and/or testing plan.

This text is primarily based on OWASP Top 10 - 2017. 

1 What is the OWASP Top 10 - 2017

While the original goal of the OWASP Top 10 was simply to raise awareness among developers about common software vulnerabilities, it has since become the de facto application security standard. It is, however, merely a starting point: by securing an application against the top 10 threats does not mean that the application is secure; there much more than that when it comes to secure software and information security.

A primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the consequences of the most common and most important web application security weaknesses. The Top 10 provides basic techniques to protect against these high-risk problem areas and provides guidance on where to go from here.

The 2017 release replaces the previous 2013 release. It is primarily based on over 40 submissions from application security-oriented companies, and an industry survey that received responses from over 500 individuals. All and all the data is based on experiences and observations from hundreds of organizations and "over 100,000 real-world applications and APIs".

The survey data has been made publicly available in GitHub.

2 Reasons to Use the OWASP Top 10 - 2017

The two most obvious and important reasons to pay proper attention to these top 10 issues relate to software development and software acquisitions. 

For people involved in software development, it should be a matter of professionalism to be aware of the common vulnerabilities (and by extension, potentially exploitable weaknesses) and to do their best to have these issues covered in their projects.

At very least these issues (as applicable) should be covered in testing and have them fixed before production release, if discovered.

For people involved in software acquisitions, it literally pays to require suppliers to prove that their software has been tested against these known issues. This should be stipulated either in contract or in project requirement specification. Alternatively, a risk assessment or code review could be performed for an on-going project to discover if these issues are present.

All and all by taking note of these issues as early as possible in a project significant time and resources (= money) can be saved instead of trying to patch the project later down the road. More importantly, if these vulnerabilities find their way to production and then get exploited, potential damages for a business can be severe depending on what kind of information was exposed.

Why take the risk?

3 The Top 10 Issues Overview

A1:2017 - Injection

Injection flaws typically occur when untrusted data is accepted without being properly validated and/or encoded before being passed on to an interpreter as part of command or query. As a result the injected code change the intended functionality into something harmful that can access or process in unintended ways.

A2:2017 - Broken Authentication

Incorrectly implemented authentication and session management can make it possible to compromise user credentials, assume different user's identity, elevate access rights without authorization or exploit the system in many other ways resulting in unauthorized access to data and functionalities.

A3:2017 - Sensitive Data Exposure

It is all too common that a web application or API does not properly protect access to sensitive data. Data can be stolen or modified unless properly protected e,g, by applying authentication or at very least having it encrypted (encryption at rest or in transit).

A4:2017 - XML External Entities (XXE)

Many XML processors evaluate external entity references in an XML file, which can cause all kinds of unexpected grief especially when XML (or the referred entities!) are received from untrusted sources: they can be used to disclose internal files and file shares, scan internal ports, execute remote code or denial of service attacks. 

A5:2017 - Broken Access Control

Even when authenticating users is handled properly, the authorization of users often leaves much to be desired. By not implementing (preferably a robust role based) access policy or by failing to enforce the access restrictions one may enable an attacker to access unauthorized user data or system resources, or even to change the system's access rights etc.

A6:2017 - Security Misconfiguration

This is arguably the most common security mishap, which can be caused by variety of mistakes, omissions and overlooks. For example, the system might be using unsecure default configuration (e.g. the default admin password has not been changed), overly helpful error / debug messages reveal exploitable details about the system's behaviour and configuration, some ad hoc configuration change might have unintended consequences and so on. The security misconfiguration may take place at any level ranging from operating system, third party libraries and frameworks and/or application's business logic or settings. This topic also includes all security patches that were never installed...

A7:2017 - Cross-Site Scripting (XSS)

Application that accepts untrusted data from external source without proper validation and escaping is vulnerable against cross-site scripting. This allows an attacker to execute unintended scripts in the user's browsers, which may result in redirection to a malicious site, having the session hijacked or having the site's page content changed in some more or less subtle ways.

A8:2017 - Insecure Deserialization

Application that fail to deserialize objects securely may end up executing unintended remote code with various harmful consequences. Alternatively (or additionally) the application might be open to replay attacks, injection attacks and privilege escalation attacks.

A9:2017 - Using Components with Known Vulnerabilities

It is a common practice to utilise third party libraries, frameworks and other software components or services when developing a new application. It makes perfect sense: why re-invent the wheel when there is a perfectly good solution that already gets the job done? However, all these third-party solutions are subject to same security threats and software vulnerabilities as your application is and using an external solution with known vulnerabilities may end up compromising the application in question in various unexpected ways.

A10:2017 - Insufficient Logging & Monitoring

No one should consider logging as something developers do to debug the application. Logging is the primary method of keeping a record of application's various activities. Proper logging combined with active monitoring is how various misconducts can be detected, identified and ultimately reacted to. Logs are also the primary source of information after a breach has been detected and the response team is trying to figure out what exactly happened.