3

Goal: Prevent unauthorized 'clone' apps from using REST API-based solutions where the customers manage their own servers and services instead of the vendor doing so (database, resource, and identity). In other words: on-premise servers instead of a cloud-based solution.

My company wants to be able to authorize only some third-parties to be able to create apps that can use our APIs, but not just anybody, in addition to our own apps. So we will likely have some process where third parties will submit their apps to us for signing and adding to some kind of 'white-list' (whatever form that ends up taking.. hence the question.)

(Why no cloud? Some countries and industries are subject to stricter regulations where cloud or off-site servers is not an option for some classes of sensitive operational data. If that is not good enough of a reason, then please consider this a thought experiment).

This question is a variation on this near identical question, but with the additional constraint that the software vendor doesn't own or manage the servers.

I have zero affiliation with CodeBlue, the makers of Approov, but they did publish a decent explanation of the typical process for securing REST APIs for both web apps and mobile apps. Here is a link to part 2 of 3 which covers some of the critical points such as the mediation server and the attestation process for authorizing the client and techniques for keeping shared secrets out of public clients (i.e.: mobile apps).

https://www.approov.io/blog/mobile-api-security-techniques-part-2.html

The solution described by the above article from CodeBlue sounds dandy for a cloud-based or vendor-controlled environment. However, I have been struggling to find a way to protect against clone apps when the customer has physical access to not only the clients, but to the servers. Configuration alone could probably enable unauthorized apps, and if that doesn't work the app itself could be modified.

Of course there is a legal safety net here (license agreement, terms of service), but is there anything code-wise that can be done to harden against this, if not prevent it outright?

I am aware of - and pursuing - various techniques for obfuscating solutions (like spreading the secrets around, and protecting against reverse engineering) and for client attestation, but in all of my models so far there exists the possibility that a malicious customer (or agent) can trick the REST API into believing that requests are made by an authorized client. I know I'm in some kind of arms race here - so I'm reaching out to the community for thoughts on this because all of the methods I have researched over the past week rely on the vendor owning the server.

nothingisnecessary
  • 139

2 Answers2

2

It seems like you have a quite specific requirement.

Technically its not possible, but people implement solutions anyway. As you only really need to make it harder, not impossible.

In your case I would obsfucate the API and issue client libraries to authorised developers with embedded ids. Possibly you could simply encrypt the data with a shared secret. Or use a custom binary serialization.

That way you make it hard to create your own client and can work out who leaked if you find the clients in unauthorised apps.

Releasing frequent updates to the servers which tweak the API will put extra burden on unauthorised app developers.

Of course your customers might choose not to install the updates. But they will eventually want the features that come with them.

Ewan
  • 83,178
2

My understanding is that you have a deployed solution which your organisation believes is secure because it is a closed API and a closed app. So, my first thought is to emphasise that you already have no way to track the apps that are accessing your API - there is no such thing as a private API. It is normally trivial to reverse-engineer the API from listening to traffic or reverse-engineering the app. As your customer has both the server-side and the app they must already have access to all code they need to achieve this. API-Keys, code obfuscation, pinned connections - these are normally quite easy to circumvent for experienced professionals. (As mentioned regularly on the Approov blogs you reference.)

That being said, I believe your use-case can be supported by the normal Approov flow but with asymmetric keys to sign the JWTs used to transmit trust between the Approov cloud service and your backend. Using an asymmetric key allows your backend to verify the token signature without access to the private key used to sign the tokens. This way the backend will only service requests from registered apps. Of course, this solution will not prevent your customers from completely cloning your backend service. like you suggest, but as I said, you have that problem with your existing solution. (You can contact Approov to see how they can support this flow.)

Disclaimer: I work at Approov

Exadra37
  • 141