OWASP Top 10 2017 – a short vulnerability guide

OWASP Top 10 was established by the Open Web Application Security Project (OWASP) – a non-profit organization producing freely available articles and other information on web application security.

What is OWASP?

The Open Web Application Foundation is dedicated to creating a safer web application environment. It offers free articles, tools, technologies, and forums to empower every developer to create secure code. One of its most well-known projects is the OWASP Top 10.

What is OWASP Top 10?

OWASP Top 10 is a publicly shared list of the 10 most critical web application security vulnerabilities according to the Open Web Application Security Project In 2017. According to OWASP, a vulnerability is a weakness in an application that allows a malevolent party to cause harm to the application’s stakeholders (owners, users, etc.). 

The OWASP Top 10 list is developed by web application security experts worldwide and is regularly updated. It aims to educate companies on vulnerabilities and critical security risks they must mitigate to secure their web application.

This list is also under development for mobile applications.

Next to the Top 10 list, OWASP also publishes and maintains the following resources:

• OWASP Testing Guide: “Best Practices” for application testing
• OWASP Juice Shop: An intentionally insecure web application for security training

The OWASP Top 10 List 2017

1. Injection Attacks

An injection attack refers to an attacker’s input of malicious code into an application forcing it to execute commands that compromise data or the whole application. The most common types of injection attacks are SQL injections and cross-site scripting (XSS) attacks, but there are also code injections, command injections, CCS injections, and others.

SQL Injection refers to exploiting a SQL database vulnerability caused by the lack of masking or validation of meta-characters in user input. 

The attacker attempts to inject his own database commands through the application which has access to the database. However, as the request is not validated correctly, the inserted code changes the original SQL commands and therefore alters the results in favor of the attacker. 

With a successful attack, the attacker can spy on data, modify or delete it, and control the server. For this to work, the attacker has different ways to breach the system. For example, finding a way into the system is possible via response time or error messages.

How to prevent SQL injection attacks?

The main way to avoid injection flaws is by segregating the data in the database from commands and queries, i.e., separating it from the web application logic. This can be achieved in several different ways that include:

• Use a safe API that eliminates the use of the interpreter or uses parameterized queries 
• Introduce positive server-side input validation (whitelist)
• Where special characters are required in an application, these should be avoided, if possible, via the escape syntax of the particular interpreter
• Use database controls within queries such as the LIMIT SQL clause to minimize the amount of data that is exposed if an injection is successful
• Run a SQL Injection test

2. Broken Authentication

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens or exploit other implementation flaws to temporarily or permanently assume users’ identities. 

Abusing such vulnerability, an attacker may hijack user sessions and access or modify information he has no permission for.

How to prevent broken authentication vulnerabilities

To avoid attacks that take advantage of broken authentication, OWASP recommends the following actions:

• Introduce password checks that determine the weakness or strength of a password
• Align password length, complexity, and rotation with strong and modern evidence-based password policies
• Introduce multi-factor authentication that stops the usage of stolen credentials, brute force attacks, stuffing, and more
• Use a server-side secure session manager that generates new and random sessions IDs that are limited in time
• Avoid session IDs in URLs, store them securely, and ensure they are invalidated after user logout, session timeout, and idle
• Do not allow deployment when using default credentials 
• Limit or delay failed login attempts while monitoring them. Implement alerts to admins when an attack is detected

3. Sensitive Data Exposure

Sensitive data exposure is one of the most common attacks. It consists of gaining access, modifying, or stealing data that is not protected at rest or in transit (transmitted data). Such data frequently includes personally identifiable information (PII) such as credentials, health records, and credit card numbers. The lack of encryption is one of how data can end up being exposed.

The methods of gaining access to sensitive data vary but may include attackers stealing keys, executing an on-path attack (also known as a man-in-the-middle), stealing clear text data from the server or users, and more.

Fuzzing is a technique where invalid, random, or unexpected data is used to produce either unexpected states or gain access to hidden features. There are multiple types of fuzzing:

