Security Configuration Problem

[rossent]

Hi Servoy,

I think there is a problem with the current implementation of the way the design-time security information is handled which results in an "unauthorized" access to forms and elements.
Consider the following scenario to reproduce the issue:

1. Create a solution with a few forms. One of the forms (e.g. Form A) is intended to be used only by administrators.
2. Create 2 user groups: Administrators and Users and at design time indicate that only Administrators have access to Form A by unchecking the appropriate checkboxes on the Security tab of Form A
3. Check the resulting formA.sec file - you will notice that it contains information only about the groups which do not have access to that form.
4. Create 2 users and assign them to the groups so that one of them is member of Administrators and the other is member of Users
5. Run the application and verify that members of the Administrators group have access to formA and the members of the Users group do not have access to that form.
6. Deploy the solution to a server and create again 2 users - one member of the Administrators and the other member of the Users group and verify that the application still behaves as expected and only Administrators can access the formA.

So far so good.... now comes the "fun" part.

7. On the server create a new group or simply import another solution which uses a different group - for example Guests
8. On the server, create a new user account (e.g. guest1 ) and assign it to be member only of the Guests group
9. Run the first application but this time login using the guest1 account
10. Access the formA (which supposedly was to be accessible only to members of the Administrators group) - you will see that the user guest1 which is not a member of the Administrators group in fact has access to that restricted form.

This issue applies to individual elements on the form as well and I suspect that it applies to table-level security also. As you can see, this is not even a hack and can be caused unintentionally by the administrators (all they need to do is simply import another solution which uses some other groups).

For sure almost all developers which bother to put any security in their applications using the design-time options in Servoy will not expect this. I am very skeptical that this is the designed and expected behavior but wanted to bring this question up to see what the official Servoy position is on this. To me, this looks like a very serious security issue which is very easy to exploit - all you need is a valid user account.

[sbutler]

This is the intended way, and how it has always worked. Servoy uses a Least Restrictive security model. So users have access to everything, unless you explicitly restrict them from it. In your example, when you added the new group, there are no permissions for that group on FormA, so users in that group will get access to it. Should that change? I don't know. I can see it being confusing to some.

However, you do have another option...
Most people don't use design time security model any more. Servoy added the security.setSecuritySettings(dataset) function to the API a long time ago, allowing you to roll your own security. There is an example implementation of this here: https://www.servoyforge.net/projects/servoy-security Essentially, you can do all the things you can do at design time, plus more, and its done via your own GUI and stored in the database. Then on login security.setSecuritySettings(dataset) is executed, and the security model is then applied. This has an interesting advantage in your situation because the sample solution shows how to setup default permissions for the application (which is very important in a Least Restrictive security model). So, for example, you setup that formA as not accessible on the application. Then on the Administrators group, you set it to accessible. Now only Administrators have access to it. So, you take everything away first at the application level, then add things back to certain groups. Its also handy that all the settings are in the DB, so you can automate the creation/modification of some permissions if needed, and make security changes without having to import another solution. Hope that helps.

[rossent]

Scott,

I agree with you that it has always worked this way but this does not make it right and it for sure is not the "intended" way but rather an unfortunate consequence of the current implementation which basically renders any application which uses design-time security with almost no security when there are 2 or more solutions using different security groups imported on the same server. Just imagine the case when a client imports on the same server solutions from 2 different vendors - at that point all bets are off as far as the application security is concerned. I already discussed this with Servoy and created a case for this issue: https://support.servoy.com/browse/SVY-7185

A better approach is to have another "built-in" security group: Public or Everyone (similar to the Administrators) and every user by default will be a member of this group and all permissions will be granted by default to this group. This way developers can opt to revoke certain permissions from the Public/Everyone group and grant them only to some specific group(s). There are other ways of achieving similar results which are beyond the scope of this post. The most important thing is to acknowledge that the current design-time security has serious flaws which need to be addressed. Since the design-time security is the easiest one to implement, many developers will chose this "least-resistance" path and it will be just a matter of time before someone exploits this vulnerability (if it has not happened already). I am sure that you are aware of all the efforts which the other platform vendors are investing in improving the security and best practices of their offerings. Why should we expect less of Servoy?

As for not using the design-time security - yes, this is exactly the option we took years ago for various other reasons. Still, whenever I see a serious issue with the Servoy platform (even in a part of the platform which we do not currently use) I cannot just turn away and pretend that it does not exist. As it is, Sevoy is not a mainstream development platform. Any flaw in it similar to this one just has the potential to turn away more developers from it which in the long run will have negative impact on everyone using Servoy.

[sbutler]

I wouldn't say Servoy is unsecure because of this. I would say there are a series of decisions a developer can make, which can accidentally result in an unsecure solution. Your example is one of those. At the moment you decide to introduce a new solution onto the same server that is already running another solution, you have to make sure your not adding other users and groups to your server which will be default be given full access to the solution (Since you haven't setup any privileges for them, and a lack of privileges equals full access). So you have to review those new groups your adding first, and setup the appropriate level of access for them.

If your stuck using the old design-time security, I have taken other approaches to solving this. One of those is to create some additional security metadata about which groups have access to which solutions. This is something that exists in most other application development environments I've worked in, but is missing from Servoy. So, in your example, you could set that only "Administrator" and "User" groups have access to Solution A. Then when you import Solution B, and it adds your new users and groups, they will be default have no access to the entire solution. This is a pretty simple thing you can manually implement yourself, but I could also see this being a nice feature to add.

One other thing to keep in mind, and this is really the achilles heel of design-time security, is by default the groups are shared across all solutions. So, if Solution A has an "Administrator" group, and Solution B has an "Administrator" group, when those get imported into the same server, you now have a similar problem, and have no way of distinguishing between the two groups. So a user in Administrators will be an admin in both solutions. Since people tend to name groups with common names, this can be a problem. So, this is another benefit of using the new security model options, like what is implemented in the Servoy Forge Servoy Security example framework. All the settings and groups are setup by Application, so a group membership on one solution doesn't give you any privileges to another solution using that same group name.

[david]

I agree with the premise that there is a flaw with design-time security. I also agree that fixing it isn't important.

The architecture of security was created before SaaS was even a term. When that whole craze came about Servoy added in some neat functionality to help code SaaS apps (data filters). They also added security upgrades over the years like the security module and extra methods to help rolling your own security (even though you could always code your own runtime security). And they were very aggressive in adding these features in.

The base level security I think still has its uses and you have plenty of great options if that is not enough. Nothing here that would keep potential Servoy developers away or lead current ones to leave. It's fine.