OWASP Top 10
What is OWASP?
OWASP stands for the Open Web Application Security Project, an online community that produces articles, methodologies, documentation, tools, and technologies in the field of web application security.
What is the OWASP Top 10?
OWASP Top 10 is the list of the 10 most common application vulnerabilities. It also shows their risks, impacts, and countermeasures. Updated every three to four years, the latest OWASP vulnerabilities list was released in 2018. Let’s dive into it!
The Top 10 OWASP vulnerabilities in 2020
The Top 10 OWASP vulnerabilities in 2020 are:
Injection
Broken Authentication
Sensitive Data Exposure
XML External Entities (XXE)
Broken Access control
Security misconfigurations
Cross-Site Scripting (XSS)
Insecure Deserialization
Using Components with known vulnerabilities
Insufficient logging and monitoring
Injection
A code injection happens when an attacker sends invalid data to the web application with the intention to make it do something that the application was not designed/programmed to do. Perhaps the most common example around this security vulnerability is the SQL query consuming untrusted data.
Main recommendations to prevent injection:
Separation of data from the web application logic.
Implement settings and/or restrictions to limit data exposure in case of successful injection attacks.
Without appropriate measures in place, code injections represent a serious risk to website owners. These attacks leverage security loopholes for a hostile takeover or the leaking of confidential information.
Broken Authentication
A broken authentication vulnerability can allow an attacker to use manual and/or automatic methods to try to gain control over any account they want in a system – or even worse – to gain complete control over the system.
Types of Broken Authentication Vulnerabilities:
Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
Permits brute force or other automated attacks.
Permits default, weak, or well-known passwords, such as ”Password1″ or “admin/admin.″
Uses weak or ineffective credential recovery and forgot-password processes, such as “knowledge-based answers,” which cannot be made safe.
Uses plain text, encrypted, or weakly hashed passwords.
Has missing or ineffective multi-factor authentication.
Exposes session IDs in the URL (e.g., URL rewriting).
Does not rotate session IDs after successful login.
Does not properly invalidate session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout or a period of inactivity.
Main recommendations to prevent Broken Authentication vulnerability:
Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential reuse attacks.
Do not ship or deploy with any default credentials, particularly for admin users.
Implement weak-password checks, such as testing new or changed passwords against a list of the top 10,000 worst passwords.
Align password length, complexity, and rotation policies with NIST 800-63 B’s guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence-based password policies.
Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
Limit or increasingly delay failed login attempts.
Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL. Ids should also be securely stored and invalidated after logout, idle, and absolute timeouts.
Sensitive Data Exposure
Sensitive data exposure is one of the most widespread vulnerabilities on the OWASP list. It consists of compromising data that should have been protected.
Sensitive data:
Credentials
Credit card numbers
Social Security Numbers
Medical information
Personally identifiable information (PII)
Other personal information
There are two types of data:
Stored data – data at rest
Transmitted data – data that is transmitted internally between servers, or to web browsers
How to Prevent Data Exposure:
Classify data processed, stored, or transmitted by an application.
Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
Apply controls as per the classification.
Don’t store sensitive data unnecessarily.
Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation.
Data that is not retained cannot be stolen.
Make sure to encrypt all sensitive data at rest.
Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.
Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters.
Enforce encryption using directives like HTTP Strict Transport Security (HSTS).
Disable caching for responses that contain sensitive data.
Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2.
Verify independently the effectiveness of configuration and settings.
XML External Entities (XXE)
XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser.
XML external entity attack vectors:
Vulnerable XML processors if malicious actors can upload XML or include hostile content in an XML document
Vulnerable code
Vulnerable dependencies
Vulnerable integrations
How to prevent XML external entity attacks:
Whenever possible, use less complex data formats, such as JSON, and avoid serialization of sensitive data.
Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system.
Use dependency checkers (update SOAP to SOAP 1.2 or higher).
Disable XML external entity and DTD processing in all XML parsers in the application, as per the OWASP Cheat Sheet ‘XXE Prevention.’
Implement positive (“allowlisting”) server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes.
Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar.
SAST tools can help detect XXE in source code – although manual code review is the best alternative in large, complex applications with many integrations.
If these controls are not possible, consider using:
Virtual patching
API security gateways
Web Application Firewalls (WAFs) to detect, monitor, and block XXE attacks
Broken Access Control
In website security, access control means putting a limit on what sections or pages visitors can reach, depending on their needs.
For example, if you own an ecommerce store, you probably need access to the admin panel in order to add new products or to set up a promotion for the upcoming holidays. However, hardly anybody else would need it. Allowing the rest of your website’s visitors to reach your login page only opens up your ecommerce store to attacks.
Here are some examples of what we consider to be “access”:
Access to a hosting control / administrative panel
Access to a server via FTP / SFTP / SSH
Access to a website’s administrative panel
Access to other applications on your server
Access to a database
Attackers can exploit authorization flaws to the following:
Access unauthorized functionality and/or data
View sensitive files
Change access rights
Broken Access Control Prevention:
With the exception of public resources, deny by default.
Implement access control mechanisms once and reuse them throughout the application, including minimizing CORS usage.
Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record. Note: For example, if a user logs in as “John,” he could only create, read, update or delete records associated with the ID of “John,” never the data from other users.
Unique application business limit requirements should be enforced by domain models.
Disable web-server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
Log access control failures, alert admins when appropriate (e.g. repeated failures). Note: We recommend our free plugin for WordPress websites, that you can download directly from the official WordPress repository.
Rate limit API and controller access to minimize the harm from automated attack tooling.
JWT tokens should be invalidated on the server after logout.
Developers and QA staff should include functional access control units and integration tests.
Security Misconfigurations
At its core, brute force is the act of trying many possible combinations, but there are many variants of this attack to increase its success rate. Here are the most common:
Unpatched flaws
Default configurations
Unused pages
Unprotected files and directories
Unnecessary services
Misconfiguration can happen at any level of an application stack, including:
Network services
Platform
Web-server
Application server
Database
Frameworks
Custom code
Pre-installed virtual machines
Containers
Storage
Example of Security Misconfigurations:
The application server’s configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws, such as component versions. They are known to be vulnerable.
In order to prevent security misconfigurations:
A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. Automate this process in order to minimize the effort required to set up a new secure environment.
A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.
A task to review and update the configurations appropriate to all security notes, updates, and patches as part of the patch management process. In particular, review cloud storage permissions.
A segmented application architecture that provides effective and secure separation between components or tenants, with segmentation, containerization, or cloud security groups.
Sending security directives to clients, e.g. Security Headers.
An automated process to verify the effectiveness of the configurations and settings in all environments.
Cross-Site Scripting (XSS)
Cross Site Scripting (XSS) is a widespread vulnerability that affects many web applications. XSS attacks consist of injecting malicious client-side scripts into a website and using the website as a propagation method.
Generally, XSS vulnerabilities require some type of interaction by the user to be triggered, either via social engineering or via a visit to a specific page. If an XSS vulnerability is not patched, it can be very dangerous to any website.
Types of XSS:
Reflected XSS: The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to interact with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites, advertisements, or similar.
Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered high or critical risk.
DOM XSS: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs. Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM-node replacement or defacement (such as Trojan login panels), attacks against the user’s browser such as malicious software downloads, keylogging, and other client-side attacks.
How to Prevent XSS Vulnerabilities:
Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS. Learn the limitations of each framework’s XSS protection and appropriately handle the use cases which are not covered.
Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The OWASP Cheat Sheet for XSS Prevention has details on the required data escaping techniques.
Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context-sensitive escaping techniques can be applied to browser APIs as described in the OWASP Cheat Sheet for DOM based XSS Prevention.
Enabling a content security policy (CSP) is a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks).
Insecure Deserialization
Every web developer needs to make peace with the fact that attackers/security researchers are going to try to play with everything that interacts with their application–from the URLs to serialized objects.
In computer science, an object is a data structure; in other words, a way to structure data. To make it easier to understand some key concepts:
The process of serialization is converting objects to byte strings.
The process of deserialization is converting byte strings to objects.
Example:
A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker notices the “R00” Java object signature, and uses the Java Serial Killer tool to gain remote code execution on the application server.
How to Prevent Insecure Deserializations:
The best way to protect your web application from this type of risk is not to accept serialized objects from untrusted sources.
If you can’t do this:
Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.
Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable.
Isolating and running code that deserializes in low privilege environments when possible.
Logging deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.
Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
Monitoring deserialization, alerting if a user deserializes constantly.
Using Components with Known Vulnerabilities
These days, even simple websites such as personal blogs have a lot of dependencies. We can all agree that failing to update every piece of software on the backend and frontend of a website will, without a doubt, introduce heavy security risks sooner rather than later.,
How to Avoid Using Components with Known Vulnerabilities:
Remove all unnecessary dependencies.
Have an inventory of all your components on the client-side and server-side.
Obtain components only from official sources.
Get rid of components not actively maintained.
Use virtual patching with the help of a Website Application Firewall.
Insufficient Logging and Monitoring
The importance of securing a website cannot be understated. While 100% security is not a realistic goal, there are ways to keep your website monitored on a regular basis so you can take immediate action when something happens.
Example:
An attacker scans for users with a common password. They can take over all accounts with this password. For all other users, this scan leaves only one false login behind. After some days, this may be repeated with a different password.
Keeping audit logs are vital to staying on top of any suspicious change to your website. An audit log is a document that records the events in a website so you can spot anomalies and confirm with the person in charge that the account hasn’t been compromised.
Last updated