Question

Anonymous user breach the security

1

I have an application that has an anounymous user and registeration page, This anonymous user can manage another role called public user role, I have an user account entity which inherits from the account entity. And I applied the security on the level of my user account enity for the anonymous user role and prevent reading and writing or (even if the anonymous user role has no access on the level of my user account entity) When I send a hacking request without login(Anonymous user), I can read the data for the user account with the public user role . So because the anonymous role can manage public user role and Mendix will ignore any entity acess applied on user account entity for public user role.

asked 2017-01-19

Mohammad Fawzy

1 answers

Jasper van der Hoek · Answer 1 · 2017-01-19

If I understand it correctly your anonymous user sees system.user information that you don't want it to see?

This is something I have seen more frequently with misconfigured user role security.
In your userrole can you check what you have configured in your user role, under grantable roles (see this documentation page). When configuring 'grantable roles' you are implicitly giving read and write access to the user.

The option ALL gives your user read/write access to all attributes of every System.User record in the system. Even if this is configured differently in your subclass, the user can still read/write all system.User attributes.

The option SELECTED gives you access to read/write in all users with the selected user roles.
Checking NO boxes at all gives NO read/write access. For an anonymous user, there should be NO boxes checked.
Checking the box: "(no user roles)" is granting read/write access to users without roles.
So please note that checking a box always gives more access!

The security for the system.User information works slightly different than normal entity access. With normal entity access the most specific sub-class determines the security rules, you'd simply specify on this entity who can do what, and that rule specifies this for all attributes and associations for all parent classes.
Entities inheriting from system.User work differently, as you can see in the Modeler you can never specify read/write access on the attributes or associations from system.User the access to these system attributes are inferred from your user role in the system module and grantable roles. You can only specify what the access is to the fields in the subclass.

Having the system.Admin module role will grant you read(only) access to all system.User records and all their attributes.
Having the system.User module role will grant you only access to your own user.

The grantable roles checkboxes in the UserRole determine which write/access you get in addition. This is basically instance access. If you check any of the boxes in the grantable roles section you get full read and write access to all the users with the checked role (or all users without userroles if you check the last box)

My guess is that your anonymous user has one or more of these boxes checked.

In all the Mendix versions I have not seen structural issues in the security evaluation. So far the platform has always done exactly what has been configured, and I have never been able to pull data out of it that wasn't caused because of a configuration error (and that wasn't for the lack of trying).