OWASP Top 10 Vulnerabilities
Cloud-native applications, with their distributed architectures that comprise many third-party libraries and services, are an attractive target for hackers. The fact that 82% of all vulnerabilities are found in application code is not lost on attackers, who seek to use this vector to compromise the networks on which the application is deployed. Securing web applications, therefore, has become a business-critical requirement.
What Is OWASP?
The Open Web Application Security Project is a non-profit global community that strives to promote application security across the web. A core OWASP principle is that their knowledge base be freely and easily accessible on their website. With its tens of thousands of members and hundreds of chapters, OWASP is considered highly credible, and developers have come to count on it for essential web application security guidance.
Every application developer, regardless of experience level, must make the effort to understand code security vulnerabilities in order to avoid frustrating and often costly application security failures.
What Is the OWASP Top 10?
Every three to four years, OWASP revises and publishes its list of the top 10 web application vulnerabilities. The list includes not only the OWASP top ten threats but also the potential impact of each vulnerability and how to avoid them. The comprehensive list is compiled from a variety of expert sources such as security consultants, security vendors, and security teams from companies and organizations of all sizes. It is recognized as an essential guide to web application security best practices.
The Latest List of OWASP Top 10 Vulnerabilities
The four main criteria used to compile the OWASP top ten vulnerabilities are:
- Business impact.
The last full revision of the OWASP Top 10 list was published in November 2017. A new OWASP Top Ten list is scheduled for 2020. As of October 2020, however, it has not yet been released.
The current list of OWASP TOP 10 web vulnerabilities being used by application developers and security teams is:
- 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
In this section, we explore each of these OWASP Top 10 vulnerabilities to better understand their impact and how they can be avoided.
Injection vulnerabilities can occur when a query or command is used to insert untrusted data into the interpreter via SQL, OS, NoSQL, or LDAP injection. The hostile data injected through this attack vector tricks the interpreter to make the application do something it was not designed for, such as generating unintended commands or accessing data without proper authentication.
Any application that accepts parameters as input can be susceptible to injection attacks. The level of the threat is highly correlated with the thoroughness of the application’s input validation measures.
Injection attacks can be prevented by any combination of the following approaches:
- Segregate commands from data to avoid exposure to attacks that replace data with unintended command execution.
- Code SQL queries with parameters rather than structuring the command from user input content only. These are called parameterized queries or prepared statements.
- Eliminate the interpreter altogether through the use of a safe API.
- Implement positive server-side validation as well as an intrusion detection system that spots suspicious client-side behaviors.
2. Broken Authentication
When applications incorrectly execute functions related to session management or user authentication, intruders may be able to compromise passwords, security keys, or session tokens and permanently or temporarily assume the identities and permissions of other users. This vulnerability poses a grave threat to the security of the application and the resources it accesses and can also severely compromise other assets connected to the same network.
Broken Authentication Remediation
The key OWASP best practice recommendations to mitigate broken authentication vulnerabilities are:
- Implement multi-factor authentication.
- Do not deploy with default credentials, especially for users with admin privileges.
- Enforce strong passwords.
- Carefully monitor failed login attempts.
- Use a secure session manager that generates random, time-limited session IDs. Never include session IDs in URLs.
3. Sensitive Data Exposure
Without essential data protection measures such as encryption of data in transit or at rest, attackers can view, steal, or modify sensitive data such as credentials, credit card or social security numbers, and medical information. Unencrypted data is a prime target for damaging exploits related to identity theft, fraud, and industrial espionage, to name just a few security vulnerability examples. Data protection is especially critical for web applications that involve financial transactions, healthcare records, and personally identifiable information (PII).
Sensitive Data Exposure Remediation
Take a risk-based approach that applies strict controls to data assets that are subject to external or internal compliance requirements.
For data in transit, implement Secure Sockets Layer (SSL) certificates to deploy secure encrypted links between the host server or firewall and the web browser.
For data at rest:
- Disable caching for user responses that contain sensitive data
- Never store sensitive data that is no longer needed.
- Encrypt all sensitive information that does need to be stored.
4. XML External Entities (XXE)
For web applications that parse XML input, a poorly configured XML parser can be tricked to send sensitive data to an unauthorized external entity, i.e., a storage unit such as a hard drive. XXE attacks are used by hackers to observe critical information, disclose internal files and file shares, scan internal ports, execute code remotely, and mount denial of service (DoS) attacks.
XML External Entities (XXE) Remediation
OWASP recommends a number of best practices to prevent XXE attacks, including:
- Avoid the serialization of potentially sensitive data.
- Use less complex data formats such as JSON.
- Keep XML processors and libraries patched or upgraded.
- Ensure that XML or XSL file upload functionality validates incoming XML with, for example, XSD validation.
5. Broken Access Controls
Website security access controls should limit visitor access to only those pages or sections needed by that type of user. For example, administrators of an ecommerce site need to be able to add new links or add promotions. These functions should not be accessible to other types of visitors.
Developers must be encouraged to internalize “security first” discipline to avoid pitfalls such as content management systems (CMS) that generate all-access permission by default—up to and including admin-level access. Broken access control can give website visitors access to admin panels, servers, databases, and other business-critical applications. In fact, this OWASP Top Ten threat could even be used to redirect browsers to other targeted URLs.
Broken Access Controls Remediation
Broken access control vulnerability can be addressed in a number of ways:
- Adopt a least privileged approach so that each role is granted the lowest level of access required to perform its tasks.
- Delete accounts that are no longer needed or active.
- Audit activity on servers and websites so that you are aware of who is doing what (and when).
- If there are multiple access points, disable the ones that are not required at that moment.
- Keep servers lean; shut down unnecessary services.
6. Security Misconfiguration
Gartner estimates that up to 95% of cloud breaches are the result of human errors. Security setting misconfigurations are one of the prime drivers of that statistic, with OWASP noting that, of the top ten, this vulnerability is the most common. There are many types of misconfiguration that expose the company to cybersecurity risk, including:
- Accepting default settings that are insecure
- Overly accessible cloud storage resources
- Incomplete configurations
- Misconfigured HTTP headers
- Verbose error messages that contain sensitive information
Security Misconfiguration Remediation
Security misconfigurations can strike almost anywhere in the environment, including network-attached devices, databases, web and application servers, and containers. The following practices can help maintain a well-configured environment:
- Use templates to deploy development, test, and production environments that are preconfigured to meet the organization’s security policies.
- Leverage segmented application architectures that minimize the risk from an insecurely configured element; maintain a library of properly configured container images.
- Deploy minimal platforms and remove unused features and services.
- Continuously monitor cloud resources, applications, and servers for security misconfigurations and remediate detected issues in real time, using automated workflows wherever possible.
7. Cross Site Scripting (XSS)
Cross Site Scripting (XSS) Remediation
- Implement code vulnerability testing at the design and development phases, and scan code in production environments as well.
- Take a zero-trust approach to user input data. Separate active browser content from unvalidated data.
- Implement a Content Security Policy that provides for appropriate website defenses against XSS.
8. Insecure Deserialization
Insecure deserialization offers hackers an attack vector that is most typically used for remote code execution but can also be used to conduct injection attacks, replay attacks, and attacks utilizing privilege escalation. An example of an insecure deserialization scenario is a super cookie containing serialized information about the logged-in user. An attacker could deserialize the object, modify it to give himself/herself an admin role and then serialize it again.
Insecure Deserialization Remediation
The most effective defense against insecure deserialization is to not accept serialized objects from unknown or untrusted sources. Barring that option, developers can take several precautions to avoid the security flaw:
- Implement digital signatures to ensure the integrity of serialized objects.
- Initiate type constraints during deserialization so that application code detects unexpected classes.
- Run deserialization code in low privilege environments to prevent unauthorized actions.
9. Using Components with Known Vulnerabilities
Modern distributed web applications often incorporate open-source components such as libraries and frameworks. Any component with a known vulnerability becomes a weak link that can impact the security of the entire application.
Although the use of open-source components with known vulnerabilities is ranked low in terms of security problem severity, it is #1 when ranking the OWASP Top 10 by how often a vulnerability was the root cause of an actual data breach.
The most effective defense is continuous scanning of all code components for known vulnerabilities and deploying a patch or other remedy as quickly as possible when a vulnerability is detected. There are a number of best practices that enhance the effectiveness of this line of defense:
- All components integrated into the company’s frameworks should be under configuration management.
- The scanner must be able to automatically discover all the components to be monitored.
- Scanning should be conducted against a comprehensive vulnerability database that is enriched with threat intelligence data.
- The patch management workflows for identifying, testing, and deploying the right patch should be as automated as possible in order to reduce to a minimum the operational risk associated with patching.
Snyk open source vulnerability scanner can help you identify vulnerabilities and dependencies.
10. Insufficient Logging and Monitoring
Studies indicate that the time from attack to detection can take up to 200 days, and often longer. This window gives cyber thieves plenty of time to tamper with servers, corrupt databases, steal confidential information, and plant malicious code.
Implement readily available logging and audit software to quickly detect suspicious activities and unauthorized access attempts. Even if a detected attack has failed, logging and monitoring provide invaluable tools for analyzing the source and vector of the attack and learning how security policies and controls can be hardened to prevent intrusions.
What are the other Non-OWASP vulnerabilities?
OWASP state very clearly in their methodology that the Top 10 list is, by definition, only a subset of important security issues and organizations should be aware of additional security risks.
OWASP Vulnerabilities: FAQs
What Is an OWASP Vulnerability?
OWASP vulnerabilities are security weaknesses or problems published by the Open Web Application Security Project. Issues contributed by businesses, organizations, and security professionals are ranked by the severity of the security risk they pose to web applications.
What Are the Top 10 OWASP Vulnerabilities?
OWASP’s top ten list is compiled and published every three to four years, highlighting the most critical security vulnerabilities. Additionally, the list includes examples of the weaknesses, how they can be exploited by attackers, and suggested methods that reduce or eliminate application exposure.
What Is the number 1 Application Security Risk Reported by OWASP?
Injection is the number 1 flaw reported by OWASP. Injection can send untrusted data through SQL or other paths such as LDAP, allowing the interpreter to access unauthorized data or execute commands not intended by the application.
How Can OWASP Top 10 Vulnerabilities Be Tested?
OWASP provides an in-depth testing guide that offers test cases for a multitude of test scenarios. Many development teams have adopted a more automated solution by utilizing software to scan code for vulnerabilities with automated warnings and consistent application of best practices.
How Should the OWASP Top 10 Be Used?
OWASP’s top 10 list offers a tool for developers and security teams to evaluate development practices and provide thought related to website application security. While it is by no means all-inclusive of web application vulnerabilities, it provides a benchmark that promotes visibility of security considerations.
Check for vulnerabilities in public GitHub repositories