A Closer Look at OWASP Top 10 Security Risks & Vulnerabilities

In this article, we will take a closer look at the OWASP Top 10 security risks and vulnerabilities, which are ranked according to the frequency of security flaws discovered, the severity of the vulnerabilities, and the magnitude of their potential impact. 

The Open Web Application Security Project (OWASP) is a non-profit foundation that aims to improve the security of software. Since OWASP is a non-profit foundation, most of the tools are free and open sources.

Users can join the OWASP community by making monthly/annual payments or free for a lifetime. Users gain privileges like voting in OWASP Global Board elections, training discounts, and access to professional mentoring programs based on the membership type.

Now, let’s take a closer look at OWASP Top 10 security risks and vulnerabilities.

What is OWASP Top 10?

OWASP Top Ten means Top 10 most critical security risks against web applications. Risks are ranked according to the frequency of security flaws discovered, the severity of the vulnerabilities, and the magnitude of their potential impact.

We had briefly talked about OWASP Top 10 in our previous AppSec Blog, What is OWASP? This time we will dive deeper and take a look at each element. Also, we are going to talk about some prevention techniques for these security risks.

The list was last shared in 2017 and previously in 2013. You can see the differences between the 4 years in the image below:

Why is the OWASP Top 10 Important?

The importance in a closer look at OWASP Top 10 lies in the direct out-of-the-box information it provides. It serves as an essential checklist and internal Web application development standard for many of the world’s largest organizations. Also, it gives organizations a priority on what risks to focus on and helps them understand, identify, mitigate, and fix vulnerabilities in their technology. Each identified risk is prioritized based on prevalence, detectability, impact, and availability. In addition, these criteria also play a role in being important for OWASP Top 10.

Let’s Talk About Each Item of the List in Detail:

2017 OWASP Top 10 list:

• A1 – Injection
• A2 – Broken Authentication
• A3 – Sensitive Data Exposure
• A4 – XML External Entities (XXE)
• A5 – Broken Access Control
• A6 – Security Misconfiguration
• A7 – Cross-Site Scripting (XSS)
• A8 – Insecure Deserialization
• A9 – Using Components with Known Vulnerabilities
• A10 – Insufficient Logging & Monitoring

A1 – INJECTION

Injection attacks occur when dangerous data is sent to a code interpreter as a form entry or as a different data type to a web app. For example, a hacker might enter SQL code into a form that awaits a text username. If this input is not safely processed, this is going to lead to a SQL code execution. This is called SQL injection.

An application is vulnerable if:

• The data provided by the user is not verified, filtered, or sterilized by the application.
• Dynamic queries or non-parameterized executed with no context-sensitive escaping are used straight in the interpreter.
• Dangerous data is used in the object-relational mapping (ORM) search parameters to get valuable, important records.

Also see: The Ultimate Guide to SQL Injection

SQL Injection

In modern systems, SQL injection often happens by inputting malicious SQL requests to an endpoint of an API provided by a service. SQL injection might allow a hacker to get root access to a host and get full control in its most important form.

*SQL is a domain-specific language used to manage databases.

SQL Injection can be divided into three types:

1. In-band SQLi (Error-Based & Union-Based)

In-band SQL Injection happens if a hacker is capable of using the same communication way to both start the attack and get the results

2. Inferential SQLi (Blind-Boolean-Based & Blind-Time-Based)

The hacker can exploit this to send requests and determine differences in the responses of requests, which will approve if the requests sent include a true or false return.

3. Out-of-band SQLi

Out-of-band SQL Injection happens if a hacker is not able to connect the same channel to start the attack and get results.

How to Prevent Injection?

Recommendations

• Do not use interpreters or have an interface that allows binding variables.
• Binding variables let the interpreter tell apart between code and data.
• Encode all inputs before sending them to the interpreter.
• Always have a “whitelist” for login verification on every user-provided inputs.
• Minimize database privileges to minimize the impact.

Primary Defenses:

• Option 1: Using Prepared Statements
• Option 2: Using Stored Procedures
• Option 3: Using Whitelist for Inputs
• Option 4: Not Using User Inputs

Additional Defenses:

• Option 1: Using Least Privilege
• Option 2: Performing Whitelist Input Validation

A2 – BROKEN AUTHENTICATION

