OWASP Top Ten
Application Pen Testing
The OWASP Top Ten is a standard awareness document for developers and web application security, defining the current most critical security risks to web applications. The list was last updated in 2021.
Here’s how our Application Pen Testing solution identifies these vulnerabilities and helps to mitigate risk.
A1:2021
Broken Access Control
Broken Access Control
This is where routes / views within the application are not properly protected, meaning users can act outside of their intended permissions.
There are dozens of Common Weakness Enumerations (CWEs) mapped to this category, including technical vulnerabilities such as Open Redirects, CSRF, Path Traversal – as well as more simple mis-applied permissions on records, pages, data, and services.
What Our Solution Does
All discovered routes are attempted during a crawl by an authorised and unauthorised user.
Access control mechanisms are validated by attempting to access components that should be restricted or should require prior authentication but fail to protect the resource.
Insecure or superficial access control systems that simply hide components but do not properly secure them are also identified.
Unfortunately, due to the custom nature of applications, our solution is unable to rule on whether a given instance of permitted forced browsing discovered is expected behaviour or an unintentional vulnerability, as it lacks context – however it does present this list in its report for review.
A2:2021
Cryptographic Failures
Cryptographic Failures
This category focuses on failures related to cryptography, which often leads to sensitive data exposure or system compromise. Examples include the use of weak encryption algorithms, weak or default passwords, weak encryption strength, or simple lack of transport layer protection (e.g., use of HTTP rather than HTTPS).
What Our Solution Does
Checks for and reports on many cryptographic issues, including checks for weak passwords, the use of cleartext (unencrypted) protocols for data transport (e.g., HTTP being offered rather than HTTPS), the use of weak or outdated encryption algorithms on HTTPS services, and many other issues.
All reported issues typically need manual review to determine whether there is a need for the data on the system or service in question to be encrypted in transport or at rest – if the data is intended to be publicly readable, then it is arguable that the use of weak (or no) encryption is acceptable and not a vulnerability.
A3:2021
Injection
Injection (including XSS)
Injection attacks are the most common type of fault found in web applications, they are usually the result of unfiltered user input being directly included into command executions or database queries.
Cross site scripting (XSS) is a specific and very common type of injection attack whereby an attacker can inject JavaScript content into an application that runs in a user’s browser. Often thought of as an attack against the users of an application rather than the application itself, some more complicated XSS attacks target the administration and backend systems of an application (2nd order attacks).
What Our Solution Does
Performs numerous checks for a large variety of injection attacks to build up a rationale as to why it thinks an application is vulnerable, and where it is vulnerable then provides an example of the payload it used to confirm the vulnerability along with technical detail and remediation advice. Browser and application frameworks evolve constantly, and new techniques and vectors are discovered all the time.
Injection vulnerabilities that are checked for include:
– XSS / Cross-Site Scripting
– SQL Injection
– NoSQL Injection
– XPath Injection
– Code Injection
– Command Injection
– LDAP Injection
– Expression Language Injection
Also covering a range of XSS variants including:
– Reflected and Stored XSS
– DOM Based XSS
– HTML5 postMessage XSS
– Adobe Flash XSS
– Second Order / Delayed Execution XSS
A4:2021
Insecure Design
Insecure Design
Insecure Design is a new category introduced by OWASP in its 2021 update. It focuses on risks related to design and architectural flaws.
It includes many “process” weaknesses that cannot be scanned for since they are human processes within an organisation, such as the lack of threat modelling, the lack of secure design patterns and principles, and the lack of standard and secure reference architectures by software development teams.
What Our Solution Does
The Insecure Design category is incredibly broad. Many of the CWEs mapped to this category rely on human-aware context of intended business logic vs actual implemented behaviour for example. However, our solution can check for many other types of vulnerability within this category, such as sensitive information displayed in error messages, missing encryption, and the ability to control file name or path traversal.
A5:2021
Security Misconfiguration
Security Misconfiguration
This category relates to the misconfiguration of any layer of the application stack from the operating system or cloud platform up to the individual deployed application layer. It can therefore include inadvertently exposed services or ports, out of date or un-patched frameworks or the stack on which the framework sits, default passwords, or verbose error display left enabled on production systems. Often it can be a case of the server administrator failing to change the settings within the stack to harden the security of the setup.
What Our Solution Does
Maintains a database of common configuration faults and out of date or unpatched frameworks and will flag these if detected.
It will also check for many other issue types due to underlying misconfigurations, including default passwords that have been left unchanged, the use of verbose error messages, sensitive cookies without the “http only” flag, overly permissive cross-domain allow lists, or weak configured ciphers. It also checks for XML External Entity issues which now fall into this category.
If configured to do so, it will perform a comprehensive infrastructure assessment against all IP addresses and web applications defined within the scope.
A6:2021
Vulnerable & Outdated Components
Vulnerable & Outdated Components
Outdated components refer to standard software that is used to support an application, but which has not been updated and is therefore at an “old” version known to contain vulnerabilities. Outdated components can exist at any layer of the software stack, from an unpatched kernel on the host OS, right up to third-party library dependencies referenced in the application codebase in JavaScript served for client-side execution. With the rise of the huge number of 3rd party components freely available on the internet for inclusion in applications, it’s not uncommon for a developer to find a component or library and include it in an application to solve a problem or provide common functionality.
What Our Solution Does
Looks at the libraries and JavaScript components used within an application using real browsers for confirmation of the existence and where possible to get the version. This is then compared to a regularly updated database containing thousands of known vulnerabilities within content management systems and reported back. In some cases, static analysis of the code of the component will be performed and any suspect areas will be highlighted in the finding.
The following dedicated assessment components are also provided:
– CMS Build review for: Umbraco, WordPress, Drupal, Magento, Joomla, and DNN
– Web Server and Proxy vulnerability checks for Nginx, Apache, IIS, Tomcat, Struts, F5 Load Balancers, plus many more
– Scanning for known server-side script vulnerabilities
– Client-Side JavaScript library checks to identify vulnerable and unsupported components.
Can also be configured to perform “credentialed infrastructure scanning” in which it makes use of privilege access to scanned hosts being granted by a customer to report on outdated OS and system level software.
A7:2021
Identification & Authentication Failures
Identification & Authentication Failures
Sometimes authentication can be implemented incorrectly or an application can contain routes to sensitive data that haven’t been correctly protected by an authentication barrier. In other cases, it can be the session token that is vulnerable either to enumeration or not expiring, this can allow an attacker to guess the session token of another user (e.g. an administrator) and take control of their session to steal data.
What Our Solution Does
While crawling an application our solution analyses the session for the possibility of enumeration by activating many sessions and examining the tokens. It will also look out for weakly implemented authentication, for example long response 302 redirects, which usually happens when the application serves up the content of a restricted view in the response of the page but then sends a redirect in the header.
It also includes configurable password guessing modules to identify weak account credentials with many systems, as well as specific checks for known default or hard-coded vendor passwords on equipment and services, the use of session IDs in the URL, plaintext passwords emailed to users during registration, vulnerabilities in forgot-password processes, and authentication bypass.
A8:2021
Software & Data Integrity Failures
Software & Data Integrity Failures
Another new category for 2021, “Software and Data Integrity Failures” focuses on the category of vulnerabilities that relate to making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. Examples include insecure deserialisation, in which objects or data that are intended to be immutable can be encoded or serialised by an attacker into a form or structure that an attacker can see and manipulate.
What Our Solution Does
As part of its injection checks, it will attempt to exploit both generic and specific deserialisation vulnerabilities across a wide variety of frameworks and libraries.
Our solution also has plugins to identify dependency confusion vulnerabilities which may affect the application’s build process based on the libraries detected to be in use by the application.
A9:2021
Security Logging & Monitoring Failures
Security Logging & Monitoring Failures
This is a broad category, including whether a system correctly audits security events such as logins and failed logins. It also includes issues such as when logs contain sensitive information.
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
What Our Solution Does
This category is extremely challenging to test for. Since logs are not typically exposed externally, it is not possible for a scanner to confirm if security events are audited (recorded) correctly – and certainly not whether logs are then subject to triggering alerts and being manually reviewed by security staff. To fully review this area would involve interviews with security operations staff or asking if attacks were detected during a scan.
Through creating a realistic attack scenario, our solution helps to flex monitoring and logging solutions and so can highlight weaknesses and omissions in current processes, but this must be performed in hand with manual review by customer security or incident response teams – for which our security team are always on hand to offer advice on best practice.
A10:2021
Server-Side Request Forgery (SSRF)
Server-Side Request Forgery (SSRF)
SSRF is a particular variant of injection attack – SSRF vulnerabilities are those specific attacks in which an untrusted remote party (an attacker) is able (via the malicious payload submitted) to force a server to perform requests on their behalf.
SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network ACL.
What Our Solution Does
Performs comprehensive checks for a massive range of web application vulnerabilities from first principle to detect vulnerability – including SSRF. It uses a variety of techniques to detect SSRF, including an out of band monitoring system to detect DNS and HTTP requests from the application in response to injected payloads, and proof of concept exploitation in cloud environments which interacts with services which are not exposed to the internet. It also draws on checks for known SSRF vulnerabilities in vendor software from a large database of known and published CVEs.