3

Q: Is it 'safe' to include a secret API Key in a HEADER (for a request) which prevents bad actors from creating their own evil-requests by using your API Key ?

We need to send data to a 3rd party from our mobile app. Their SDK ends up sending requests to their REST api .. with our unique API KEY as part of the request HEADER.

So in my head, I'm simplifying this as a simple curl request with a custom HEADER that contains the api key:

(other headers/body stripped out)

curl 'https://example.com/api/data' \
-X POST \
-H 'X-Api-Key: some-guid'

Also, I'm thinking about the following threat models:

  • A passive attacker on the network (eavesdropping)
  • An active attacker on the network (can change packets at will, mitm, etc) <-- E.g. An attacker is doing MITM from their mobile phone <-> 3rd party server.

So - given all of this ... can't a bad attacker just snoop all the requests from their mobile phone (aka. MITM attack) and see this single request and now read the API key in the header .. and viola! they can now generate their own curl's?

I keep reading a consistent suggestion here and that is: If the request is done over TLS (aka HTTPS) then the request is "secure". But .. as suggested above, I can decrypt the HTTPS request, right? Then I can easily see the API key, right?

Am I missing something obvious here?

If this was server <-> server, I wouldn't care. If you are doing a MITM on that level then I have bigger things to worry about now.

But because this is a mobile phone - surely this is a security issue?

UPDATE 1: Including topology example, of a single request:

  • 📱Mobile Phone (with a custom proxy set)
  • 💻My computer with the custom proxy MITMProxy running
  • ☁️ Interwebs
  • 💻3rd Party API Server

UPDATE 2 Re-reading my comments I feel like I'm basically saying "please tell me how to be a bad-actor/hacker". 😓 I'm actually reviewing some 3rd Party SDK which is to be used in our iPhone/Android App .. and we're thinking: this could be a security issue as someone could steal our API Key (using the steps/thinking, above) and abuse our account .. which means abuse our customers.

13
  • "Am I missing something obvious here?" - you are assuming that HTTPS MITM is actually doable. But a MITM attack to a HTTPS connection is not possible unless the victim trusts the attacker (as in case of MITM by explicitly trusted security products like antivirus or firewalls) or the client application has broken certificate validation. Commented Jan 5, 2023 at 22:36
  • i'm trying to understand your topology, so please clarify any error: your mobile app connects to a 3rd-party's web-api, and this web-api needs a secret, and the secret is provided via http header to their server api endpoint? if this is correct, the only option you have to guarantee that your api secret can't be stolen is to proxy the 3rd-party web-api call using your own web-api
    – brynk
    Commented Jan 5, 2023 at 22:45
  • HTTPS protects against on-path attackers, passive listeners, etc. It does not protect against compromised endpoints. The two endpoints that participated in key establishment, and no one else, can decrypt or control the contents of a TLS session.
    – Ben Voigt
    Commented Jan 5, 2023 at 22:49
  • @SteffenUllrich I'm under the impression that I can easily see HTTPS encrypted traffic (by using MITM) between a mobile phone and a 3rd party server via software like MitmProxy (Here's an example (via google search) with hacking the SSL cert on an iPhone to do it). I've not tried it - which is why I'm asking this question/post.
    – Pure.Krome
    Commented Jan 5, 2023 at 23:37
  • @brynk - Yes, that is the topology. mobile phone 📱 -> internet ☁️ -> 3rd party API server 💻. As commented just above, couldn't I just use the MITMProxy software to intercept the HTTPS traffic and therefore see all the headers, including the API key header .. and viola! I have the api key, now?
    – Pure.Krome
    Commented Jan 5, 2023 at 23:40

1 Answer 1

2

I can decrypt the HTTPS request, right?

No.

TLS connection begins with establishing a secret encryption key (session key) using Diffie–Hellman key exchange. This method allows to create the same key on both sides without sending this key. If the attacker intercepted all the data between client and server, it will be still impossible to create this key.

A man-in-the-middle cannot interfere this step, because the server response contains data signed by the server. The attacker cannot fake the server signature without having server private key.

After client and server established the secret key, they use it to encrypt their communication. The encryption algorithms, AES or ChaCha20, are strong and cannot be brute-forced.

TLDR: The attacker cannot decrypt the intercepted data.

To decrypt the intercepted data, the attacker would need to obtain the server private key. For serious websites it is almost impossible.

Is it 'safe' to include a secret API Key ... ?

It depends on how reliable the 3rd party is. If they use TLS 1.3, if they keep their private key securely, for instance, in HSM, if they follow normal security practices (limit access to their infrastructure, properly rotate keys, revoke certificates immediately when there is a reason instead of trying to hide that, etc.). Also it depends on how you implemented the client part, e.g. if you properly validate their certificate each time you establish connection. If all this is implemented properly, then yes, it is safe to send secret API key via such connection.

5
  • Thank you @mentallurg for your answer 😊 So .. software like MITMProxy can't be used to intercept the HTTPS request and then decrypt the full payload, showing all the headers, including the custom API Key header? Remember -> this is between a mobile phone -> proxying to my computer with MITMProxy -> internet -> 3rd party server
    – Pure.Krome
    Commented Jan 6, 2023 at 0:51
  • To make MITMProxy and similar tools work, you need to make them trusted. Means, you break security of your client intentionally. If you don't use such tools but the attacker wants to use them, the attacker will need to break security of your device. Without breaking the security, your device will notice that the connection is insecure (because such tool is a MITM) and will refuse to continue.
    – mentallurg
    Commented Jan 6, 2023 at 1:03
  • In this scenario, I'm the attacker (for argument sake). So I break the security of my iPhone. Like in this quick post, I add a custom certificate to my iPhone. Now, I should be able to see what the API key is of this random application I'm using .. and then make malicious attacks? 2x examples of this are here and here. (Let's assume no CERT PINNING in the mobile app)
    – Pure.Krome
    Commented Jan 6, 2023 at 1:26
  • You contradict to yourself. The OP implies that there are fair users and there is an attacker. Now you are saying you are user and you are attacker simultaneously. You cannot be the user and the attacker simultaneously. Otherwise this means that your users are attackers. Means, you give attackers access to your application knowingly. And when you knowingly give access attackers, then why are you worrying about security at all?
    – mentallurg
    Commented Jan 6, 2023 at 1:36
  • re: I am contradicting myself: do you mean where I suggest the two type of threat models? "Now you are saying you are user and you are attacker simultaneously.". I'm sorry if I'm not communicating correctly :( I'm trying to say: "anyone can be a user. Just download our App from the AppStore. Right now, I'm going to pretend I'm a User .. and at the same time an attacker by snooping in the middle". So maybe there's a better way to describe that, in security lingo? I'm sorry if I'm muddling up all the lingo and explanations.
    – Pure.Krome
    Commented Jan 6, 2023 at 3:37

Not the answer you're looking for? Browse other questions tagged .