The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
What is OWASP?
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.
First of all, let’s answer the What is OWASP? question for those who did not read our previous AppSec Blog. 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. In addition, they are reliable. That is probably one of the main reasons that OWASP has reached its mass usage size, reputation, and importance today.
As a non-profit foundation, OWASP accepts donations. 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. In a conclusion, OWASP is not managed by commercial interests.
Further information is in our What is OWASP? Blog post.
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 of What is OWASP? 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 worlds 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
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.
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?
- Do not use interpreters or have an interface that allows bind 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
Option 1: Using Prepared Statements
Option 2: Using Stored Procedures
Option 3: Using Whitelist for Inputs
Option 4: Not Using User Inputs
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.
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 dont need. Delete these data as soon as possible. If you dont 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.
- Dont 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.
A5 – BROKEN ACCESS CONTROL
Users should not function outside of their planning permissions with access management. Unauthorized information access, alteration or deletion of all records, or executing a business process outside of the users limits are all common outcomes of failures.
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.
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.
A web applications 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 portion of the application stack.
- Features that arent 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 protected 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)
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.
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.
Serialization can be used in a variety of applications, including:
- Inter-process communication and remote communication
- Email brokers, online platforms, and wire protocols
- 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 isnt an option, try one or more of the following:
- Integrity tests, such as digital signatures, should be added on 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 youre using.
- If one or more software is insecure, unsupported, or out-of-date.
- If you dont check for bugs on a routine basis, youre 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 havent been modified in a while or dont have security updates for older versions. If patching isnt 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 or 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.