It should be emphasised that the examination focused on the corporate website and not banking and transactional websites (or parts of websites) where a higher level of security would be applied. The corporate website was chosen as this is the principal ‘customer facing’ tool and is the primary method of commercial representation of an organisation on the internet. As such, it is reasonable to infer that the security level of the website is representative of the organisations’ approach to security. In this analysis we focus particularly on the payment provider sector.
The tests comprised checking several security vulnerabilities that might affect the corporate websites. These were all non-intrusive tests, i.e. tests that can be performed without affecting the confidentiality, integrity and availability of the websites. Nevertheless, the tests give a good indication of the actual security level of the website. In total, 144 companies were assessed. Of these, thirty-one are in the payment provider segment. This document specifically focuses on the payment provider segment. This will provide the opportunity for the most appropriate like-for-like comparisons. In this document, the ten most common vulnerabilities among payment providers are described. Table 1 below provides an overview of the vulnerabilities found in the payment provider subsection. For reference, table 2 provides an overview of all assessed companies in the fintech sector. The results show that for the fintech sector generally, and the payment provider segment specifically, a significant number of companies’ websites are affected by the tested vulnerabilities, meaning that they have not or sufficiently implemented appropriate, and often trivial, security measures. In most cases, the corporate websites allow visitors to leave their personal data via a contact form (for example, when requesting a call back, downloading a broachure or otherwise making contact). They also require, for personalised services (for example, quotations for insurance services, applications for new products) the visitors to present their username and password to log into another system within the website portal. This means it is crucial that the websites guarantee that this sensitive personal data is sufficiently secured.
The headline figure shows that from our tests over 64% of the investigated websites from the payment providers sector are affected by one or more vulnerabilities. These potentially allow eavesdropping on the connection between the visitor and the website. If we look at all fintech websites tested this figure rises to over 76%. This can have serious consequences for users and the fintech business as these vulnerabilities can allow access to hackers and other cyber criminals.
- Personal data theft by an attacker: any data (e.g. usernames, passwords, addresses) entered by visitors of the website could read by an attacker
- Privacy violations: an attacker to identify which pages are accessed by visitors, thus violating their privacy
Furthermore, the testers found that nearly 84% of the investigated websites from the payment providers sector are affected by one or more security flaws that make it significantly easier to obtain, modify or delete the potentially senstive data entered by visitors of these websites.
We typically rate the risk of cyber security vulnerabilities according to the severity, from Critical (requiring immediate action), through High, Medium and Low to Informational (vulnerabilities that should be acknowledged and monitored but require no immediate remedial action). The vulnerabilities identified in this analysis are in the mid-range of risk categories (medium or low risk). These vulnerabilities still pose a risk to both the business and end users, and still need investigation as even modest risks can allow attackers to access confidential and sensitive data, as described here.
The tables below show the top 10 issues found during the non-instrusive tests.
By their nature, fintech companies usually process sensitive data, of which the theft or alteration is likely to have a signficiant impact. The fact that so many websites of the fintech sector are affected by trivial flaws seems to imply that security received insufficient attention during the development and lifecycle of the corporate websites. It is the judgement of the Eurofins test teams involved in this project that the security level of the websites is below that which might be reasonably expected for current website, application and infrastructure design. As stated earlier, the security level of the corporate website of an organisation should be representative for the security level of the organisation. This could be an indication that other web applications than the corporate websites are affected by security flaws as well. The results of the test show that improvements can be made on both the application and infrastructure level. While this should improve the hardening level of the systems, these steps should also be incorporated in coding and deployment guides and procedures, in order to prevent these issues from appearing in new systems, or when the current systems receive an update. Website security should never be an afterthought, no matter what the nature of the site. Security needs to be a key consideration from the outset, in the design and planning phases. Ensure it is also part of the website development strategy and be regularly, or even continuously monitored, once the site is live. Hackers are finding ever more devious ways to access private and secure data in websites. Any site is at risk so it is crucial that you keep at least one step ahead. That’s a process that needs to take into account not only your website but your associated business practices and your staff: ensuring that they are able to recognise illicit web activity. Eurofins provides a comprehensive range of services, solutions and tools. We can provide advisory services for the secure and compliant development of your website. We can analyse and monitor existing sites and we can deliver training courses and simulations to empower your staff to detect suspicious activity, such as phishing. Get in touch to discuss.
To learn more about the vulnerabilities examined see below.
In the following section we describe the vulnerabilities found in the Payment Provider Sector in a little more detail
Lack of Strict-Transport-Security header
Occurrences: 27 (87.09%) The HTTP standard specifies multiple headers that can be used to increase the security of web applications and mitigate certain vulnerabilities. The Strict-Transport-Security header is not present on (all) application responses. This header specifies that the domain should only be accessed over HTTPS for future connections. Not using it may allow access to the application using plain-text HTTP.
Lack of Content-Security-Policy header
Occurrences: 26 (83.87%) The HTTP standard specifies multiple headers that can be used to increase the security of web applications and mitigate certain vulnerabilities. The Content-Security-Policy header is not present on (all) application responses. This header prevents modification of the application to include malicious content.
Lack of Referer Policy header
Occurrences: 26 (83.87%) The HTTP standard specifies multiple headers that can be used to increase the security of web applications and mitigate certain vulnerabilities. The Referrer-Policy header is not present on (all) application responses. This header prevents leaking URLs and parameters to other domains through the Referrer header. This prevents the disclosure of application paths and URL parameters to third parties.
Lack of Cache Control header
Occurrences: 26 (83.87%) The HTTP standard specifies multiple headers that can be used to increase the security of web applications and mitigate certain vulnerabilities. The Cache-Control header is not present on (all) application responses. This header configures whether to store the page in the cache of the browser and intermediate proxies. Not using it may expose sensitive information by storing it in these caches.
Lack of DNSSEC
Occurrences: 25 (80.64%) The Domain Name System (DNS) protocol is used for translating domain names into IP addresses and vice versa. DNSSEC is a feature of DNS to prevent malicious modification of these translations. When malicious modification is possible, an attacker can direct traffic to themselves instead of to the correct company system.
Lack of X Content-Type-Options header
Occurrences: 23 (74.19%) The HTTP standard specifies multiple headers that can be used to increase the security of web applications and mitigate certain vulnerabilities. The X-Content-Type-Options header is not present on (all) application responses. This header prevents insecure rendering of a page based on content type sniffing. This in turn prevents exploiting browser-specific vulnerabilities or shortcomings.
Weak cipher suite supported
Occurences: 20 (64.51%) Cryptographic cipher suites are used to establish a secure connection, e.g. HTTPS. Supporting weak cipher suites makes it easier to perform a so-called Man-in-the-Middle attack, allowing an attacker to eavesdrop on the connection.
Lack of CAA
Occurrences: 19 (61.29%) Certificate Authority Authorization (CAA) allows a domain owner to specify which Certificate Authorities should be allowed to issue certificates for the domain. This helps reduce the threat of an attacker tricking a certificate authority into issuing a false certificate for the affected domains. The lack of the DNS CAA record means that any Certificate Authority can issue a certificate for the affected domains. If an attacker manages to trick a Certificate Authority into issuing a certificate for a domain without being the owner, e.g. via a separate vulnerability or social engineering, the attacker can imitate the legitimate website and domain name, without triggering browser warnings for the end users.
Lack of X-Frame-Options header
Occurrences: 17 (54.83) The HTTP standard specifies multiple headers that can be used to increase the security of web applications and mitigate certain vulnerabilities. The X-Frame-Options header is not present on (all) application responses. This header specifies if the page can be loaded in frames, and from which origins. Not using this header may allow for so-called ClickJacking attacks.