In this highly-competitive market where new releases take place daily, businesses are putting much of their focus on speed. Reports show that in 2019, 38% of developers indicated that they released monthly or even faster.
However, with speed getting the preferred treatment, security can be left behind. In the application release process, security often arrives as the last step. With security teams brought in this late to the process, they have limited time to evaluate the app and run security tests. If they do find issues, there is again limited time to remediate them without disrupting the strict deadlines for release.
Thankfully, while security was once an afterthought in software development, it’s now increasingly important as applications are becoming more accessible, and, in turn, more vulnerable to different types of network threats. Many organizations are recognizing the importance of and adopting application security programs, in the field known as AppSec.
However, AppSec is quite often misunderstood. Businesses either don’t know where to start or lack the proper technology needed to execute the program.
With many AppSec programs not at the desired maturity level to properly recognize and address security risks, having a source that can help with just that proves quite useful. Once such a source is OWASP.
What is OWASP?
The Open Web Application Security Project, OWASP for short, is an open and non-profit foundation and community dedicated to helping organizations, developers and just about anyone interested in AppSec improve the security of their software and build secure applications.
Launched in 2001, OWASP is a well-known entity in the AppSec and developer community. With a program that includes many local chapters throughout the world (275 to be exact) as well as numerous open source projects and educational and training conferences, everyone is encouraged to participate and join this foundation boasting more than ten thousand members.
What makes OWASP so respected and resourceful for both amateur and professional developers is that they hold true to their core values, which dictates that all of their projects, tools, documents and chapters are open and free for anyone interested in learning about application security.
Engaging with their projects and chapters is a great way to not only learn, but to also network and build your reputation in the community. We’ve actually talked to Tanya Janca, who led an OWASP chapter in Ottawa, so we highly recommend checking out that interview and hearing this first-hand account of her experience.
OWASP is mostly known for the OWASP Top 10 project, which provides developers with resources on the most common application vulnerabilities. That, however, doesn’t even begin to describe everything OWASP has to offer.
Let’s explore their different projects and examine their list of web application security risks.
Top 10 OWASP web application security risks
Starting with their most well-known project, the OWASP Top 10 of web application security risks is, fundamentally, just what the name implies—a resource that provides organizations, developers and consumers with an overview of the most critical vulnerabilities that plague applications and show their risk, impact and how to mitigate those risks.
It’s updated every three to four years, and is put together by a team of experts from all over the world. The OWASP Top 10 helps organizations understand cyber risks, minimize them and be better prepared to mitigate them. The newest update was released just a few months ago in 2021, and surprisingly or not, the list hasn’t changed all that much from the previous one in 2017. In the new release, there are three new categories, four categories with different names and scopes, and some consolidation of categories in the Top 10 for 2021.
And what are those 10 web application security risks? Let’s dive in.
Broken access control
Broken access control has climbed to the number one spot after holding fifth place in the previous version. This arrives as OWASP research showed that the 34 common weakness enumerations (CWEs) mapped to broken access control had more occurrences in apps than in any other category.
Access control is a system that dictates what tasks and activities users can perform and puts a limit on what users can view. When this is not properly enforced, and in the case of broken access control, attackers can bypass the authentication and perform tasks that are not permitted, or gain access to other users’ information.
Broken access control vulnerability is often caused by the lack of automated detection and mechanisms that ensure each user has specific and isolated privileges.
The prevention of broken access control is possible by implementing access control mechanisms throughout the application, disabling web server directory listing, logging access control failures, use of 2FA or MFA on all access points, discarding inactive accounts and removing unused services off your server.
Previously known as Sensitive Data Exposure, which is considered to be more of a symptom rather than a root cause, Cryptographic Failures addresses those failures related to cryptography, which often lead to sensitive data exposure and system compromise.
Sensitive data in applications (including user credentials, PII, financial information, healthcare records and more) needs to be protected and encrypted, but unfortunately, many web applications keep this data hidden in plain sight, or better said, in plaintext. When this data is not properly secured, attackers can gain access, modify, steal or sell it, often using a man-in-the-middle attack.
The most common cause of cryptographic failure is merely failing to secure and encrypt sensitive data. This security risk can at the very least be minimized by identifying which data is sensitive and classifying all data processed, stored and transported by the app; encrypting data that is in rest as well as that which is in transit; using proper key management; not storing sensitive data longer than needed and disabling the caching of any sensitive information.
Injection has fallen from the first spot to the third, and now, Cross-Site Scripting, once a separate category, is part of the Injection category.
Injection vulnerabilities refer to a scenario where an attacker provides untrusted data to a program, which is then sent to a code interpreter and processed as part of a command or a query. This leads to executing unintentional commands and changes the execution of that program. Injection occurs when the app takes the query and passes it to the database or a server without input validation checks, which then gets executed. A common form of injection vulnerability is an SQL injection, but there are also NoSQL, OS and LDAP injections.
Injection vulnerabilities are particularly dangerous as the attack surface is large and almost any data can be the vector. The consequences don’t make it any less scary: data loss, data theft, denial of service, loss of data integrity and even complete system compromise.
Injection vulnerabilities and attack can be prevented by doing input validation checks, rejecting suspicious data, keeping data separate from commands and queries, and controlling and limiting the permissions on the database login used by apps.
Insecure Design is a new category in the 2021 edition that focuses on risks related to design and architectural flaws. This development arises with the community’s call to move beyond “shift-left” in software development to activities that occur pre-code, to provide secure design.
Insecure Design is presented as a broad category, representing different weaknesses of missing or ineffective control design. Garnering some disagreement in the infosec community due to its very broad scope and debated as a cause for other Top 10 risks rather than warranting a category in itself, OWASP claims that insecure design is not the source of all other categories.
One of the core factors that contributes to insecure design is the lack of business risk profiling of software being developed. Secure software requires a secure development lifecycle and design pattern, as well as a secured component library, tools and threat modeling.
Prevention of this risk category can be achieved through the use of AppSec teams to evaluate and design security controls, along with the use of threat modeling, access control, business logic, limiting resource consumption by users or services, integration tests to validate all critical flows and determine how resistant they are to the threat model, and much more.
Security Misconfiguration keeps the same name but has moved up a spot. Additionally, a former separate category “XML External Entities” is now a part of security misconfiguration.
Security misconfiguration is one of, if not the most common vulnerability on the entire OWASP list. Applications can suffer from the security misconfiguration vulnerability when they have unpatched flaws, are missing proper security hardening on all levels of an application stack and configured permissions, have unnecessary features enabled (such as unnecessary ports), still have default accounts with default user credentials, or even show users error messages that are overly descriptive and reveal app vulnerabilities.
Misconfiguration can occur at any level of the application stack, including network services, platform, web server, application server, database, frameworks, custom code, pre-installed virtual machines, containers and storage.
Attackers will try to exploit unpatched flaws, attempt to access the default accounts, or gain knowledge through error messages in order to gain unauthorized access into the system, which can then result in system compromise.
To prevent security misconfigurations, start by removing any unused features and frameworks, update configurations, install patches as part of the patch management process, and have an automated process to verify their effectiveness and ensure that error messages show general content.
Vulnerable and outdated component
In the previous version, this risk category was known as “Using Components with Known Vulnerabilities” and it has climbed up significantly from its previous ninth spot.
This web application security risk refers to using components such as libraries, framework and other software modules that have the same privileges as the application. When those components have known vulnerabilities, attackers can exploit them in order to execute an attack. Components are used by many developers and while they often release security patches and updates, developers fail to apply them. Consequently, attackers can find a security flaw in a single component and are able to execute an attack on hundreds, if not thousands, of sites that use these components. This scenario is often seen with WordPress security. WordPress website hacks frequently occur, and the common denominator is that its components, the themes and plugins, were not updated once security patches were released, leaving the entire website vulnerable.
The prevention of this security risk is possible by having a patch management process in place, and removing unused features, components, files, documentation, and of course, unused components. It’s also essential to continuously monitor and review used components, apply appropriate and timely updates and patches, and use only components from trustworthy sources.
Identification and authentication failures
This risk category was previously named “Broken Authentication” and has fallen significantly in the list, all the way from the second position,due to the increased availability of standardized frameworks.
Vulnerabilities and misconfigurations in authentication systems can allow attackers to assume users’ identities by compromising passwords, keys or session tokens. Attackers would only need to gain access to a couple of accounts, or even just the one admin account in order to compromise the entire system.
Brute force attacks, credential stuffing, dictionary attack tools… session management attacks are widespread and pose a big threat to businesses with an outcome that includes data loss, social security fraud, identity theft, use of accounts for illicit activities, and more.
Prevention of this risk is possible by using 2FA or MFA, not using default credentials for admin accounts, employing a strong password policy (which dictates the complexity of users’ passwords, how often they need to be changed and limits failed login attempts among other restrictions) and using a server-side secure session manager that generates a new random session ID.
Software and data integrity failures
Software and Data Integrity Failures are a new category for the OWASP Top 10 in 2021. This web app risk category focuses on risks related to software updates, critical data and CI/CD pipelines without verifying integrity. This category has also absorbed a previously separate category called “Insecure Deserialization”.
An example of risks addressed in this category is an application that relies on plugins, libraries and modules from untrusted sources. Further, insecure CI/CD pipelines have the potential for unauthorized access and malicious code.
Some prevention methods for this web app risk category include the use of libraries and dependencies from trusted and secure sources; checking any components for known vulnerabilities; ensuring that the CI/CD pipeline has proper segregation, configuration and access control; as well as ensuring that unencrypted data is not sent to untrusted clients without a form of integrity check (such as a digital signature).
Security logging and monitoring failures
Security Logging and Monitoring Failures was previously named “Insufficient Logging & Monitoring” and has moved up from its previous 10th and last position on the list. This web app risk category now includes more types of failures that can impact visibility, incident reporting and digital forensics.
Did you know that the average time needed to detect a data breach is over 200 days? This means that an attacker can remain undetected in the system for a prolonged period and wreak havoc. This happens with insufficient logging and monitoring of security incidents; when there is no proper monitoring and reporting to the incident response team, no timely action and response to security alerts can take place. This allows attackers to modify, extract or even destroy data. Insufficient logging and monitoring also allows for data breaches and advanced persistent threat attacks, among the most devastating types of cybercrime.
Implementing proper logging, monitoring and incident response; ensuring all logs are noted with context in mind so malicious activity can be easily discovered and having a SOC team in place are all effective ways of preventing this web application security risk.
Server-side request forgery
Server-Side Request Forgery (SSRF) is a new addition to the list that was prompted by the Top 10 community survey, where the security community voted it #1. The SSRF web security vulnerability involves an attacker exacting a web server to send a request to an unexpected destination and bypassing firewalls, VPNs and similar access controls.
OWASP recommends several prevention practices against SSPF, such as disabling HTTP redirections, sanitizing all client-side input data, logging all accepted and blocked network traffic from firewalls, and segmenting remote resource access functionality in separate networks to ultimately reduce impact.
Top 5 OWASP projects
We’ve mentioned that, while the OWASP Top 10 list of web application security risks is their most well-known project, there are other worthwhile projects OWASP has to offer. It was difficult to choose a few from their numerous flagship, lab and incubator projects, but we have put together our top 5 favorite OWASP projects (aside from the Top 10, of course).
If you’ve read our blog, you’re familiar with our love for OWASP Amass. We like to describe it as ‘a swiss army knife for your command line tool box’.
Amass is an open source DNS enumeration, external asset discovery and attack surface discovery tool that helps infosec professionals perform network mapping and external asset discovery by using information gathering and other techniques, such as active reconnaissance.
We’ve recently published a blog post in which we go in depth (really in depth) about Amass and all of its nitty-gritty details. We encourage you to check it out and learn more about this must-have for your security toolbox.
OWASP Cheat Sheet Series
The OWASP Cheat Sheet Series is a really handy security resource for developers and security teams. It provides a brief overview of best security practices on different application security topics. Because it’s in such a short form, it doesn’t go into too much detail yet suggests to developers valuable practices they can quickly implement.
Some of the security topics noted in the Cheat Sheet Series include:
- Attack surface analysis
- Content security policy
- Cross-site request forgery prevention
- Database security
- Denial of service
- Session management
- Virtual patching
- XML security
OWASP Top 10 Privacy Risks
Another top 10 list, the OWASP Top 10 Privacy Risks Project is a list of privacy risks in web applications that also provides details on countermeasures. This project aims to offer tangible tips on how to embed privacy in the design of web applications and helps developers better understand the consequences of these privacy risks.
The top 10 privacy risks for web applications provided by OWASP are as follows:
- Web application vulnerabilities
- Operator-sided data leakage
- Insufficient data breach response
- Insufficient deletion of personal data
- Non-transparent policies, terms and conditions
- Collection of data not required for the primary purpose
- Sharing of data with a third party
- Outdated personal data
- Missing or insufficient session expiration
- Insecure data transfer
OWASP Top 10 Internet of Things Project
And here’s yet another Top 10 list (a pattern, one might say!), the OWASP Internet of Things Project.
Created in the wake of the lightning speed expansion of IoT, this resource helps manufacturers, developers, and consumers learn about the security risks associated with this vast addition to the attack surface, and guides them when building secure IoT technologies.
The project has resulted in several sub-projects, but the most interesting to us is the OWASP Top 10 IoT project.
The 10 IoT vulnerabilities are:
- Weak, guessable or hardcoded passwords
- Insecure network services
- Insecure ecosystem interfaces
- Lack of secure update mechanism
- Use of insecure or outdated components
- Insufficient privacy protection
- Insecure data transfer and storage
- Lack of device management
- Insecure default settings
- Lack of physical hardening
The next update to the OWASP IoT project and its list of vulnerabilities should take place in 2020. We’re very interested to see what, if anything, will change.
OWASP Zed Attack Proxy, OWASP ZAP for short, is a free open-source web application security scanner. It’s one of the most popular OWASP Projects, and it boasts the title of “the world’s most popular free web security tool”, so we couldn’t make this list without mentioning it.
ZAP is created to help individuals from all skill levels, whether they are new to pen testing, or are senior developers and security professionals. Basically, ZAP is a “man-in-the-middle proxy” and it allows you to manipulate all of the traffic between browser and application, modify the contents, and forward those packets to the destination.
It can help in finding vulnerabilities in web applications during development and testing and can also be used for manual security testing. Main features of ZAP include intercepting proxy server, automated scanner, passive scanner, brute force scanner, fuzzer, port scanner, web sockets and a REST API. All in all, the OWASP ZAP is a great addition to your security toolbox and can help you discover critical vulnerabilities in your web application and help you build better, more secure apps.
Honorable mention - OWASP WebGoat
We’ve talked about OWASP WebGoat in our post about the top 10 vulnerable websites for penetration testing and ethical hacking training, but it’s such an interesting project that it made its way to our list as an honorable mention.
OWASP WebGoat is a deliberately insecure application that provides a “safe” learning space for developers to test common server-side application flaws found in Java-based applications. It’s been created to help people legally practise their pen testing skills and educate themselves about application security.
The application offers different lessons that teach you about a specific security issue and then provides you with knowledge on how to exploit it.
Some of the vulnerabilities you can in the OWASP WebGoat are:
- Cache poisoning
- SQL injection
- Trojan horse attacks
- Unicode encoding
If you’re interested in finding out about more similar deliberately insecure websites, check out our post about top ethical hacking training websites for more details.
OWASP is an incredibly respected foundation, not only in the AppSec community, but throughout the entire security community as well. And with good reason—their values create an open environment for knowledge sharing and keep it all free and accessible to anyone interested in creating and deploying secure software.
Their Top 10 list of web application security risks is something every developer and AppSec team should always keep nearby, but be sure not to miss their other projects. There are even more we didn’t have the opportunity to mention, which we hope to cover in a later post.
One thing is certain, OWASP makes the Internet safer for everyone, every day!
As we’ve seen, OWASP offers quite a bit of resources and tools to include in your security toolkit. And so does SecurityTrails! Based on the IT role you are playing and your needs, we offer several different intel-reconnaissance, threat intelligence and attack surface reduction tools. You can learn more about them here and discover which one is perfect for your security needs.