An API, or Application Programming Interface, is how software talks to other software. Every day, the variety of APIs and the volume of API calls are growing. Every web and mobile application out there is powered by APIs. By nature of the APIs, many of them have a direct line to the heart of the user data and the application logic.
For example, getting control of the billing API would allow a hacker to redirect payments to his/her own accounts or mark purchases as completed, while the actual payment has not been received. Substituting a malicious or phishing API for a legitimate one can result in whole sites being taken over. We have seen catastrophic results of such actions in the recent security issues around cryptocurrency exchanges where hundreds of millions of dollars were lost.
Here at RestCase, we believe that the best security is preventive security. When we auto-generate security tests for your API, the first thing we are testing is the Man-In-The-Middle attack.
I more than welcome anyone who wants to check out the RestCase platform and our API testing - Create a project, API and start testing within seconds. Register for Free!
Let's go over this in-depth and see how can we prevent this attack from happening.
Man-In-The-Middle Attack (MITM)
‘Man-In-The-Middle’ attacks are when an unauthorized third-party secretly altering, intercepting or relaying communications between two interacting systems and intercept the private and confidential data passed between them.
MITM attacks occur in two stages: interception and decryption.
Here are 2 recommendations that will make your REST API more secure:
1. HTTP and Lack of TLS
The absence of a Transport Layer Security (TLS) in an API is practically equivalent to handing out open invitations to hackers. Transport layer encryption is one of the most elementary ‘must-haves’ in a secure API.
What is TLS?
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communications security over a computer network.
When secured by TLS, connections between a client and a server have one or more of the following properties:
- The connection is private (or secure) because symmetric cryptography is used to encrypt the data transmitted.
- The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session.
- The identity of the communicating parties can be authenticated using public-key cryptography.
- The connection ensures integrity because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.
Unless a TLS is used, risks of the fairly common ‘Man-In-The-Middle’ attacks remain very high. Use both SSL and TLS in your APIs, especially if you are going public with your APIs. Today, you can get a free certificate with Let's Encrypt.
SSL and TLS go a long way in removing basic API vulnerabilities with almost minimal effort.
To get an excellent report on how good your implementation is, run your URL against the Qualys SSL server test. Here is ours:
2. Use Strict Transport Security
Forcing SSL should be combined with HTTP Strict Transport Security. Otherwise, you run a risk of users entering your domain without specifying a protocol.
For example, typing example.com rather than https://example.com and then being redirected to HTTPS. This redirect opens a security hole because there’s a short time when communication is still over HTTP.
You can address this by sending an STS header with your response. This forces the browser to do the HTTP to HTTPS conversion without issuing a request at all. Instead, it sends the header together with a time setting that the browser stores, before checking again:
strict-transport-security:max-age=315360000; includeSubdomains
This means that the header is set for 10 years and includes all subdomains.
If you follow this simple two guidelines, it will make your REST API much more secure and less vulnerable to attacks.