Estimated difficulty: 💜💜🤍🤍🤍
We are back! And what better way to kick things off than a joint blog post from both Sarah & Sophia?
Despite our now varying areas of specialty, we’ve gone back to our penetration testing routes and will be covering the current OWASP Top 10 for web application security.
What is OWASP Top 10?
As many of you may (or may not) know, OWASP is an open-source community driven project dedicated to web application security. As a not-for-profit, all of OWASP’s materials are available from their website and includes things like documentation, tools and forums. One of their most well-known publications is the “OWASP Top 10” which is a regularly-updated framework that outlines the ten most critical risks to web applications. The list is collaboratively updated and put together by security professionals and experts around the globe. Categories for the “Top 10” list are also data-driven by CVEs and found vulnerabilities in the wild.
OWASP’s most recently published “Top 10” is from 2021, and has some updated naming conventions and categories from the previous 2017 version.
Source: OWASP
It has been so long since I have done penetration testing that I didn’t realise OWASP was updated in 2021 – so this blog will be a learning experience for us both!
Author’s Note (Sophia)
And with that, let’s move on to the categories! Cue my best RuPaul voice, the category is…
A01:2021-Broken Access Control
To understand what broken access controls are, we first need to define what access control actually is. Let’s say we have three users. An administrator, a standard user, and a guest user. The administrator may be allowed to create, delete and update standard and guest accounts. However, an access control should be in place to disallow a standard user and guest user from creating, deleting and updating accounts other than their own account.
A broken access control can be summarised in terms of: An account being able to escalate privileges to perform actions outside of their intended role or permissions.
Privilege escalation can be split into two categories: horizontal and vertical privilege escalation. If the guest user was able to modify or delete a standard or admin user, then this would be considered vertical privilege escalation. This is assuming the guest user has less permission to carry out task than the other two user types. An example of horizontal privilege escalation would be when a standard user is able to delete a different standard users account, provided this was not the intended functionality of that user.
Broken access can also be found through many other methods. These can include: brute forcing a URL to reach a page that should not be available to your user, viewing an account by modifying your unique identifier, unauthorised access of website functionality when not authenticated to the site, and the list could go on.
In order to prevent broken access from occurring, OWASP have made some recommendations.
- Implement a deny by default rule.
- Re-use access control mechanisms.
- Provide record ownership.
- Deny web server directory listings
- Setup incident alerts for admins to identify when a resource is accessed by an unauthorised user.
- Rate limiting to prevent brute force attacks on URLs
- Stateful session identifiers that invalidate after a period of time.
For more information you can check out the link to their website.
A02:2021-Cryptographic Failures
Previously known as “Sensitive Data Exposure”, this category focuses on failures related to cryptography that could lead to the exposure of sensitive data. There a few things that need to be determined to fulfil this category, but first we’ll talk about the difference between data in transit and data at rest.
When we talk about data in transit we mean data that is being transferred between two locations, it can also be known as data in motion. We worry about data in transit as that is when data is vulnerable. It can often be susceptible to interception or compromise, as it is out of the user’s control.
When we talk about data at rest we mean data that is not actively being moved, and is usually stored in some way (think about hard drives, cloud storage etc.). Although we tend to worry more about data in transit, data at rest is usually a more attractive target for threat actors – however the risk profile may differ depending on the type of data at rest (would a picture of last night’s dinner saved to the cloud be as valuable as hundreds of gigabytes of financial information for a bank customer base?)
Both types of data would need to protection to prevent sensitive data exposure, more so data that may be relevant to regulations such as General Data Protection Regulation (GDPR) and the PCI Data Security Standard (PCI DSS). Recommendations for cryptographic failures include encrypting all data at rest, and ensuring all data in transit is be secured with the relevant algorithms, protocols and keys to preserve confidentiality.
A03:2021-Injection
Oh injection, our reigning champ for so many years, now slipping into third! The Injection category covers a multitude of sins, and is most likely the reason as to why it was in the top sport for so many years. An Injection vulnerability occurs when data input by a user is not properly sanitised. This just means that special characters for specific languages can be used to break out of the original query or command and an additional or different query or command can be run to perform unauthorised or malicious activity.
Typical languages used in websites, and are often vulnerable to injection vulnerabilities when not implemented correctly are: SQL, NoSQL, OS commands such as Bash, LDAP, Expression Language, and more. To identify vulnerabilities in code, it is good to get someone to review the code before releasing it into production. To automate some of the testing, parameters can be fuzzed through the use of tools such as Burpsuite.
Common ways of preventing this vulnerability type is through input sanitisation, use of an interpreter and server-side input validation, where special characters are not needed.
A04:2021-Insecure Design
A ✨brand new ✨category for 2021, this category focuses on the risks related to architectural and design flaws in applications. With the hope of encouraging the use of threat modelling and security from the design level, it’s a fairly broad category that can be summarised as “missing or ineffective control design.” We need to ensure that we aren’t confusing insecure design with insecure implementation, as a secure design of an application can still be implemented insecurely! And likewise, and insecure design cannot be surpassed by secure implementation!
When we consider this category, some recommendations include the use of a secure development lifecycle that considers both security and privacy-related controls and the use of threat modelling for access control.
A05:2021-Security Misconfiguration
This pretty much does what it says on the tin! Security flaws can be introduced into websites through poor security configuration.
The best way to explain this is through an example. Let’s say you have an application and it is running common software such as WordPress… Users are usually added into the software by default so users can login and start configuring it before their site goes live. A vulnerability of doing so is leaving the default account, in this case it would be “admin”, as a real account in the software. Paired with a weak password this would make it easy for malicious actors to access the website and sensitive consequently stored on the site.
To prevent this from occurring would be to remove default accounts, prevent verbose logging or delete/ remove default config files, remove unnecessary features and review the configurations frequently.
A06:2021-Vulnerable and Outdated Components
An easy one, this is! When we talk about vulnerable and outdated components, it’s just that – components that may be exposed to known vulnerabilities which may (or may not) be due to being outdated or obsolete. To address this risk, ensure that you are aware of the versions of all the components in use by an application, including at the operating system or server level, and implement a patch management process to reduce the risk of vulnerable and outdated components being used.
Even better, if you’re not using a certain dependency/feature/framework – remove it, one less thing to worry about!
Source: Sonatype
A07:2021-Identification and Authentication Failures
This category includes a mixture of broken access controls and Common Weakness Enumerations (CWEs), also known as Security Misconfiguration vulnerabilities. Issues such as Improper authentication and session fixation are included in this category. But what exactly are they?
Improper authentication is when an application is vulnerable to attacks such as credential stuffing, where an attacker takes credentials used from breaches or unrelated accounts to gain access to the website, permits brute-force attacks or allows weak passwords and usernames. This technique could be prevented through account lockout or authentication failures, however, caution should be used to prevent introducing a DoS vulnerability. Ideally the application would implement two factor authentication and also perform weak password checks.
Session fixation occurs when session timeouts are not set correctly. For example, a session is still valid with the correct cookie or token, even after the user has logged out of their account. If the users session does not timeout, this is also an added layer of concern and misconfiguration. To prevent this, a server-side session manager could be built with hard to guess generated tokens to prevent people guessing a session ID and hijacking it or using the existing token to access unauthorised areas of the site.
A08:2021-Software and Data Integrity Failures
Another new category for 2021, this category primarily relates to code or infrastructure that does not verify against integrity violations. For example, if an application relies on different plugins and libraries from a variety of sources, we want to make sure that we can check and verify the integrity and “trustworthiness” of that source. We don’t want to be accidentally embedding risks related malicious code, do we?
This category also address the update functionality of these plugins/frameworks/libraries, we want to be able to check that auto-updates are legitimate and not an attacker trying to fudge their own update to run on installations. Recently nation-states have been known to abuse update mechanisms, the most notable attack recently being the SolarWinds supply-chain attack in 2020.
Some of the recommendations included in this category are the use of digital signatures to verify the authenticity and integrity of code, ensuring that libraries are using trusted repositories, and verifying components using a software supply chain security tool.
A09:2021-Security Logging and Monitoring Failures
This little category has been awarded a promotion, and has been escalated up a spot! It now further covers Improper Output Neutralization for Logs, Omission of Security-relevant Information, and Insertion of Sensitive Information into a Log File. This very much sounds like a layer 8 problem if ever I have spotted one.
A scenario where these vulnerabilities may become apparent is when several login attempts are not audited, log messages are inadequate and therefore security breaches may be missed, appropriate alerting is not in place or effective and the list can go on. Consequences of not having appropriate logging can mean hefty fines for companies that suffer a data breach. Air Europa was recently fined ~600,000 euros for violating GDPR and “not implementing technical and organisational measures to ensure an adequate level of security” ~ Data Guidance.
Spotting issues with logging is not common, as if a tester does not have access to the logging or monitoring systems, they will not know if any alerts have been triggered. However, preventative measures include: ensuring log data is encoded correctly, ensuring audit trails are implemented on high value transactions, establishing an incident response and recovery plan.
A10:2021-Server-Side Request Forgery
A category that was added from the top 10 community survey (taking the #1 spot…) this risk is a specific flaw seen in web applications where the application fetches a remote resource without validating the user-supplied URL. Attackers can abuse this vulnerability by sending a crafted (and malicious) request to a destination of their choice. In a typical attack, a threat actor may force a server to establish an internal-only connection or connections with arbitrary external systems.
You can conduct SSRF attacks against the server itself or other back-end systems, PortSwigger have written a fantastic article on SSRF here that details the two types of attacks (a bonus being the article also compliments their web academy).
SSRF is reportedly becoming more common as we move towards cloud services and architectures become more complex. There are two ways you can implement recommendations to follow defence-in-depth at both the network level and at the application level. At the network level, you may consider segmenting remote resource access functionality or enforcing “deny by default” firewall policies. At the application level, you may consider sanitising and validating client-supplied input and disabling HTTP redirections.
And with that, this is us kicking off the… New financial year..? With a bang! If you have any questions around this, please do not hesitate to comment on this post. We will definitely work with getting round to comments in a more timely manor.
We are very excited to be back and creating content, so please let us know your thoughts and provide us with any feedback and areas of interest. We can tailor our content more to what you would like to see! Equally, we will also dive deeper into the topics that we love, so hopefully that is also useful!
Sophia & Sarah <3
