Web and app security for FinTechs

As studies show, startups in the financial sector, as well as traditional banks, still have homework to do when it comes to the IT security of their websites and apps. Due to an ever-growing cybersecurity threat landscape, companies in the financial sector face the major task of ensuring both the functionality of their own systems and the security of customer data. What do modern and intelligent cybersecurity solutions for banks and FinTechs look like?

For a detailed overview of the current threat landscape in the financial sector and the types of threats, please refer to our previous article on possible cyberattacks.

Summary

Time and again, studies show the weaknesses of the major FinTechs. These usually involve old software versions on forgotten subdomains or neglected APIs. As a result, most FinTechs do not meet the requirements for encryption, security, and data protection. Still, in terms of their web presence, FinTechs generally perform better than traditional banks.

Of course, although the financial sector is being addressed here in particular, companies in all industries must protect themselves against cyberattacks. In the first months of 2021, numerous internationally active corporations from the food industry and the energy sector were already targeted by professional cyberattacks.

Security situation of FinTechs

Security experts and analysts from ImmuniWeb, a company specializing in web security, took a closer look at the security systems of the 100 largest companies in the FinTech sector. All tests were carried out exclusively using information that can be obtained from the public Internet. In other words, the company did not break into any computer systems or networks belonging to the organizations under review.

The investigation covered the websites of the FinTech companies, including all subdomains and recognizable API endpoints, as well as their apps. The team tested the security of the software currently in use, the configuration of SSL encryption, and the possibility of phishing attacks against the operators of the websites and apps. In addition, compliance with the EU GDPR and the PCI DSS credit card data processing standard was reviewed.

The most common vulnerabilities encountered were:

• Various forms of cross-site scripting (XSS)
• Data leaks
• Misconfigured security settings

Another problem identified was that half of all server backend systems, which are supposedly meant to communicate exclusively with mobile apps, also disclose parts of their data to third parties. That can create data protection problems, but also dangerous security gaps that cyberattacks can exploit.

Positive: FinTechs are ahead of traditional banks. Overall, the 100 startups tested perform better in almost every area than the top 100 credit institutions on S&P Global’s list of the largest banks.

In summary, it is important for the entire financial sector and beyond to keep IT security standards high in order to protect against the growing number of cyberattacks.

Protection against cyberattacks

Below, we take a closer look at possible vulnerabilities and security features for Android and web applications. Banks and FinTechs are usually present across all platforms, so security must be high both on the individual platforms themselves and across the stack.

Securing mobile apps properly using Android as an example

Android itself has built-in security features that significantly reduce the frequency and impact of security problems in applications. The system is designed so that apps usually only access their own data, and any other permission, such as access to contact information or the camera, requires the user’s explicit approval. The operating system therefore implements a very restrictive permission model.

The following core security features help developers build secure apps:

• Android App Sandbox, which isolates an app’s data and code execution from other apps. The Android platform uses user-based Linux protection to identify and isolate app resources. This isolation protects the entire system and other apps from damage. To do this, Android assigns each application a unique user ID (UID) and runs it in its own process.
• App-defined permissions for controlling application data on a per-app basis. For example, camera access must be approved separately for each app. The user can also choose between one-time and permanent permission.
• Encrypted data systems that can be enabled to protect data on lost or stolen devices. To activate them, Android users only need to protect their device with a PIN through Settings > Security and enable encryption by default. Depending on the device manufacturer, this may already happen during initial setup.
• Creating application frameworks with robust implementations of common security features such as cryptography, permissions, and secure IPC (interprocess communication).

These security features often form the basic building blocks for app development. There are many ways to implement security functions. Here we explain three important elements: data storage, the Android Keystore system, and security when programming with native C/C++ code.

Secure data storage

The most common security concern for an Android application is whether data stored on the device is accessible to other apps. There are three basic ways to store data on devices: internal storage, external storage, and the use of third-party providers. Proper data storage is extremely important for companies and their customers.

Internal storage

By default, files created in internal storage are accessible only to the app itself. This protection is already implemented by the Android App Sandbox and is sufficient for most applications. Files such as MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE should be avoided, because they do not allow access to be restricted to specific applications and do not provide control over the data format. If specific read and write permissions are still needed for other apps, dynamic permission assignment should be used.

External storage

Files created on external storage are globally readable and writable. Since external storage can be manipulated by the user and changed by any other application, it should not contain sensitive information. For secure reading and writing on external storage, use the Security library, which provides the EncryptedFile function.

When input and data from external storage are processed, input and data validation should be carried out, just as it should be for data from untrusted sources.

Third-party providers: Content Providers

Content Providers provide a usually well-structured storage mechanism that restricts data access to the app itself, but can also allow access by other applications if needed. If such access is not intended, access should be denied through the appropriate configuration.

• Allow access to stored data: set android:exported to true in the app manifest
• Do not allow access: set the Content Provider to android:exported=false