Validation of the user’s identity, authentication, and session management is important to keep safe against authentication attacks. A vulnerable application:

• Allows automated attacks, such as filling credentials, where the hacker has a true list of usernames and passwords.
• Allows default, weak, or known passwords.
• Has weak or not effective forgot password functions, such as “knowledge-based answers“.
• Stores plain text passwords or encrypt passwords with weak hash.
• Using weak multi-factor authentication.
• Shows Session IDs in the URL.

Vulnerabilities in login systems might give hackers access to user credentials and even the capability to take control of an entire system using an administrator account. As an example, a hacker might get a list of thousands of known credentials leaked during a data leakage and use an automation tool to try all those credentials to see if there are any that work.

For more information, check our article The Ultimate Guide for Broken Authentication.

How to Prevent Broken Authentication?

• If possible, use multi-factor authentication to escape from automated attacks, brute force, and stolen credential attacks.
• Do not use any default credentials, especially for admin users.
• Use password-checking systems for weak-passwords.
• Use long and complex password policies.
• Limit and report consecutive failed login attempts. Log these attempts and have an alert system.
• Have a server-side, safe, built-in session manager that creates a new session ID with strong complexity after each login. Session IDs should not be exposed in the URL and deleted after logouts.

A3 – SENSITIVE DATA EXPOSURE

The protection necessities of data at rest and in transit should be defined. For example, credentials, credit card numbers, health entries, personal and commercial data require additional protection. The following points should be questioned for this kind of data:

• Is data in transit encrypted? (External internet traffic is very dangerous. Check all internal traffic between load balancers, servers, or back-end systems.)
• Are there any weak cryptographic algorithms being used?
• Are there any default, weak, or re-used crypto keys being used?
• Is there any enforced encryption system?
• Does the user agent check if the received server certificate is not invalid?

How to Prevent Sensitive Data Exposure?

• If web apps do not keep sensitive data (credentials, personal data, etc.) safe, hackers can get that data and use or sell it for bad purposes.
• The risk of data exposure can be reduced by enabling the encryption of all sensitive data as well as preventing the caching of important data.
• Also, web application developers must ensure that the system does not store any sensitive data if not necessary.
• Data that is processed, stored, or transmitted should be classified. After classifying, define which data is important according to laws, or business matters.
• Set control mechanisms for each different classification.
• You should not store any important data that you don’t need. Delete these data as soon as possible. If you don’t store data nobody can steal it.
• Encrypt every piece of sensitive data at rest.
• Use up-to-date and powerful encryption algorithms.
• Use security protocols like TLS for data in transit.
• Don’t use caching if responses return sensitive data.
• Use powerful and up-to-date salted hashing functions for storing passwords.

A4 – XML EXTERNAL ENTITIEs (XXE)

Applications might be vulnerable to attack if:

• The application receives XML directly from external sources.
• XML documents that are parsed with an XML processor.
• If XML processors in the web app have document type definitions not disabled.
• The application uses an older version of SOAP than version 1.2.
• If the application is vulnerable to XXE it means the app is also vulnerable to denial-of-service attacks.

How to Prevent XML External Entities?

• Keep updating your XML Parser to the latest edition.
• To detect and mitigate XXE, developers must be educated.
• Use fewer complex data formats, such as JSON, and avoid serializing sensitive data wherever possible.
• Both XML processors and libraries used by the program or on the underlying operating system should be patched or upgraded. Check for dependencies with dependency checkers. SOAP should be updated to version 1.2 or higher.
• Disable the processing of XML external entities and DTDs in all XML parsers in the application.
• To avoid hostile data in XML documents, headers, or nodes, use whitelisting server-side input validation, filtering, or sanitization.
• Check that the XML or XSL file upload feature uses XSD validation or something similar to validate incoming XML.

The easiest approach to avoid XXE attacks is to make web applications support a less complicated form of data, such as JSON, or to patch XML parsers and stop using external entities in an XML program. JavaScript Object Notation (JSON) is a type of human-readable notation that is commonly used to transfer data over the internet. JSON is a language-agnostic format that can be read by a variety of programming languages, including its origins in JavaScript.

The following are examples of typical access management flaws:

