Stephan Bruijnis .dev

Anonymous users enabled? Check these 3 common security misconfigurations

Anonymous users enabled? Check these 3 common security misconfigurations

Dec 7, 2021
Mendix
Security

Attackers are constantly on the lookout to exploit security vulnerabilities in applications and systems to gain access to or control of sensitive information. This post will discuss 3 security misconfigurations that often cause vulnerabilities in Mendix applications, even if you don’t have anonymous users enabled.

#1 Constants - exposed to client #

Constants are often used to define configuration values, these can differ per environment. Many developers use constants to store secrets, usernames or passwords. When a constant is exposed to the client, Mendix Runtime sends its value to the client. Allowing all users to retrieve and see the value of this constant. If anonymous users are enabled, the value will be publicly available.

Do not store sensitive data or secrets such as passwords in a constant which is exposed to the client.

How to check which constants are exposed #

Open Mendix Studio Pro and manually check all constants defined in the project, or run this JavaScript function1 from your browser console (F12):

mx.session.getConfig("constants")

it returns an array with all constants (and values) that are exposed to the client. The Mendix Marketplace has 7 constants exposed, below one of the array-values.

[
  {
    "name": "Frontend.RegexForValidURLAsString",
    "type": "String",
    "value": "^(?![\\s\\S])|(https?):\\/\\/(-\\.)?([^\\s/?\\.#]+\\.?)+(\\/[^\\s]*)?"
  },
]

#2 FileDocument specialisations - access rules #

A FileDocument is a system module entity that holds the contents of a file (for example, an invoice, legal advice, medical report, profile picture, etc.). Many applications and modules use specialisations of the FileDocument entity to create, download or display files. These files can contain a lot of personal or sensitive information, but setting proper access rules is often overlooked. To secure these files, the access rules should always be defined on the specialisation2!

Entity access constraints are not inherited from the generalisation.

How to find all specialisations #

Go to the System module in your Mendix project, look for the FileDocument entity and right-click. Select “find specializations”. Use the Find results panel to check each specialisation of FileDocument. Open these entities, and check the access rules. In general you want anonymous users (and other roles as well) to only access their own files. Set the access rule to: [System.owner='[%CurrentUser%]']

FileDocument find specializations

Deep links make it possible to directly link to a specific form or microflow within an application. Which is often used for things like forgot password, account activation or other transactional e-mails that contain a personalized link to the Mendix application.

In the DeepLink module configuration the developer needs to specify if an object or parameters are passed to the configured handler microflow. The security of the object that is retrieved in the handler microflow based on the parameters is often set to anonymous & read all (without access conditions). Which makes it possible for attackers to retrieve all objects of that specific entity and compose their own deep links. Which exposes data or functionalities to unauthorized users.

You should be able to identify the microflows called from deep links by their prefix DL_ — if the Mendix naming conventions are used. Open these microflows and check the (database retrieve) usages of the parameters. Check for each deep link entity the access constraints, it is best to let a sub-microflow perform the retrieve without entity access applied. This allows you to remove any access to the entity from a user role.

Additionally, make sure deep link URL’s are single use only and are short lived (for example 48 hours by adding a validUntil date attribute and checking these constrains in the microflow).

Check entity access rules!!! #

I cannot stress this enough, check the entity access rules. Access rules of an entity define what a user is allowed to do with objects of the entity. Too often a shortcut is used and Read/Write is selected on various, if not all, roles without any constraints.

Check the Mendix how-to’s for more information on how to properly secure your Mendix application.


  1. more useful JavaScript functions exposed by the Mendix Client API can be found in the Docs-section ↩︎

  2. Read more about applying security to inheritance ↩︎