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.

  • 1
    What threat are you trying to protect against? Is it customers seeing your intellectual property? Or customers creating a data-leak involving their own data? Something else? – Bart van Ingen Schenau Sep 17 '18 at 15:41
  • 1
    Trying to prevent other companies from making money from our APIs without permission - we want some third parties to be able to do this, but they must be authorized. Updated question to reflect this important point, thanks. My research suggests that up to 80% of Goole Play store apps may have 'clone' apps, and this is one of those 'management-wants-it-this-way' things, so don't assume there is any inherent logic in the decision please. :/ – nothingisnecessary Sep 17 '18 at 15:46
  • 1
    should we assume that the customer will work with you to prevent these clone apps? if so you can use the same solution as with cloud based – Ewan Sep 17 '18 at 16:00
  • 1
    No - let's assume the customer could create the clone app, or the customer could work with a third party to ask them to create a clone app.. for example, maybe the customer wants an app but they don't like our price, or our schedule, and so hires some other company (or an intern) to turn one around quicker without going through our license & approval process – nothingisnecessary Sep 17 '18 at 16:04
  • 1
    Not sure this is helpful or relevant to the answer - I personally don't see a problem with letting third parties make the apps as long as my customers are aware that it is not our app and that the app is from a trustworthy source (i.e.: not evil). I think we could monetize it, offer training, require extra license for doing this, etc.. But imagine execs who didn't go to programmer school: they probably saw some presentation like "APIs make you agile!" and then were like "we need APIs!!" and then you tell them: "Ok, but this means third party apps are possible..." and they are like "NOOOO!!!" – nothingisnecessary Sep 17 '18 at 16:06
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.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.