Serverless Security
Overview: OWASP Top 10 2021
The long-awaited OWASP Top 10 2021 draft edition is here. We take you through the changes, new vulnerabilities, and the triggers, enabling you to secure your apps against the latest threats.
Save to Folio
If you work in application security, you’ve probably already heard about OWASP and the OWASP Top 10. If not, here’s a quick rundown: the OWASP Top 10, launched in 2003, lists the most critical risks in web applications. After four years since the last version, a new version was released in September. In this article, we’ll go over the changes and updates of the new OWASP Top 10 and talk about the added categories of risks. We’ll also cover how the most exploited web application vulnerabilities relate to this new list and what kind of protections are available for you to implement on your web applications.
Mapping the changes
Figure 1 - Changes between the OWASP Top 10 2017 and 2021
As we can see from the figure above, there were some significant changes in the new Top 10, some risks went up, others went down, some were bundled into other categories, and three new items were added. So, let’s break it down each one of these changes:
- Broken Access Control
Broken Access Control jumped from fifth to first place in the list since 94% of the applications tested for this issue increased in incidence over time. This is not only because of the increase of cloud computing and API usage but also because the issue is hard to detect with automated scanners, making it primarily the responsibility of penetration testers (pentesters) and bug bounty hunters to discover, and developers to avoid it by implementing secure access controls.
- RENAMED: Cryptographic Failure
Previously called Sensitive Data Exposure, Cryptographic Failures climbed one position from the 2017 edition. The name was changed to highlight the focus on cryptography failures either in transit or at rest, which in turn may lead to sensitive data exposure. It affects anything from hard-coded credentials to using weak crypto algorithms and not having proper entropy on your sensitive data.
- Injection Flaws
This risk category dropped from first place to third due to the native and transparent implementation of protections in the frameworks or new languages being used by developers. With one of the main issues being SQL Injection, a vulnerability more than 23 years old, it’s rewarding to see the InfoSec community are on the right track here. Even though it was added to this category as an injection form, which I believe it makes sense, many native protections such as browsers default settings and framework implementations have been put in place to reduce its impact.
- NEW: Insecure Design
Insecure design, a new risk category focusing on risks related to design flaws, is ranked fourth. Although there’s been plenty of discussion about DevOps, DevSecOps, and shifting security left in the community, it is essential to highlight that secure design patterns are vital to taking this approach to the next level. However, much more than shifting left, we need to start left, which means making sure that we design our applications securely from the start. As the new Top 10 demonstrates, an insecure design cannot be fixed just by the correct implementation as, by definition, the security controls and requirements needed were never created put in place to defend against specific attacks. For that reason, inherent and embedded security practices usually referred to as security by design, is a great approach to mitigate these design risks.
- Security Misconfiguration
Security Misconfiguration (bundled with XML External Entities) remains on the Top 10, jumping up one position to fifth, as the number of incidents increases due to the cloud computing shift over the past 15 years. According to a report by Snyk, misconfiguration is the second most common incident type in cloud native environments, with more than 56% of survey respondents experiencing a misconfiguration or known unpatched vulnerability incident involving their cloud-native applications. Also, according to the IBM’s X-Force Cloud Security Threat Landscape Report, two-thirds of cloud attacks could be stopped by checking the proper security configurations.
- RENAMED: Vulnerable and Outdated Components
Previously known as Using Components with Known Vulnerabilities, this category jumped three spots to sixth. Most applications rely on libraries and dependencies that are, for the most part, open-source software. These libraries are usually incorporated during the development lifecycle and rarely get updated or checked against known vulnerabilities.
An evolution of early verification systems, software composition analysis (SCA) identifies and lists all the parts and versions present in the code. It also checks each specific service and looks for outdated or vulnerable libraries that may impose security risks to the application. These tools can also check for legal issues regarding the use of open-source software with different licensing terms and conditions.
Another pertinent aspect that must be secured is software supply chains. Attackers can compromise software components of third-party suppliers by inserting malicious code inconspicuously. This code could then connect to a command and control (C&C) server to download and deploy backdoors and other malicious payloads within the system. This can lead to remote code execution (RCE) and unhampered access to an enterprise's system and computing resources.
- RENAMED: Identification and Authentication Failures
This category renamed from Broken Authentication, dropped from second to seventh place. According to OWASP, it is still a fundamental part of the Top 10, but the number of frameworks available today to deal with these issues is driving the problems down.
- NEW: Software and Data Integrity Failures
Another new category, Software and Data Integrity Failures, which, together with Insecure Deserialization, focuses on the lack of proper integrity verification, either on software updates, critical data, or the CI/CD pipeline. According to OWASP, “this category contains one of the highest weighted impacts from CVSS according to the data analysed.”
- RENAMED: Security Logging and Monitoring Failures
Interestingly enough, according to OWASP's Executive Director and OWASP Top 10 Project Leader Andrew van der Stock, this category received a lot of criticism in the 2017 edition, but moved up one spot to ninth place. Previously known as Insufficient Logging and Monitoring, it was expanded to include more types of failure. Although it is challenging to test for and isn't well represented in the CVE/CVSS data, failures can directly impact visibility, incident alerting, and forensics.
- NEW: Server-Side Request Forgery (SSRF)
The last risk added from the community survey is Server-Side Request Forgery. According to the OWASP survey data, this risk had relatively low incidence rate but had an above-average ratings for Exploit and Impact potential. This new risk category was written by Orange Tsai, a famous security researcher with great experience finding and exploiting SSRF vulnerabilities in many large organisations.
Top vulnerabilities x OWASP Top 10
We recently published Linux Threat Report 2021 1H, which looks at the top Linux threats for the first half of 2021 based on data from Trend Micro Cloud One™ – Workload Security and Trend Micro™ Deep Security™ Software. We also looked at the triggers for CVEs known to be actively exploited or have a known proof of concept (POC). Based on Trend Micro Cloud One™ data, the following list features the top 15 CVEs. We’ve also correlated each vulnerability with its own OWASP Top 10 categories. And yes, Trend Micro Cloud One, a platform composed of seven security services, provides protection against all 15 vulnerabilities listed below via virtual patching, vulnerability shielding, and exploit blocking features.
Table 1 - The top 15 vulnerabilities with known exploits or proofs of concept and related Top 10 risks
How to secure code via application security and testing
Now, let’s focus on how to secure your apps from these vulnerabilities. This can be tricky given you can have tens, hundreds, or maybe thousands of developers writing and deploying code every day in your production environment.
First, organisations must ensure that all communications are being made using TLS encryption. This should be applied even amongst internal services like load balancers, application servers, and databases.
Organizations can significantly reduce the attack surface of their systems just by limiting and monitoring exposed services, ports, and API endpoints. Here, it is essential to think about container base images and the systems on which its clusters are running.
There are various code security verifications to add to your pipeline to ensure that one's code is secured:
Static application security analysis (SAST) - This is also called “security code review” or “code auditing” and is still one of the best and quickest ways to detect security issues in one's code. Enterprises should have at least one static analysis tool embedded into the pipeline regardless of the language being used. This tool will check for unsafe coding practices every time developers commit new code into the application. In addition, the OWASP Foundation has a list of open-source and commercial tools designed to analyse source code or compiled code to detect security flaws.
Dynamic application security analysis (DAST) - Although dynamic analysis can only be done when there is a running application to test against, it is also a good idea to perform automated scans and checks to test for common application attacks such as SQL injection, XSS attacks, and cross-site request forgery (CSRF) attacks. These tools will also test your application, container, and cluster resilience when faced with a series of unexpected load and malformed requests. In addition, OWASP has a dynamic analysis tool that can also be automated and embedded into the pipeline called OWASP Zed Attack Proxy (ZAP).
Software composition analysis (SCA) - Between 70% and 90% of all cloud-native applications are made of libraries or third-party dependencies. These codes are generally not checked during the static analysis phase. However, tools like the OWASP Dependency-Check can be used to check for outdated or vulnerable libraries in one's code. Trend Micro Cloud One™ – Open Source Security by Snyk provides cloud-native application security via continuous monitoring and identifying open-source code vulnerabilities and license risks in application components.
Runtime Application Self-Protection (RASP) - RASP is a robust application security tool that kicks in when an application starts, providing real-time or immediate protection against threats and attacks, such as zero-day exploits, XSS attacks, and email and messaging app attacks. RASP not only detects attacks but also analyses the attacks’ behaviour and the context of the behaviour. This means that it can correctly pinpoint legitimate requests from attacks, minimising false positives and gray alerts. Trend Micro Cloud OneTM – Application Security offers RASP, allowing developers to design and deploy secure applications and protect against sophisticated attacks quickly and efficiently.
Patching and ensuring that proper configurations are set are separate tracking items. The responsibility for these rests with the application owners and their application security teams. DAST and penetration testing are usually helpful in identifying vulnerabilities and configuration issues. In addition, enterprises can deploy systems that can prevent such from happening or perform virtual patching, such as a web application firewall (WAF) or an IPS.
Conclusion
Securing your modern apps against today’s most dangerous vulnerabilities doesn’t have to be complicated, but it does require some care. Learn more about how a platform approach can automate and streamline security from build time to runtime by checking out the robust Trend Micro Cloud One documentation site. If you’re ready to try it for yourself, get started with a free, 30-day trial.