• Fuzzing based on observed data
• Fuzzing without previous knowledge

How to prevent sensitive data exposure?

You can do several things to protect any sensitive data from being exposed. These include:

• Implement a Transport Layer Security (TLS) to protect data in transit 
• Avoid storing sensitive data when possible, or storing longer than needed
• Encrypt all data at rest that needs to be stored
• Enforce encryption through HTTP Strict Transport Security (HSTS) or similar directives
• Do not cache user responses that contain sensitive data
• Classify data (processed, stored, or transmitted) and apply controls depending on the classification
• Implement strong standard algorithms, protocols, and keys
• Use hashing functions such as brcrypt, scrypt, Argon2, PBKDF2 that always salt and hash passwords

4. XML External Entities (XXE)

By default, many older or poorly configured XML processors evaluate external entity references within XML documents. This can be exploited by attackers who manage to upload an XML document (such as a DOCX or SVG file) or include malicious content in an XML document.

In this scenario, external entities can be used to extract internal files using the file URI handler. They may also enable internal file shares, internal port scanning, remote request execution, and performance of denial of service attacks (DOS).

How to prevent XML external entity attacks?

To prevent this attack, developers need to be trained to test for, identify, and mitigate XXE. In addition, OWASP recommends the following measures:

• Avoid the serialization of potentially sensitive information and use data formats such as JSON that are less complex
• Whitelist server-side input validation to avoid malicious data via XML documents
• Validate incoming XML through XML schema, i.e. XSD validation
• Make sure XML libraries and processors are regularly patched or upgraded
• Entirely disable Document Type Definition (DTD) processing in the parser (this also secures the parser against DOS)
• Review source code manually for instances of XXE

5. Broken Access Control

Broken access control refers to a vulnerability in enforcing restrictions on the actions of authenticated users. When restrictions are not properly enforced, attackers can use this weakness to gain unauthorized administrative access to system functionalities and sensitive personal data. They can also create, modify or delete data.

How to prevent broken access control?

It must be enforced in trusted server-side code or a server-less API to prevent access control. This will prevent attackers from modifying access control checks or metadata. OWASP lists the following measures to prevent this type of attack:

• Excluding public resources, deny by default
• Introduce access control mechanisms and use them repeatedly throughout the application
• Enforce record ownership
• Log and monitor access control failures, notify admins if needed (repeated login attempts)
• Invalidate JSON Web Tokens (JWT) after logout
• Enforce unique application business limit requirements via domain models
• Make sure metadata and backup files are not present in web roots
• Disable webserver directory listing
• Perform functional access control unit and integration tests

In addition, you may want to:

• Delete inactive or unnecessary accounts
• Implement multi-factor authentication to all access points
• Reduce the number of access points if some are not needed
• Implement the principle of least privilege (PoLP) 
• Shut down services that are not required on your server

6. Security Misconfiguration

Security misconfiguration is a common issue opening attack surfaces. This commonly is a result of: 

• Insecure default configurations
• Incomplete or ad hoc configurations
• Unpatched flaws
• Unused pages
• Unprotected files and directories
• Open cloud storage
• Misconfigured HTTP headers or encryption
• Verbose error messages containing sensitive information

Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded promptly.

Automated pentest tools like Crashtest Security can help detect security flaws that can lead to a breach via security misconfigurations. Sign up for a free trial and start your first scan in minutes.

How to prevent security misconfiguration attacks?

OWASP recommends the implementation of secure installation processes. Along with that, you should:

• Develop and automate a process that allows for fast and easy deployment of secure environments that are configured identically but accessible through different credentials
• Deploy a minimal platform and remove unused features and frameworks, or do not install
• Introduce segmented application architecture that separates components and tenants
• Review and update the configuration of all security notes, updates, and patches, particularly cloud storage permissions
• Automate the monitoring and verification of the effectiveness of security configurations in all environments
• Resolve security issues in real-time with the help of automated workflows

7. Cross-Site Scripting (XSS)