When creating a Content Provider that is exported for use by other applications, there are several ways to grant access. There can be one or multiple permissions for reading and writing. The basic rule is to limit permissions to what is required to perform the task at hand. In general, it is easier to add permissions later to enable new functionality than to remove them and affect existing users.

Android Keystore System

The Android Keystore System (AKS) can be used to store cryptographic keys and make them harder to extract from the device. Once keys are in the Keystore, they can be used for cryptographic operations such as encrypting data or even entire databases.

It also offers ways to restrict when and how keys can be used, such as requiring user authentication for key usage via PIN or biometric authentication on the device, or restricting keys to certain cryptographic modes only.

AKS protects key material from unauthorized use. First, it protects against extracting key material from application processes and from the Android device as a whole. Second, it protects against unauthorized use by allowing the app to define authorized key usage and enforce those restrictions outside the process as well.

Be careful when choosing between SDK and NDK

In general, Android SDK (Software Development Kit) should be used for application development. It relies on the Kotlin programming language (formerly Java) and includes the security features listed above out of the box. There are special cases, however, such as demanding 3D games, which may instead be built in C/C++ code using the Android NDK (Native Development Kit). Applications built with the NDK are more complex, less portable, and more likely to contain memory bugs. When working with native code, it is extremely helpful to know best practices for secure Linux development, because Android is built on the Linux kernel.

One important difference between Android and most Linux environments is the application sandbox. Under Android, all applications run inside the App Sandbox, including those written in native code.

Securing web applications properly

Web application security is the process of protecting websites and online services from various security threats. Web applications are often attacked because of vulnerabilities in the application code. Common targets include content management systems such as WordPress, database administration tools such as phpMyAdmin, and SaaS applications such as CRM systems.

Why are web applications considered high-priority targets for cyberattacks? The reasons include:

• The inherent complexity of source code, which increases the likelihood of overlooked vulnerabilities and malicious code manipulation.
• High value for attackers, including sensitive private data that can be collected through successful source-code manipulation.
• Ease of execution, because most attacks can be automated and launched indiscriminately against tens or hundreds of thousands of targets at once.

Security vulnerabilities in web applications

Web application vulnerabilities are often the result of missing input and output sanitization, which can also be found in FinTechs and especially traditional banks. Such legacy issues can be used to manipulate source code and may give attackers unauthorized access.

These vulnerabilities enable a range of attack vectors, including:

• SQL injection - occurs when an attacker uses malicious SQL code to manipulate a backend database so that it reveals information. The consequences range from unauthorized data access to administrative access.
• Cross-site scripting (XSS) is one of the most common and serious vulnerabilities in the financial sector. XSS is an injection attack aimed at users in order to access accounts, activate trojans, or modify page content.
• Remote file inclusion - attackers use this type of attack to inject a file remotely into a web application server. Such attacks can lead to theft or manipulation of data.
• Cross-site request forgery (CSRF) is an attack that can lead to unauthorized transfers of money, changed passwords, or data theft. CSRF is also one of the biggest threats in the financial sector.

In theory, thorough sanitization of inputs and outputs can eliminate many vulnerabilities and make an application almost immune to unauthorized manipulation. In practice, complete sanitization is usually not an option, because most applications are in a constant state of development. In addition, complex integrations between very different applications make it difficult to identify such legacy issues.

To avoid these threats, web application security solutions and enforced security procedures such as certification according to the PCI Data Security Standard (PCI DSS) should be used. PCI DSS is also of enormous importance for the financial sector, so these safeguards must be continuously improved.

Application Firewalls (WAFs)

WAFs are hardware and software solutions used to protect applications from security threats. They are designed to inspect incoming traffic to block attack attempts and compensate for any shortcomings in code sanitization. By protecting data against theft and manipulation, the use of a WAF meets an important criterion for PCI DSS certification. For example, the data processing standard states that all cardholder data stored in a database must be protected.

In most cases, using a WAF does not require any changes to an application, because it is placed before the DMZ at the edge of the network. From that position, it acts as a gateway for all incoming traffic and blocks malicious requests before they even have a chance to interact with the application. Of course, WAFs must also stay up to date with the current threat landscape.

Almost all WAFs can be configured specifically for particular use cases and security policies. For example, banks and FinTechs can place special emphasis on protecting against individual and industry-specific attacks and build their security systems accordingly.

Goal: cybersecurity

Fundamentally, just as security can never be guaranteed inside a bank branch, protection in the digital age can never be 100% guaranteed either. For the financial sector in particular, continuous monitoring and modernization of the systems in use are therefore essential.

Good protection against cyberattacks begins with the design of applications themselves, with security-by-default and security-by-design, and ends only when the application is no longer used by customers and internal and external data has been deleted.

With regard to compliance regulations, the banking sector in particular remains a clear focus of regulators. It is therefore very important to adhere closely to applicable security standards and, where appropriate, go beyond them. Modern and targeted security systems are also important for fraud detection and prevention as well as for audits.

The challenges in cybersecurity will continue to grow in the coming years. We are happy to tackle them together with you. Contact us if you have any questions or ideas.