Disclaimer: This is a security testing guide that should only be used for authorized testing. A lot of the techniques and vulnerabilities come from the Mendix Capture The Flag event and the subsequent writeups. This is mainly aggregating and building on top of previous work done by Alex Polle so kudos to him.

Overview

Mendix is a Low Code No Code (LCNC) application development platform primarily used for creating and managing web and mobile applications. Mendix applications are Model-driven, cloud-native, and the platform provides rich integrations.

Checklist

  • Sensitive Data in Client Constants Exposed
  • Demo Users in Use
  • Default Credentials
  • Vulnerabilities in custom services
  • Insecure Entity Access Control
  • Insecure Microflow/Nanoflow Access Control
  • Insecure Page Access Control
  • Vulnerabilities in Mendix or Modules

mx

Mendix applications ship with a JavaScript client mx that can be used to interact with the application at runtime. The client provides some wrapper functions for HTTP requests and is populated with properties that will prove useful during recon (initial information gathering).

mx The JavaScript mx client can be accessed via browser devtools.

xas

The majority of HTTP calls to the Mendix application backend will be to a specific endpoint at /xas/. The frontend client will POST to /xas/ to perform CRUD operations.

xas

.mda

There are a few different file formats when working with Mendix. The .mda file format is the deployment package that ends up being run by the runtime server. The documentation at Mendix Runtime Deployment provides an excellent overview of the deployment process.

The .mda file format is based off of the zip file format. This can be determined by examining the magic bytes of the deployment package. Within the deployment package you will find all of the necessary files for the application to run. This includes jar files, .mdp, JavaScript, and CSS.

mda Layout of unpacked mda file.

Flows

Microflows and nanoflows are ways to express application logic. The main difference is that microflows run on the server and nanoflows run on the client.

Application Security

The “App Security” “Security Level” dictates many of the security settings within the Mendix application. For example, “Off” means that “No security is applied; users do not have to sign in and can access everything.”

appsec

Some of the security settings that can be defined within the Application Security Security Level are anonymous users, demo users, and user roles.

appsecprod

Without further ado, we’ll start getting into the security vulnerabilities associated with Mendix applications.

Note: For all of the examples, we will assume that anonymous users are enabled or that the user has already authenticated to the Mendix application and thus can access the mx client in the browser.

Sensitive Data in Client Constants

Overview

Constants are used to define static configuration values. When creating the constant, there is an option to expose the constant to the client and ultimately the end user. The Mendix Studio Pro IDE and documentation do warn about putting sensitive data in a constant and exposing it to the client but mistakes happen.

constant

Attack

From the browser frontend, we can leverage the mx client to fetch all the constants and review them for any sensitive values.

mx.session.sessionData.constants

constant

Defense

Do not put sensitive data in the constants and expose them to the client.

Demo Users in Use

Overview

Demo users are created to demonstrate each user role that exists in the application. For example, as an application developer you want to test if the custom user role can perform certain actions or view specific data. Although this is intended functionality of Mendix development, I would argue that leaving this enabled, especially in production environments with sensitive data would qualify as a security vulnerability.

Attack

In this example, the Security Level is set to Production, with Anonymous Users, and demo users enabled. Similarly, if anonymous users is enabled, we can access the mx client and leverage that to fetch the demo users username and passwords. Another way is to use the UI to select the demo user and it will auto-login with that user.

HOST="localhost:8080"
curl -s -X $'POST' \
        -H $'Content-Type: application/json' \
    --data-binary $'{\"action\":\"get_session_data\",\"params\":{}}' \
    "[http://$HOST/xas/](https://$HOST/xas/)" | jq .demoUsers

mx.session.sessionData.demoUsers

demousers

Because of the high visibility of demo users being enabled, it is low likelihood that this is accidentally enabled in a production application. But this could be enabled in internet facing non-production environments which can provide an entry point to the application to search for other vulnerabilities or sensitive data.

Another interesting thing to note is if the “Demo Users” feature was accidentally enabled then later disabled, it does not remove the demo users from the database. So if an attacker was able to store the demo users credentials, they can still manually sign in to the application after the demo users feature was disabled if the accounts were not deleted or passwords rotated.

demousers Demo users are disabled and Anonymous Users is disabled but can still sign in with demo users credentials.

Defense

