API attack prevention, a real life example

API attack prevention

I posted a previous article about ways to protect Web Services and protect REST APIS and got contacted to help with an inquiry around how an API Gateway could help mitigate a recent attack that occurred. You will read below a real-life example of API attack prevention.

The API attack situation

The situation got described to me as this:

“The company provides an app for trading (stock papers) and is  receiving data thru an API. The hacker obtained user and passwords probably using phishing and reverse engineering to capture/rebuild specific payload structures to falsify operations.”

This sound scary doesn’t it? It is not that unusual. Companies like Kaspersky and others have already raised that more sophisticated cyber attacks are on the increase.

The diagnostics

So how can enterprises develop an API attack prevention strategy for such king of scenario?

In first place it needs proper monitoring to get detected which seemed to be the case here. It’s also interesting that in this scenario it was not a general issue of the implementation or mistake, it was caused by a higher level of effort to gain access to credentials. This can be seen quite often if the value of the data or action is high. Intellectual property, any kind of financial transaction (stock papers, payments etc.) are interesting here.

Some people might say, ah you need to encrypt the traffic to stop this kind of attack. The point is that this has to be implemented the right way on the client side too. If the attacker got access to login information, it’s likely that he would be able to gain access to additional things like Certs and Keys in order to be able to decrypt the payload.

The counter-measures for API attack prevention

1/ First counter-measures against this API attack: out-of-band notification

The receiving system could for example implement a notification system which would push notifications to the user. While the user gets onboarded for the first time, he could provide a mobile phone number where those notifications would be sent to.

If someone would take over your account, you would recognize it by getting those SMS push notifications without having to perform any action. This allows at least the user to quickly change the password or react on the account take over. Push notifications etc. can be provided by MBaas Platforms  and this can for sure be integrated within the policies of an API Management solution to get triggered.

You have to be a little bit careful with the onboarding process and make sure that it’s hard to change a mobile number too.

Those SMS can also be used to send messages when new devices get identified by different IP, Host Header etc. accessing the service. This is for example what Facebook or Google do when you login from different parts of the world. This doesn’t prevent the attack entirely but provides a way to react quicker.


2/ Second counter-measures against this API attack: 2-factor authentication

Another way could be to integrate with an OTP (One-Time-Password) system like Google Authenticator or other systems. Most providers like Apple, Google, Microsoft or AWS provide this two-factor authentication for their accounts. 

The second factor – a second password for example – is provided by the OTP app and is changed frequently (for example every 120 seconds). You can only access the service and execute actions if you have both username, password and the OTP.

There also exists an alternate method that consists in having 2-factor authentication leveraging SMS push notification containing an OTP. The SMS contains a timeboxed password you have to present for login or other actions that you want to perform and needs to be entered before any action get executed. This method is currently widely used here in Germany for interacting with your bank or insurance company to protect your account with an additional layer of security.

Leave a Reply