• Modifying the URL, internal application state, or HTML page, or just using a custom API attack tool, are different ways to get past access control tests.
• Allowing a user’s primary key to be changed to another user’s record, allowing them to access or update another user’s account.
• Privilege can be elevated by acting as a user while not logging in, or as an admin while logged in as a user.
• Unauthorized API access is possible due to a CORS misconfiguration.

This article may interest you: A Comprehensive Guide to Broken Access Control

How to Prevent Broken Access Control?

Access control is only successful if it is implemented in reliable server-side code where the access control check can’t be modified by the hacker.

• Access control systems should be applied once and uniformly across the application.
• Instead of giving access to the user to build, read, change, or remove any records, access controls must ensure record ownership.
• Domain models must implement unique application business limit specifications.
• Stop using directory listing on the web server, and make sure file metadata and backup files do not rest in the webroot.
• Failures in access control should be recorded, and administrators should be notified when necessary.
• To reduce the possibility of automated attacks, rate limit API and controller access.

Web application access controls can be protected by ensuring that authorization tokens are used and that they are strictly controlled. When users log in to several programs, they are given authorization tokens. The authorization token will be required for any privileged request a user makes. This is a safe way to verify that the user is who they claim to be without having to enter their login credentials repeatedly.

A6 – SECURITY MISCONFIGURATION

The application might be vulnerable if the application is:

• Poorly configured permissions on cloud servers.
• Lack of sufficient security hardening across some portions of the application stack.
• Features that aren’t required are enabled or installed.
• Default accounts and passwords are not changed.
• Revealing unnecessary information in error messages.
• The latest security features are missing or not configured securely on upgraded systems.
• Security headers and directives are either not sent or are not set to protect values by the server.

How to Prevent Security Misconfiguration?

Secure installation processes should be implemented, including:

• A repeatable hardening procedure that makes it simple and easy to install another properly protected area. This procedure can be automated to reduce the time and effort taken to set up a new safe environment.
• A minimal platform with no additional functionality, modules, documentation, or samples. Unused functions and frameworks should be removed or not installed.
• In all environments, an automatic method to test the effectiveness of the configurations and settings.
• With segmentation or cloud protection groups, a segmented framework architecture offers efficient, safe isolation between components or tenants.
• Security instructions such as “Security Headers” are being sent to clients.

This can be avoided by eliminating any unused code features and ensuring the error messages are more generic.

A7 – CROSS-SITE SCRIPTING (XSS)

When web applications enable users to insert custom code into a URL path or into a page that would be used by other users, cross-site scripting vulnerabilities arise. This flaw can be used to inject malicious JavaScript code into a victim’s browser. An attacker might, for example, send a victim an email that claims to be from a reputable bank which includes a connection to the bank’s website. This connection could have malicious JavaScript code attached to the end of it. If the bank’s website isn’t correctly secured against cross-site scripting, malware code can be executed in the victim’s browser when they click on the URL.

Reflected XSS: As part of the HTML output, the framework or API provides unvalidated and unescaped user input. If the attack is effective, the hacker will be able to run arbitrary HTML and JavaScript in the victim’s browser. Usually, the user would be needed to click on a malicious connection that leads to a page controlled by the attacker.

Stored XSS: The web application or API keeps unprocessed user input that can be accessed by another user or administrator at a later time. Stored XSS is often identified as a high or critical risk.

DOM XSS: DOM XSS is a vulnerability that affects JavaScript implementations, single-page programs, and APIs that dynamically include attacker-controllable data to a page. Ideally, the program does not transmit attacker-controllable data to insecure JavaScript APIs.

How to Prevent XSS?

Separating untrusted data from active window content is required to prevent XSS. This can be accomplished by using the following methods:

• Use frameworks that, by default, avoid XSS, such as the latest Ruby on Rails and React JS.
• Learn the XSS security shortcomings of each framework and how to manage use cases that aren’t secured.
• Reflected and Stored XSS vulnerabilities are handled by escaping untrusted HTTP request data depending on the context in the HTML response.
• When editing the browser file on the client-side, use context-sensitive encoding to prevent DOM XSS.
• Using a Content Security Policy (CSP) against XSS is a defense-in-depth mitigation control.

A8 – INSECURE DESERIALIZATION

