How to protect public REST API from attackers using network sniffing tools

user_10489583 0
Viewed 80

We are developing a desktop application in C++ which is distributed to our customers. It will communicate with the server using REST API over HTTPS. We are concerned about network sniffing software, such as Wireshark. By using such tools, malicious users could record the HTTPS traffic, extract request URL, headers and body and perform requests to our backend REST API server on their own using automated scripts or Postman.

I read an article which suggests that API keys should be used to identify that requests are really sent from C++ application. However, I don't understand how API keys prevent users from sniffing traffic? If API keys are included in HTTP header, they are still easily extracted by Wireshark.

Are there any other ways for ensuring that requests to our REST API server are actually sent from genuine and unmodified C++ application that we developed? How can we ensure that even if attackers use Wireshark, they won't be able to call REST API on their own using Postman (outside of our C++ application)?

api-key reverse-engineering rest security http
2 Answers

Sending the API key inside a TLS encrypted session (HTTPS) is perfectly safe as the headers are encrypted as well. The only thing that you may find in cleartext is the hostname/SNI of the server.

user_186830510

No, there is absolutely no way to make sure, that the requests are sent from the 'genuine and unmodified C++ application'. But if you want to raise the bar and make it way harder for an attacker to e.g. perform a Man in the Middle (MitM) attack and analyze the traffic, you can do following:

  1. API keys are a good thing. Do it.
  2. Pin the certificates to make MitM attack way harder to perform. Wireshark will see the traffic still, but it will be encrypted.
  3. Obfuscate the code, so even a binary analysis becomes harder.

This will not hold back a motivated attacker, but it will raise the bar significantly and unless you are doing banking apps (which I believe you don't, as banks buy themselves security solutions out of the box from some companies specializing in security design), then it may be simply not worth it to go through all the trouble of attacking apps with such protection.

user_8314600
Related