Cross-site scripting is the injection of client-side scripts into web applications, which is enabled by not validating and correctly encoding user input. The malicious scripts are executed within end-user browser and enable various attacks – from stealing their session to monitoring and altering any actions on the affected website. 

Different types of cross-site scripting attacks depend on whether the malicious scripts are injected non-persistent or persistent. Furthermore, a differentiation is made between the vulnerability caused by a flawed input validation on the client- or server-side.

How to prevent cross-site scripting (XSS)?

The main way to prevent this type of attack, according to OWASP, is to separate untrusted and unvalidated data input from active browser content. This can be done in the following ways:

• Use frameworks such as React JS, Ruby on Rails, and others that largely avoid XSS by design
• Avoid untrusted HTTP request data in HTML except in allowed slots as defined in the OWASP Cheat Sheet Series‘XSS Prevention’
• Use HTML encode prior to inserting any untrusted data in HTML elements
• Apply context-sensitive encoding against DOM-based XSS
• Implement a Content Security Policy (CSP) that creates source allow lists for client-side resources. This is helpful if there are no vulnerabilities that allow inserting malicious code through local files

8. Insecure Deserialization

Insecure Deserialization is an attack where a manipulated object is injected into the context of the web application. If application vulnerabilities exist, the object is deserialized and executed, resulting in SQL Injection, Path Traversal, Application Denial of Service, and Remote Code Execution.

How to prevent insecure deserialization?

To protect against insecure deserialization, OWASP recommends the following steps:

• Deny serialized objects from untrusted sources
• Utilize only serialization mediums that permit primitive data types
• Implement digital signatures to check the integrity of serialized objects
• Enforce strict type constraints during deserialization to detect unexpected clauses 
• When possible, isolate and run deserialization code in low privilege environments to prevent unauthorized actions
• Log instances of deserialization exceptions and failures
• Monitor and/or restrict any outgoing or incoming network connectivity coming from servers or containers that deserialize

9. Using Components With Known Vulnerabilities

The privileges of components such as libraries, frameworks, and other software modules are the same as those of an application. Data loss and server takeover are possible if a vulnerable component is exploited. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts. This is a widespread issue.

To help you assess whether you are using components with known vulnerabilities, fingerprinting scanners try to detect any web server or web application frameworks and associated versions running on the server.

How to avoid the use of components with known vulnerabilities?

To remediate the use of such components, you should:

• Only use components from official sources via secure links. Use signed packages to minimize the possibility of a malicious component being included in the package
• Monitor any libraries and components that are not maintained and do not provide security patches for older versions
• Deploy virtual patches to monitor, detect, and guard against issues with unpatched components
• Remove all unused dependencies as well as features, components, files, and documentation that are not needed
• Keep an up-to-date inventory of client-side and server-side components and their versions and dependencies. Monitor important sources for component vulnerabilities, and automate the process as much as possible
• Create and continuously execute monitoring, triaging, updating, or changing configurations during the lifetime of an application

10. Insufficient Logging And Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to attack systems further, maintain persistence, pivot to more systems, and tamper, extract or destroy data. 

Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

How to avoid attacks due to insufficient logging and monitoring?

To prevent the common vulnerabilities that arise due to this issue, OWASP recommends that you:

• Sufficient user context is logged during login, access control failure, and server-side input validation failures, and log data is kept long enough. This will help you spot suspicious activity and accounts
• Use log formats that are easily processed by log management solutions
• Implement audit trails with integrity controls for all high-value transactions to avoid deletion or attempts at tampering
• Use monitoring and alerts to spot suspicious activities on time and take measures
• Introduce an incident response and recovery plan to tackle attacks efficiently

Do you want to prevent every OWASP Top 10 Vulnerability?

The best and fastest way to prevent these vulnerabilities is to use an OWASP Security Testing Tool. We strongly believe that security testing is a must nowadays and it should be neither expensive nor time-consuming. That’s why we’ve developed an automated pentesting tool for organizations and businesses that will help you discover any vulnerability you might be exposed to (even those that aren’t on the list). Try the 14-day free trial now.