Hack me if you can: TOP 3 tech vulnerabilities of online payments

I haven’t published a new article for quite some time, although I had a lot to talk about. The main reason is the impossibility of being in resource for everything at once. Blogging is not my forte, but payment streams are a whole different story. My name is Denys Mykhailiuk and I’m currently in the position of Architect in the bill_line team, so I’m particularly interested in strategic security issues and the workload of systems that process transactions. And today I want to list the three biggest exploits in the online payments userflow that I personally encountered or learned from my colleagues.

What a secure payment should look like

When you pay for your mobile phone account or transfer money, the process seems simple, almost instantaneous. Well, it’s nice, it means that the years of my colleagues’ work are bearing fruit: the servers are fast, the code is written correctly and it’s been regularly updated, and the designer and project manager have created a high-quality user flow that doesn’t have extra screens.

However, from the point of creating a secure software implementation, the transaction lifespan is a complex process that still has a lot of problems for everyone, from big banks and psp (payment service providers), to new players in the market who appear from time to time with offers in which you can always find  something like “simple and convenient API” and 5-10 minutes integration. Let me reveal a big secret – simplification has its own “ceiling point”. Compliance takes time, and businesses with processes that are more complex than simple retail have their own unique requirements or nuances that don’t fit into prepackaged scenarios.

So, what does a typical payment acceptance process look like? To begin with, consider the current implementation of tokenized payment when you (customer) try to pay for something, for example via Apple Pay\Google Pay:

1. The merchant’s website/app makes a request to the API server of his psp;
2. You don’t need to enter payment data, because the server sends them back in encrypted token form, thus skipping you to the payment stage;
3. If you were to do it via 24Pay\monopay on the website, then you would have to somehow authenticate yourself, but in the adopted scenario it’s not necessary. You only confirm the payment with biometrics (touch id or face id);
4. The tokenized order data flies to the API server again, after which it returns, confirming or canceling the possibility of payment (for example, insufficient funds on a bank card);
5. You see a success or error screen.

Here lies a simple and clear payment scheme (at this moment all casual readers laughed and closed the tab), which takes into account both security and the maximum seamlessness of the transaction. No payment parameters are passed explicitly, because of the tokens, which is already standard. Thanks to them, you can have recurring payments and pay in one click. The payment system server doesn’t send the results to some URL itself: instead, the website/app from which you pay makes independent requests and processes the response.

Okay, what could possibly go wrong?

In short, the devil is always in the details. Details that weren’t taken into account by the dev team, that were overlooked by individual team members or out of a simple desire to find a compromise between convenience and security not in favor of the latter.

#3 OTP code vulnerability

This topic is a little outdated, so it’s more relevant for desktop versions, the use of which is decreasing every year. However, the problem is still here. Always use the OTP code mechanism (one-time password) for all important operations in your project. One-time passwords’ lifespan mustn’t exceed 2 minutes and should be clearly linked to the operation being performed using an additional random parameter corresponding to the operation identifier. The same rule can be applied to biometrics in apps: always request verifications on basic end-user transactions. It is clear that customers won’t be satisfied with the constant need to enter a code from SMS or show their face, but this is how you will make sure any operation is carried out by the account owner.

#2 Lack of HSTS connection mechanism and lack of cookie protection by Secure and SameSite tokens

Modern browsers have a number of mechanisms to help protect data from interception, and HSTS is one of them.

It stands for HTTP Strict Transport Security – a forced connection mechanism using the HTTPS protocol. The Strict-Transport-Security header in the server’s HTTP response is responsible for activating the mechanism.

What other “spells” can be cast:

• HPKP (HTTP Public Key Pinning) is a public key pinning technology that prevents connecting to a web server if someone has changed the SSL certificate. The Public-Key-Pins header is responsible for activation;
• CSP (Content Security Policy) is a tool aimed at protecting against content injection attacks, such as Cross-Site Scripting. The magic is triggered by the Content-Security-Policy header;
• X-Content-Type-Options – a header intended to protect the user’s browser from attacks using the replacement of the MIME type of the transferred content;
• X-Frame-Options – headline against Clickjacking.

And now about the aforementioned markers. Secure requires cookies to be transmitted only over HTTPS. The absence of this token creates a threat of cookie interception. How to decide? Simple: set the requireSSL property to true.

However, using the SameSite attribute in Strict mode won’t allow cookies to be transferred to third-party resources and will provide protection against “Cross-site request forgery” type attacks.

#1 Deserialization of untrusted data

You mustn’t use serialized objects when passing in parameters that can be easily tampered with by an attacker. The easiest way to avoid this is to use a digital signature of such objects with server-side verification.

Ignoring such an error leads to critical vulnerabilities like “Arbitrary Code Execution” or “Untrusted Data Deserialization” as well as less obvious things. For example, while working on the server of an online bank, colleagues discovered an interface with the address of the bank’s internal network. Knowing this address, a hacker can attack the entire corporate infrastructure and even compromise processing.