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.
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.
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 four main criteria used to compile the OWASP top ten vulnerabilities are:
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:
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:
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.
The key OWASP best practice recommendations to mitigate broken authentication vulnerabilities are:
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).
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:
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.
OWASP recommends a number of best practices to prevent XXE attacks, including:
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 control vulnerability can be addressed in a number of ways:
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:
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:
Cross-site scripting is also a widespread vulnerability that affects 53% of all web applications. It occurs when malicious client-side JavaScript or HTML scripts are injected into a web page and then use the web application as an attack vector to hijack user sessions, deface websites, or redirect the victim to sites under the attacker’s control.
Methods to mitigate the XSS vulnerability include:
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.
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:
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:
Snyk open source vulnerability scanner can help you identify vulnerabilities and dependencies.
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.
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 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.
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.
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.
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.
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.