Servoy Solution Protection

[rossent]

Hi Servoy,

We need to allow our end-users to be able to import our Servoy Solutions into their application servers but at the same time we need to prevent these solutions from being imported into Servoy Developer. How can this be done?

Also, what protection do you provide against the end-users changing the deployed solution code? For example, a "crafty" person can change the JavaScript code stored in the servoy_repository database - for ISVs this is a big "No-No".
In short, how can ISVs ensure that what they distribute as Servoy Solution is not tempered with and runs unaltered on the end-user application server?

[lwjwillemsen]

Hi Rossen,

We raised this question (together with (better ?) solution encryption wish) some three years ago at Servoy but no sound from Servoy since then...

Regards,

[david]

An involved discussion here:

viewtopic.php?f=22&t=15527

We figured out a solution years ago (the obfuscation and compiling logic is quite a bit more complex nowadays)—as in Servoy 3 years ago—and have tweaked it for each version of Servoy along the way. Has allowed us to collaborate with other developers and deploy locally while keeping out the idly curious for a long time:

viewtopic.php?p=51842#p51842

We're using the same process in the full javascript stack development we're mainly doing these days. Unravelling the results into structures that are organized and readable enough to develop against would not be a trivial task.

If you need this as part of your process, let me know. The tool is actually a Servoy application and most of the steps are automated.

[rossent]

The obfuscation is really not the issue here. All we are after is protection that the code which we deploy and the users import and run on their application servers is not modified by someone else (for example, by updating a few records in the repository database). Something similar to digitally signing the solution code. If it is tempered with - it should not run. We know that there is no 100% proven way we can prevent users from being able to "reverse engineer" our code, but at least we should be able to guarantee that what users get from us and install and run on their servers is "genuine" - if the users change somehow the solution code then there should be a way to "indicate" that.

In my opinion this must be a core feature of Servoy and we should not have to use outside tools to achieve it (developers do not need any third-party tools to digitally sign their .NET or Java code).

Also we want users to not be able to import our solutions in Servoy Developer (but should be able to import these same solutions in their Application Servers) - again, this must also be a core Servoy feature.

I am very anxious to see what the official Servoy stand is on this.

[david]

All we are after is protection that the code which we deploy and the users import and run on their application servers is not modified by someone else (for example, by updating a few records in the repository database). Something similar to digitally signing the solution code. If it is tempered with - it should not run.

Exactly. We pull all the code out of the repository and put in a plugin to achieve this. The plugin is signed along with all the other plugins. Importing into Developer at this point doesn't matter to us—all code is still in the plugin.

[rossent]

David,

I absolutely see a value in your tool, but from what I have seen, you do not pull "all" the code from the repository - there are still calls to your plugin left in the repository. So I can very easy change those and substitute them with some other code which does not call your plugin at all but instead does something completely different from the original intention of the code. So a "rogue" person with access to the database can change the designed behavior of the code and there is no way we can prove that the code which currently runs on the client's server actually did not come from us but was "tempered with". Currently, there is no way you can prevent that. We are looking for a protection against that scenario. I believe you will agree with me that this is Servoy's job, and a very important one.

[lwjwillemsen]

I believe you will agree with me that this is Servoy's job, and a very important one.

+1

David, many thanks for your answer (never thought anyone would make that effort, amazing). Still so much stuff each developer has to find out for him or her self...

Regards,

[david]

So I can very easy change those and substitute them with some other code which does not call your plugin at all but instead does something completely different from the original intention of the code. So a "rogue" person with access to the database can change the designed behavior of the code and there is no way we can prove that the code which currently runs on the client's server actually did not come from us but was "tempered with". Currently, there is no way you can prevent that. We are looking for a protection against that scenario. I believe you will agree with me that this is Servoy's job, and a very important one.

Sounds like a rather contrived situation. Usually you just care about people stealing your code if they get access to the repository database because it's all in plain text. The "rogue" level you are talking about is typically a client's issue, not your problem. And no software or network is safe from this kind of activity given the will and intent.

In any case, with our plugin it's easy to prove if "malicious" code was inserted—just look at the repository data. Our calls are very specific and in effect behave as API's—you can easily run code before and/or after but not in between. We view this as a collaborative feature, not a security risk.

I do agree with you that Servoy should have done something about code security a long time ago. We argued for it (quite intensely...) so that an ecosystem of readily available components/modules would develop around Servoy. There was a time when we believed Servoy could have really taken off and this feature was the lynch pin for lowering the distribution barrier. (Historical side note: check out http://www.servoy.com/marketplace.)