Disable demo users if not needed. If accidentally exposed demo users credentials, the users should be deleted or passwords rotatated.

Default Credentials

Overview

The default credentials for the Administrator user in Mendix applications is MxAdmin:1. If left unchanged then an attacker can sign in as Administrator to the application.

mxadmin Default credentials setup for new Mendix application.

Attack

Sign in to the application with the username MxAdmin and password “1”.

Defense

Change the default admin credentials.

Vulnerabilities in custom services

Overview

Mendix allows application developers to publish custom services such as REST, OData, and web services (SOAP).

The services can have enabled/disabled Authentication, or choose to expose the service to specific roles as specified in the IDE.

api sec

Attack

The easiest way I’ve found to enumerate all published services is to visit the url /api-doc/

customservices

From there, you can enumerate all of the published services and test for normal API vulnerabilities e.g. BOLA, Injection Attacks, etc.

A contrived example would be command injection. api sec

api rce

Disclaimer again! Only test applications that you are authorized to test! Check and follow all of the security agreements when not testing on your own infrastructure!

Defense

Require authentication for custom services and only allow authorized user roles to consume. Perform all of the other standard API security practices such as input validation, etc. etc. OWASP Top 10 API Security Risks is a good starting point if you’re not familiar.

Insecure Entity Access Control

Overview

“The access rules of an entity define what an end-user is allowed to do with objects of the entity. You can allow end-users with specific roles to do one or more of the following things:

  1. create objects
  2. delete objects
  3. view member values
  4. edit member values

A member is an attribute or an association of an entity.”

For the sake of simplicity, “Insecure Entity Access Control” can mean anytime a user can access (read or write) to an Entity or Attribute that they should not be able to and thus break a security boundary. This can take many forms within Mendix. The example below is a contrived example where a basic user can fetch the entity “AppSecrets” that should only be exposed to admins.

broken access control

The list of accessible entities will be fetched when the mx client gets the session data. sessiondata

The objectType JSON key will hold the name of the Module.Entity which can be retrieved with either the mx client itself, or by mimicking the client’s HTTP calls with the action retrieve_by_xpath.

Attack

// view single entity
mx.data.get({xpath: "//AppModule.AppSecrets", callback: console.info})

retrievebyxpath Retrieving the entities by XPath example HTTP request.

entitywrite Writing to an entity using the mx client.

Defense

Enforce least privileged Access Rules and/or use XPath constraints.

Insecure Microflow/Nanoflow Access Control

Overview

Microflows and nanoflows allow the developer to express the logic of the application in a graphical way. For example, the microflow below takes in a Cmd parameter which gets passed to a Java Action which returns the $CmdOutput string.

microflow

Mendix makes a distinction in nanoflows and microflows. If the flow is doing anything interesting it will have to fetch or send data to the server which both use the same action runtimeOperation in the HTTP request to /xas/. As with any custom code, security vulnerabilities can be introduced.

Attack

Enumeration is a bit more difficult since in the latest Mendix versions, microflow/nanoflow names are obfuscated. The flow name obfuscation does make it more difficult to tell what the flows are doing which forces the tester to rely more on intuition. Having a Burp HTTP History filter for runtimeOperation will show only the requests that are executing flows. microflows

mx.session.sessionData.microflows

microflows

Defense

Only allow authorized users microflow access. microflows

Insecure Page Access Control

Overview

Pages in Mendix are the UI container for an HTML page. Pages could overly expose functionality to unauthorized users if proper access control is not taken.

In the example below, the “Check All” box was checked to allow all user roles access to the admin panel page. Accessing a page does not necessarily mean that the user can interact with all the page elements e.g. a button that triggers a microflow if the underlying microflow does not allow access for that user role. So exposing a page does not override the access control to a microflow.

microflows

Attack

Enumeration of pages on newer Mendix versions require bruteforcing URLs. This can be done with your favorite tool and wordlist such as gobuster. The default endpoint for pages on Mendix 11 is /p/ . microflows

Defense

Apply proper page access control.

Vulnerabilities in Mendix or Modules

Overview

This is not Mendix specific, but exploiting already known vulnerabilities is part of a thorough security test.

Attack

Search for the vulnerabilities in the Mendix runtime or module version at the Mendix security advisories page: Mendix Security Advisories

Defense

Patch.