1

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.

Pure.Krome
  • 113
  • 5
  • *"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. – Steffen Ullrich Jan 05 '23 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 Jan 05 '23 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 Jan 05 '23 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](https://mitmproxy.org/) (Here's an example (via google search) with [hacking the SSL cert on an iPhone](https://www.trickster.dev/post/setting-up-mitmproxy-with-ios15/) to do it). I've not tried it - which is why I'm asking this question/post. – Pure.Krome Jan 05 '23 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 Jan 05 '23 at 23:40
  • a follow-up .. i had assumed the worst, that your mobile app is distributed to your clients and their untrusted devices with the 3rd-party api secret embedded in the code .. is this the case? – brynk Jan 06 '23 at 01:15
  • @brynk Thanks for the follow up. Correct. The app is just posted to the Apple App Store (for example) and I now download the app from there, onto my iPhone I just bought at some shop with nothing else added to the iPhone. Literally vanilla/default iPhone. – Pure.Krome Jan 06 '23 at 01:28
  • the bigger concern may be that someone might extract the static secret from the binary, assuming no protective measures are taken .. does the 3rd-party api provider offer any other auth mechanisms besides a static secret? something along the lines of `oauth2+` or `aws-sig-v4` has the scenario in mind where you control a separate server that authorises, for a short period of time, your client's access to the 3rd-party api – brynk Jan 06 '23 at 02:04
  • @brynk No idea. The 3rd Party (which is a public marking/customer engagement company) provides an SDK for mobile devices. We asked a front end dev to check out the requests and they said they used a proxy (not sure what) and grabbed a few requests and reported back. I just checked their website out and they also have a Javascript Web SDK ... – Pure.Krome Jan 06 '23 at 03:36
  • .. if it worries you that the secret is embedded in the app, feel free to ask another question and get some advice (the point here is you don't even need to worry about tls interception - anyone could theoretically download and then reverse-engineer if your api secret is statically compiled into the app release) – brynk Jan 06 '23 at 03:54
  • but if you don't care too much about the security of the (token that allows for) interaction between your users and the 3rd-party api provider, then you just accept the risk with what you have - as @mentallurg and Steffen Ullrich have pointed out, the https interaction is practically as secure as you can make it – brynk Jan 06 '23 at 03:56
  • Even if the API Key is statically compiled into the app ... i should still be able to see the secret API Key in the request header, if i can decrypt the HTTPS request because i'm using a custom cert + my own proxy .... which means putting an API KEY in a header is BAD PRACTICE, right? (the big assumption here is that I can actually do this .. which I have yet to try) – Pure.Krome Jan 06 '23 at 04:14
  • Given that scenario is now more clear I've marked it as duplicate of several other questions which are about protecting API keys stored inside a mobile app. – Steffen Ullrich Jan 06 '23 at 05:20

1 Answers1

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.

mentallurg
  • 10,256
  • 5
  • 28
  • 44
  • Thank you @mentallurg for your answer So .. software like [MITMProxy](https://mitmproxy.org/) 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 Jan 06 '23 at 00: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 Jan 06 '23 at 01: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](https://www.trickster.dev/post/setting-up-mitmproxy-with-ios15/) and [here](https://www.trickster.dev/post/using-python-and-mitmproxy-to-scrape-private-api-of-mobile-app/). (Let's assume no CERT PINNING in the mobile app) – Pure.Krome Jan 06 '23 at 01: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 Jan 06 '23 at 01: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 Jan 06 '23 at 03:37