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.

Introduction to the OWASP Application Security Verification Standard (ASVS)

Originally published in Intopalo Digital's company blog:
https://www.intopalo.com/blog/2019-10-17-owasp/

This blog entry is about the OWASP Application Security Verification Standard (ASVS), and primarily intended as an introduction for people commonly involved in software acquisition and development projects. There are four high-level topics:

1. What is the ASVS
2.    Security levels of the ASVS
3. Reasons to use the ASVS
4. The ASVS structure

tl;dr: the ASVS is informative and authorative, which is to say, it is very useful, and most projects would do well to utilise it.

This text is primarily based on OWASP Application Security Verification Standard v4.0.

1 What is the ASVS

“The ASVS is a community-driven effort to establish a framework of security requirements and controls that focus on defining the functional and non-functional security controls required when designing, developing and testing modern web applications and web services.”

The ASVS version 4.0 was released in March 2019. It was developed in the open and is hosted in GitHub (https://github.com/OWASP/ASVS). As an open project anyone interested is invited to follow and participate in the development of future versions of the standard, for example, by submitting issues, pull requests and translations.

While there are other standards and practices covering software and information security issues, the ASVS 4.0 strives to become "the leading web applications and services standard, covering traditional and modern application architecture, and agile security practices and DevSecOps culture". With this goal in mind the ASVS 4.0 is aligned with other well-known projects and standards, such as Common Weakness Enumeration, NIST 80-63-3 Digital Identity Guidelines, and PCI DSS 3.2.1 Requirement 6.5.x for application design, coding, testing, secure code reviews and penetration tests.

As of version 4.0 the ASVS is intended to become the baseline ASVS for all other related projects, such as the Mobile Application Security Verification Standard (MASVS) and the Internet of Things Application Security Verification Standard (IoT ASVS), which is currently included in the ASVS 4.0 as Appendix C as an early preview.

2 Security levels of the ASVS

The ASVS has two stated primary goals:

1. to help organisations develop and maintain secure applications
2. to allow security service vendors, security tools vendors, and consumers to align their requirements and offerings.

To accomplish these the ASVS defines three security verification levels starting from basic and progressing to increasingly more demanding requirements. 

2.1 ASVS Level 1 - Basic

This is the bare-bones level for low assurance levels and should be considered as the minimum that (most if not) all applications should strive for. Level 1 is the only level that is completely penetration testable without having access to documentation, source code, configuration and/or the development team. However, while "black box" approach is possible it is by no means recommended as it is completely unable to cope with the harsh realities and security threats of running an application "in production".

In order achieve Level 1the application must "adequately defend against application security vulnerabilities that are easy to discover and included in the OWASP Top 10 and other similar check lists". As such this level is mainly intended for applications that do not handle sensitive data.

2.2 ASVS Level 2 - Standard

This is the recommended level for most applications. At very least it should be considered when the application handles significant business-to-business transactions or process sensitive (e.g. health care) information, implement business sensitive / critical functions, or is used in industries where integrity is a critical facet to protect business.

In order to achieve Level 2, the application must "adequately defend against most of the risks associated with software today" by having security controls in place, effective and used within the application. 

2.3 ASVS Level 3 - Advanced

This is the advanced level intended for applications that are used in areas such as military, government, health and safety or critical infrastructure - generally speaking Level 3 should be applied whenever significant levels of security verification is required.

In order to achieve Level 3, the application must "adequately defend against advanced application [of] security vulnerabilities and also demonstrate principles of good security design".

A Level 3 application should be meaningfully modularized with multiple layers of security and controls to ensure confidentiality, integrity, availability, authentication, authorisation, non-repudiation and auditing. In practice we are talking about topics such as proper use of data encryption, input validation, transactions, system scalability and logging. It should go without saying that proper documentation is also expected.

3 Reasons to use the ASVS

3.1 As Secure Coding Checklist

According to the OWASP, "one of the best ways to use the Application Security Verification Standard is to use it as a blueprint to create a Secure Coding Checklist specific to your application, platform or organization".

While using automated DAST (Dynamic Application Security Testing), SAST (Static AST) or IAST (Interactive AST) tools are recommended as part of the development process, it should be noted that no more than about half of the ASVS can be completed without human assistance. For example, finding flaws in business logic and access control are (at least in the foreseeable future) beyond the capabilities of automated tools.

3.2 As a framework for Guiding the Procurement of Secure Software

Any person who is about to buy an application or make an order development project would benefit from relying on the ASVS by specifying that the application must meet the requirements for the ASVS Level X. This should ensure that the delivery will meet certain level of expectations.

This works even better when combined with the OWASP Secure Software Contract Annex.

3.3 As detailed security architecture guide

Even if the ASVS is not directly used in a project, it is a great resource for security / software architects. It lists a wide variety of problems and risks while helping to come up with reasonable solutions.

3.4 As a guide for automated unit and integration tests

By turning the ASVS checks into automated unit and integration tests the quality assurance work can be improved greatly - especially when running these tests as part of the project's Continuous Integration / Delivery setup.

3.5 As support for secure development training

In many ways the ASVS defines what "secure software" in practical terms. It will help the developers to focus on proactive controls and reliable solution methods.

3.6 As a driver for Agile Application Security

The ASVS can be included in an agile development process to define specific tasks that need to be implemented in order to have a secure product. These tasks can be included the Product Backlog and discussed with stakeholders as much as they can be used to guide agile design work.

4 ASVS structure

The ASVS 4.0 is divided into 14 chapters.

V1: Architecture, Design and Threat Modelling Requirements

“Security architecture has almost become a lost art in many organisations. [...] Architecture is not an implementation, but a way of thinking about a problem that has potentially many different answers, and no one single ‘correct’ answer.”

This chapter covers the primary aspects of any sound security architecture: availability, confidentiality, processing integrity, non-repudiation, and privacy. All these aspects must be built in to the application, and usually cannot be meaningfully added as an afterthought at the end of the project.

V2: Authentication Verification Requirements

“Authentication is the act of establishing, or confirming, someone (or something) as authentic and that claims made by a person or about a device are correct, resistant to impersonation, and prevent recovery or interception of passwords.”

The classic combination of username and password is no longer enough, when security is considered. For example, NIST 800-63 considers these to be public information. A modern application requires much more robust approach to authentication.

V3: Session Management Verification Requirements

“One of the core components of any web-based application or stateful API is the mechanism by which it controls and maintains the state for a user or a device interacting with it.”

This chapter aims to ensure that an application satisfies the following high-level session management requirements:

• Sessions are unique to each individual and cannot be guessed or shared.
• Sessions are invalid when no longer required and timed out during periods of inactivity.

V4: Access Control Verification Requirements

“Authorization is the concept of allowing access to resources only to those permitted to use them.”

 This chapter aims to ensure that an application satisfies the following high-level requirements:

• Persons accessing resources hold valid credentials to do so.
• Users are associated with a well-defined set of roles and privileges.
• Role and permission metadata are protected from replay or tampering.

V5: Validation, Sanitation and Encoding Verification Requirements

“The most common web application security weakness is the failure to properly validate input coming from the client or the environment before directly using it without any output encoding.”

This chapter aims to ensure that an application satisfies the following high-level requirements:

• Input validation and output encoding architecture have an agreed pipeline to prevent injection attacks.
• Input data is strongly typed, validated, range or length checked, or at worst, sanitised or filtered.
• Output data is encoded or escaped as per the context of the data as close to the interpreter as possible.

V6: Stored Cryptography Verification Requirements

 This chapter aims to ensure that an application satisfies the following high-level requirements:

• All cryptographic modules fail in a secure manner and that errors are handled correctly.
• A suitable random number generator is used.
• Access to keys is securely managed. 

V7: Error Handling and Logging Verification Requirements

“The primary objective of error handling and logging is to provide useful information for the user, administrators and incident response teams. The objective is not to create massive amounts of logs, but high-quality logs, with more signal than discarded noise.”

This chapter aims to ensure that an application satisfies the following high-level requirements:

• No collecting or logging [of] sensitive information unless specifically required.
• Ensure all logged information is handled securely and protected as per its data classification.
• Ensure that logs are not stored forever, but have an absolute lifetime that is as short as possible.

V8: Data Protection Verification Requirements

There are three key elements to sound data protection: Confidentiality, Integrity and Availability (CIA).

This chapter aims to ensure that an application satisfies the following high-level requirements:

• Confidentiality: data should be protected from unauthorized observation or disclosure both in transit and when stored.
• Integrity: data should be protected from being maliciously created, altered or deleted by unauthorized attackers.
• Availability: data should be available to authorized users as required. 

V9: Communication Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:

• TLS (Transport Layer Security) or strong encryption is always used, regardless of the sensitivity of the data being transmitted.
• The most recent, leading configuration advice is used to enable and order preferred algorithms and ciphers.
• Weak or soon to be deprecated algorithms and ciphers are ordered as a last resort.
• Deprecated or known insecure algorithms and ciphers are disabled.

V10: Malicious Code Verification Requirements

“Finding malicious code is proof of the negative, which is impossible to completely validate. Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality.”

This chapter aims to ensure that an application satisfies the following high-level requirements:

• Malicious activity is handled securely and properly to not affect the rest of the application.
• [Application] does not have time bombs or other time-based attacks.
• [Application] does not "phone home" to malicious or unauthorized destinations.
• [Application] does not have back doors, Easter eggs, salami attacks, rootkits, or unauthorized code that can be controlled by an attacker.

V11: Business Logic Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:

• The business logic flow is sequential, processed in order, and cannot be bypassed.
• Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on.
• High value business logic flows have considered abuse cases malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks. 

V12: File and Resources Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:

• Untrusted file data should be handled accordingly and in a secure manner. 
• Untrusted file data obtained from untrusted sources are stored outside the web root and with limited permissions.

V13: API and Web Service Verification Requirements

This chapter aims to ensure that an application that uses trusted service layer APIs (commonly using JSON, XML or GraphQL) has:

• Adequate authentication, session management and authorization of all web services. 
• Input validation of all parameters that transit from a lower to higher trust level.
• Effective security controls for all API types, including cloud and Serverless API.

V14: Configuration Verification Requirements

This chapter aims to ensure that an application has:

•  A secure, repeatable, automatable build environment.
• Hardened third party library, dependency and configuration management such that out of date or insecure components are not included by the application.
• A secure-by-default configuration, such that administrators and users have to weaken the default security posture.