The Open Web Application Security Project (OWASP), Top 10 list (maintained since 2003 and announced every few years), highlights the ten most critical security risks to web applications.
It is recommended that organisations adopt the OWASP Top 10 to ensure their web applications are not exposed to any cyber risks.
According to OWASP:
The Top 10 OWASP vulnerabilities in 2021 are:
- Broken Access Control
- Cryptographic Failures
- Insecure Design
- Security Misconfiguration
- Vulnerable and Outdated Components
- Identification and Authentication Failures
- Software and Data Integrity Failures
- Security Logging and Monitoring Failures
- Server-Side Request Forgery (SSRF)
How was the OWASP Top 10 put together?
OWASP selected eight of the ten categories from contributed data and two categories from the Top 10 community survey at a high level.
AppSec (Application security) researchers attempt to find new vulnerabilities and new ways to test for them. Because of the nature of the testing, it takes time to integrate these tests into tools and processes. More than likely, years will have passed, so it’s not easy for OWASP to accurately test a weakness at scale.
To balance this view, OWSP conducts a community survey. The survey asks application security and development experts (in the field) what they see as essential weaknesses that the data may not have shown yet.
What is included in the OWASP TOP?
A01:2021-Broken Access Control
Access controls enforce policies so that users are unable to act outside of their intended permissions. Failures generally lead to unauthorised information disclosure or modification, destruction of data, or performing an organisation function outside a user’s restrictions.
Formerly known as Sensitive Data Exposure, Cryptographic Failures are all about protecting sensitive data. This includes personal information such as passwords, credit card numbers, health records, and other data organisations require extra protection for. Cryptographic Failures is especially worth noting if the data falls under GDPR or other regulations.
Injection occurs when suspicious data is sent to an interpreter as part of a command or query. An example of this could be a malicious user controlling the response generated by an application and managing the servers, thus deceiving the interpreter to carry out unintended commands or access data without proper authorisation.
Applications are at risk when:
- User-supplied data is not validated, filtered, or sanitised by the application.
- Dynamic queries or non-parameterised calls without context-aware escaping are used directly in the interpreter.
- Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
- Hostile data is directly used or concatenated. The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures.
Insecure Design focuses on risks related to Design and architectural flaws. There is a call for more threat modelling, secure design patterns, and reference architectures to go beyond “shift left”.
According to OWASP, “Insecure Design is not the source for all other Top 10 risk categories. There is a difference between Insecure Design and insecure implementation. We differentiate between design flaws and implementation defects for a reason, and they have different root causes and remediation. A secure design can still have implementation defects leading to vulnerabilities that may be exploited. A perfect implementation cannot fix an insecure design as, by definition, and needed security controls were never created to defend against specific attacks. One factor contributing to insecure Design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine what level of security design is required.”
While several vulnerabilities happen because of underlying code errors, this Security Misconfiguration relates to the misconfiguration of any layer of the applications stack from the software package or cloud platform up to the individual deployed application layer. It will thus embody unknowingly exposed services or ports, out of date or unpatched frameworks or the stack on that the framework sits, default passwords, or prolix error show left enabled on production systems. Typically, it may be a case of the server administrator failing to alter the settings inside the stack to harden the protection of the setup.
A06:2021-Vulnerable and Outdated Components
Vulnerable and Outdated Components includes any software that is vulnerable, unsupported, or out of date. If you are unsure of the versions of your components – including all direct and indirect dependencies – or you neglect to scan and test your components, you are likely at risk.
A07:2021-Identification and Authentication Failures
To protect against authentication-related attacks, it is critical there is confirmation of the user’s identity, authentication, and session management. Failure to do so can result in attackers being able to exploit passwords, key session tokens, or implementation flaws and assume a user identity.
A08:2021-Software and Data Integrity Failures
Software and data integrity failures are defined as code and infrastructure that are not protected against integrity violations. For example, when an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs).
An insecure CI/CD pipeline can introduce the potential for unauthorised access, malicious code, or system compromise. Additionally, many applications now include auto-update functionality, where updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers could potentially upload their updates to be distributed and run on all installations. Another aspect to consider is where objects or data are encoded or serialised into a structure that a malicious attacker can see and modify is vulnerable to insecure deserialisation.
A09:2021-Security Logging and Monitoring Failures
Security Logging and Monitoring Failures includes errors in detecting, escalating, and responding to live breaches. Without logging and monitoring, a violation or breach will not be seen. Examples of insufficient logging, detection, and monitoring include not logging auditable events like logins or failed logins, warnings and errors that generate inadequate or unclear log messages or logs only stored locally. Failures in Security Logging and Monitoring Failures will impact visibility, incident alerting, and forensics.
A10:2021-Server-Side Request Forgery (SSRF)
SSRF (Server-Side Request Forgery) flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. An attacker is then able to force the web application to send a specially crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of access control list (ACL).
Web Application Testing with Sapphire
As organisations conduct more business online and deliver services conveniently, these systems are open to being exploited. Sapphire will test these systems, advise on the security configuration and vulnerabilities within a selected website application.
Typically, in two stages, the test will be completed initially with no authentication to the application and then with a valid user account for testing privilege escalation vulnerabilities and assessing any weaknesses with the authentication and authorisation mechanisms.
Sapphire will test the user journey based on all the system’s features, such as registration, content or document uploads, e-commerce facilities, form submissions, and reporting based on several user roles. Using the OWASP guide, we will check all the website functionality, authentication, and validation.
As part of our structured web application reports, Sapphire will respond to your key security questions, namely:
• Are the web applications suitably protected from unauthenticated users gaining access to members or admin data services?
• Are the web applications suitably protected from malicious authenticated users?
• Are the correct user management practices preventing horizontal and vertical privilege escalation from obtaining personal details?
• Is there correct segregation between users and admin accounts?