This threat is aimed at the numerous web apps that serialize and deserialize data regularly. Serialization is the process of transforming objects from program code into a format that could be used for other uses, such as saving data on a disk or broadcasting it. Deserialization is the reverse of serialization: it transforms serialized data into objects that a program can use.

You can use serialization in a variety of applications, including:

• Inter-process communication and remote communication.
• Email brokers, online platforms, and wire protocols.
• Persistence/Caching.
• File systems, databases, and cache servers.
• API authentication tokens, HTTP cookies, HTML form parameters.

If applications and APIs deserialize aggressive or tampered objects supplied by an intruder, they will be vulnerable. This can lead to one of two forms of attacks:

• If the program has classes that can change actions before or after deserialization, the attacker can adjust application logic or gain arbitrary remote code execution.
• Access-control-related attacks, for example, are typical data tampering attacks in which current data mechanisms are used but the content is modified.

How to Prevent Insecure Deserialization?

The only secure approach is to avoid accepting serialized data from unknown sources or serialization formats that only support primitive data types. If that isn’t an option, try one or more of the following:

• Integrity tests, such as digital signatures, should be added to all serialized objects to avoid the creation of hostile objects or data tampering.
• Since the code usually assumes a definable collection of classes, strict type restrictions should be applied during deserialization before object creation.
• Where possible, isolating and operating code that deserializes in low-privilege areas.
• Exceptions and errors during deserialization should be logged.
• Containers or servers that deserialize should have their incoming and outgoing network access limited or tracked.
• Deserialization should be monitored, and if a device deserializes often, a warning should be sent to the admin.

A9 – USING COMPONENTS WITH KNOWN VULNERABILITIES

Application is likely vulnerable:

• If you’re unaware of the versions of all the components you’re using.
• If one or more software is insecure, unsupported, or out-of-date.
• If you don’t check for bugs on a routine basis, you’re putting yourself at risk.
• If the underlying platform, systems, and dependencies are not fixed or updated in a risk-based, timely manner.
• If program engineers do not check new, upgraded, or patched libraries for functionality.

How to Prevent Using Components with Known Vulnerabilities?

• A patch management process should be in place to:
• Disable all unused dependencies, functions, components, data, or documents.
• Keep track of the versions of both client-side and server-side modules, as well as their dependencies.
• Just use safe connections to access components from official sources. To reduce the possibility of a changed, malicious portion being included, prefer signed packages.
• Keep an eye out for libraries and modules that haven’t been modified in a while or don’t have security updates for older versions. If patching isn’t an option, consider using a virtual patch to track, diagnose, and protect against the problem.

A10 – INSUFFICIENT LOGGING & MONITORING

Insufficient logging, tracking, monitoring, and active response will happen at any time:

• Activities for example logins failed logins, and high-value transactions are not logged.
• No, inadequate, or undefined log messages are produced by warnings and errors.
• Suspicious behavior is not tracked in application and API logs.
• There is no online backup system for logs.
• There are no ineffective alerting thresholds or response escalation mechanisms in operation.
• DAST tools do not trigger alerts.
• In real-time or near real-time, the program is unable to track, intensify, or warn of active attacks. Most web apps do not take sufficient steps to determine data breaches. The average time it takes for a hack to be detected is about 200 days. As a consequence, criminals have a lot of time to cause harm before being detected. Web developers can use reporting and tracking, as well as incident management plans, to ensure that they are aware of threats on their software, according to security experts.

How to Prevent Insufficient Logging & Monitoring?

According to the level of risk associated with the data stored or handled by the application:

• Determine that all login, access management, and server-side input validation errors will be logged with enough user background to recognize suspected accounts.
• Be sure that logs are created in a format that automated log management solutions can easily process.
• Establish appropriate tracking and alerting so that unusual activity can be identified and dealt with quickly.

Conclusion

It is crucial for businesses to take cybersecurity seriously in order to protect sensitive data and maintain trust with customers. OWASP Top 10 Security vulnerabilities, such as broken authentication, and sensitive data exposure, are just a few examples of the many ways in which attackers can exploit weaknesses in your system. However, by following best practices, you can significantly reduce the risk of a successful attack. Contact us today to learn more about how we can help protect your business from cyber threats.

Check out our Vulnerability Management and Risk & Compliance services to stay secure!