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 is from 2017, and surprisingly or not, the list hasn’t changed all that much since the one released in 2004. That means we still have a long road ahead when it comes to producing apps with improved security.
And what are those 10 web application security risks? Let’s dive in.
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.
Formerly entered as “Broken authentication and session management”, broken authentication still holds the number two spot on the OWASP Top 10 list. 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, 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 broken authentication vulnerability 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.
Sensitive data exposure
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 sensitive data exposure 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.
XML external entities
XML processors are often poorly configured to load external entity references specified in XML documents and many older XML processors allow specification of an external entity by default.
As per OWASP, attackers can exploit vulnerable XML processors if they upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations. XML external entities (XEE) vulnerability can lead to scanning of internet systems, open port scanning and data loss, as well as a denial-of-service (DoS) attack.
The prevention of XXE requires upgrading all XML processors, disabling XEE processing in XML parsers and the implementation of whitelisting of server-side input validation to prevent hostile data in XML files, among other tactics.
Broken access control
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.
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.
In cross-site scripting, or XSS, attackers can include malicious code in a legitimate web application, and when a victim visits the app, it will execute the injected code and deliver the malicious script to the user’s browser and hijack user sessions, redirect users to malicious sites and damage the targeted website.
As OWASP claims, XSS is the second most prevalent security risk in their top 10 and can be found in almost two-thirds of all web applications. A web application is vulnerable to it if it allows user input without validating it and allows users to add custom code to an existing web page which can be seen by other users.
XSS can be prevented by using frameworks such as the latest Ruby on Rails or React JS, which automatically escape XSS, reject untrusted HTTP request data, enable a content security policy (CSP) and apply context-sensitive encoding.
To better understand insecure deserialization, we must first touch on serialization. Serialization refers to taking objects from the application code and converting them into a different format that serves a different purpose.
Deserialization is, logically, the opposite of serialization. It refers to taking those serialized objects and converting them to formats that can be used by the application.
In insecure deserialization, those serialized objects can be tampered with, and deserializing objects from untrusted sources, once converted to be used by the application, can lead to remote code execution attacks, among the most dangerous types of cybercrime.
The first steps toward preventing insecure deserialization is to forbid the deserialization of objects from untrusted sources, implement integrity checks on any serialized objects, isolate and run code that deserializes in low privilege environments and monitor deserialization.
Using components with known vulnerabilities
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.
Insufficient logging and monitoring
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.
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.