0

I am writing web app in PHP, which will communicate (via curl) with API (Java) for licensing purposes. Web app will be encrypted with IonCube. HTTPS will be used of course.

I am afraid that someone will e.g. override curl functions in some way and then prevent connecting with API. From this reason I want to verify that client (PHP web app) received response from the true API (Java).

My idea: API will generate unique token every day which will be verified by client during connections. Missing or incorrect token will block web app. No one except me won't know how the token is generated.

What do you think about my idea? Maybe I should do this in the different way?

matthew95
  • 41
  • 5
  • "I am afraid that ... override curl ...": Why can't you just default to a not valid state if you were unable to connect to the API server? "API will generate unique token ... will be verified by client ...": How do you plan on doing that? – Alex Barker Nov 05 '20 at 15:31
  • If you're planning on distribute the PHP source code to people, then they will be able to change what ever they want and can mock your API calls (or rather by-pass it all together.) To prevent that, you would probably need use some service that helps you encrypt the source. – M. Eriksson Nov 05 '20 at 15:31
  • Typically the major concern would be on the Java (server) side, worrying about malicious user attacks. Why do you have the requirement to verify the token's authenticity on the client side? – Tim Biegeleisen Nov 05 '20 at 15:33
  • AlexBarker Someone can override curl to response that license is valid forever, am I wrong? MagnusEriksson Code will be encrypted with IonCube. – matthew95 Nov 05 '20 at 15:34
  • I just want to check if the client has definitely connected to the correct API and it was not somehow falsified. – matthew95 Nov 05 '20 at 15:35
  • @evox95, they sure can. Ask Jetbrains about this problem ;) There is no way around that, the whole purpose of copy protection is to prevent the casual user from doing it. There is always a way to break it and nothing is 100%. Your best bet would be to verify the expected SSL cert fingerprint on the client side but your client will need to be up to date as your API ssl cert gets updated. Your API only needs to verify that a license key is valid, no need for convoluted security through obscurity token process. – Alex Barker Nov 05 '20 at 15:39

1 Answers1

3

Generally DRM is difficult, like VEEERY difficult, like not ultimately possible, every game gets cracked at some point and the DRM protection gets removed. E.g. if someone can "override curl functions" he surely can just change one of the php files to not call the API at all and remove any further check that would rely on the API having been called.

Removing the java and php terminology and instead using just "client" and "server", you want to ensure the client has a valid license to fully operate. You do that by calling a server. One of the golden rules is: never trust the client. Because the client can always be tampered with.

Now there are two kinds of applications you can think about: online vs. offline applications. Online applications need server communication to work, e.g. in a multiplayer game.
Offline application do not need server communication to work but only to authenticate. In the offline application environment you are generally out of luck because the client can just be changed to not call and not care about the licensing checks. Yes you can add some tools that obfuscate the code, or do some fancy stuff with it but at the end of the day it will still be code, some of the steps will be reversible and the result will be changeable. See. e.g. ioncube decryption in seconds :D
In the online application environment you can rely on completely normal login procedures: in the most basic sense for every regular interaction the client wants to make with the server the license token has to be sent along. If the token is invalid the server responds with an error code, end of story.

luk2302
  • 55,258
  • 23
  • 97
  • 137