Introduction
OWASP stands for the open web application security project and it’s an online community that creates free content on securing web applications. One of their most famous projects is the OWASP top 10, which is a list of the top 10 web applications vulnerabilities that they have found through their research. Recently OWASP has done a revamp of their website as well as the OWASP top 10. They have found that the vulnerabilities that we’re most prevalent 3-5 years from now are no longer the biggest security concerns for developers. In this article we will do a review of what has changed in the OWASP Top 10 and what the biggest security vulnerabilities are to date:
1. Broken Access Control
Previously in the number 5 spot, broken access control is now the most serious security risk according to the OWASP top 10. Access control is the mechanism that enforces policies such that users cannot perform actions outside of their intended permissions. In their testing, OWASP tested applications in their dataset for some form of broken access control among other security vulnerabilities. In their results, they found that broken access control was the most commonly found vulnerability with over 318,000 occurrences in the applications that were tested. This indicates that many applications had some form of broken access control that would allow users to perform actions that they are not intended to perform.
2. Cryptographic Failures
Moving up from the number 3 spot is cryptographic failures. Previously known as Sensitive Data Exposure, the authors considered this denomination was a “broad symptom rather than a root cause”. It alludes to situations where sensitive information like credit card numbers, passwords, health records, or personal information isn’t properly protected by encryption and ends up exposed.
We find the notion of sensitive information restrictive as it does not take into consideration the programmatic type of sensitive data that are secrets. Secrets (API keys, credentials) when they are hardcoded are in fact exposed. We agree that this is the symptom of a root cause which is in fact not a cryptographic failure as such but a proper secret management failure.
GitGuardian’s research finds that many company secrets are exposed and consequently allow access to sensitive data as defined by OWASP. We feel that a broader category including both root causes of exposure should be proposed. Maybe in the next version of the OWASP Top 10!
3. Injection
This was originally number 1 on the list but has been moved down to the third spot. This refers to injection-based attacks such as cross-site scripting, SQL injections, and NoSQL Injections. This is the direct result of applications accepting unfiltered or improperly filtered user inputs. It had the second most occurrences in the OWASP application tests with 274,000 occurrences.
4. Insecure Design
This refers to flaws in the application design that leads to different types of security vulnerabilities. This is the exact opposite of the principle of “secure by design”. There is a clarification important here to understand that this is not the source of all of the other weaknesses in the OWASP top 10. The other 9 vulnerabilities on this list are results of improper implementation, which means you tried to implement a security control but it was done ineffectively. In contrast, insecure design means that there were no security controls put in place during the design of the application, there is a “missing or ineffective security control design”.
5. Security Misconfiguration
This moves up from number 6 in the last iteration to number 5 on this list. This is attributed to the fact that more software has become highly configurable, which means there is more opportunity for misconfiguration to occur in applications, solutions, or services. Some examples of misconfiguration would be unnecessary features being enabled or installed, default accounts and passwords being used, or improper permissions being enabled on accounts.
6. Vulnerable and Outdated Components
Previously named using components with known vulnerabilities this refers to using things with known vulnerabilities. This can be from using old versions of software that need to be patched, using third-party code libraries that have security vulnerabilities or it can be the supporting devices such as the web servers operating system, database management system, or runtime environments that have the vulnerabilities.
7. Identification and Authentication Failures
This was previously known as broken authentication and comes all the way down from number 2 on the last iteration of this list. This simply means any occurrence where attackers can bypass authentication checks and balances to compromise user accounts or user sessions. Some common examples include weak passwords, permitting brute force attacks, and missing or ineffective multi-factor authentication. We can suppose that the generalization of the use of open-source libraries or frameworks to handle such sensitive operations over the last 5 years can explain this big step back.
8. Software and Data Integrity Failures
To understand this you first need to understand data integrity, which is your ability to verify that an item hasn’t been changed from its secure state. For example, consider a computer file that was sent over email. How can you know if that file has been changed or altered in transit? The way this is done is through using a file hash, which allows you to compare if an item has been altered or changed from its original state.
Software and Data Integrity failure means that you fail to confirm if the software or data dependency you are using has not been altered maliciously. For example, some applications have auto-update functionality, if your software program is downloading updates from a source without verifying that the software has not been altered, you run the risk of downloading malware.
9. Security Logging and Monitoring Failures
Moving one spot up is improper logging and monitoring features. Proper logging and monitoring are important for detecting, escalating and responding to active breaches. Failure to properly record events or generate alerts is a sign of security logging and monitoring failures.
10. Server-Side Request Forgery
This comes in at number 10 and according to OWASP this being on the list is not supported by the data, it’s simply something that was voted in by the community even though it’s not supported by the data at this time. This flaw occurs when a web application is getting a resource without validating the user-supplied URL. It allows the attacker to get the application to send a crafted request to an unexpected destination, regardless of firewalls, VPNs, or a network access control list.
Final Thoughts
The OWASP top 10 is a great way to identify potential security weaknesses in your application. The OWASP project overall has a great reputation for its work and should be one of your main resources when it comes to web application security. However, one thing that OWASP has not identified in its 2021 iteration of the Top 10 list is secret exposure. Considering that it was not a root cause of vulnerabilities, they replaced it with cryptographic failure. This is where we have a bit of a different point of view as GitGuardian has found over 2 million company secrets in 2020 and continue to find over 5,000 company secrets every day, which shows that this is definitely a problem in itself. Attackers will always take the path of least resistance, preferring publicly exposed secrets over encrypted ones, even when poorly done. That’s why we think merging the two concepts does not accurately reflect the scope of the problem.
If you are interested in secret detection and monitoring for your repositories, you can test GitGuardian product here: https://dashboard.gitguardian.com/
Top comments (0)