Implement Best Practices for App Security

1 Introduction

Security is one of the most important aspects of an application, because misconfiguration or failing security can have large stakeholder consequences. The Mendix Runtime protects your application and data according to your model, and the Mendix Cloud handles security at the infrastructure level.

This document describes the common aspects you should consider when delivering an application within the Mendix Cloud.

2 Implementing Access Rules

The Mendix architecture includes the Mendix Client, which can compose its own queries (generated by widgets) and send them to the Mendix Runtime. If the Mendix Runtime were to execute these queries without touching them, the Mendix Client would be able to request data that the user should not be allowed to see.

When designing an application, a developer can specify access rules on an entity (for more information, see How to Create A Secure App). These access rules are applied whenever a query (received from a client) should be executed, thus they constrain the data returned to the client. For example, users with the “Customer” role can only view orders that are associated to the customer of which this user is part.

While the data that should be viewable and editable in which role is application-specific, the following best practices are key:

• Attributes determined by the system (like the status of an order) should never be writeable
• If an anonymous user is allowed to create objects, constrain these objects to the owner (an anonymous user is actually a System.User object created on the fly)
• Do not set a default rule for read-and-write access – this forces you to think about each attribute that is added to an entity
• Security constraints should be formed as entity access rules and visibility constraints in page components (grids, list views, data views)
• Keep your attributes editable within data views, because if an access rule prohibits write access, your client will display it as non-editable – this way you are aware of the (correct) working of an access rule

3 Avoiding Injection

Injection occurs when (user) input can be misused to influence the behavior of a system. Common cases are parameters for queries (to influence the results of database queries) or HTML with JavaScript contents (to influence browser behavior).

When using Mendix-native components, there are no concerns about the possibility of injection. Queries (like XPath) are parametrized and therefore always escaped, making SQL-injection impossible. For the other way around, retrieved data shown in the user interface is escaped to the HTML format.

When you are building an application, you may use Mendix Marketplace components and external interfaces. Remember that variables—whose value originates from user input or other systems—should be escaped to avoid injection (and for the proper display).

These are the common cases and best practices:

• HTML content, usually derived from an HTML editor and displayed using an HTML viewer, format string, or an email client – these are the ways to avoid this abuse:
  • Use the XSSSanitize action from the Community Commons Function Library module to strip malicious code from the entered HTML
  • Display the value of an attribute as HTML or using the HTMLEncode function from the Community Commons Function Library module
• Database connections (for example, using the Database Connector), where user input is being used within constraints – these are the ways to avoid this abuse:
  • Use prepared statements, which will cause the database-specific connector to take care of escaping the value
  • Sanity-check your user input (for example, use a regular expression to check if your user input only contains alphanumeric characters, spaces, and dashes)

4 Applying Access Restrictions to Unnecessary Request Handlers

A Mendix app offers various endpoints that can be used to obtain information about offered services. The paths used by these endpoints end in -doc. By default, access to these endpoints is disabled when deploying to a cloud node.

Access restrictions can be configured within the Developer Portal. They can be found in the Environment details of your cloud node. This is an example of this overview showing the default settings after deploying to a new environment:

Examples are the ws-doc or rest-doc endpoints that enumerate all the published web and REST services of the application. An attacker could use this information to discover possible areas to exploit.

You can take the following preventative measures:

• Disable unused endpoints within the Mendix Developer Portal completely by applying a deny all access preset on them
• Apply IP filtering or client certificate authentication to restrict access

Keep the following in mind:

• If there are other app-specific request handlers that should have an access restriction applied, then click New to add them as additional paths
• The URLs of test and acceptance environments can easily be guessed; in order to take effective measures, the restrictions should be applied to these environments also

5 Applying Authentication on Services

When publishing a web or REST service, you should consider whether this service should be consumable by everybody (anonymous) or by a limited set of users or systems. Whenever a limited set of users should be allowed, a Mendix (web service) user should be created for each consumer of this service. The option of creating (fine-grained instead of generic) users enables an application to do the following:

• Identify which user caused a change in your application (traceability)
• Constrain access on the user (role) level
• Log the usage of your service

Mendix offers the following options for providing authentication for your services:

• User name and password validation, specified within the Mendix Modeler (for details, see Published Web Services)
• Client certificates and IP ranges, which are specified in the Mendix Cloud – these can be found at the network tab of your node’s environment details as Access Restriction Profiles

6 Using the Encryption Module When Storing Sensitive Information

Your application might require sensitive information that should be extra encrypted. These are some examples:

• Connection information for consumed services (like credentials, service locations, or keys)
• Personal information (like bank account numbers or social security numbers)

This data is defined within the domain model and stored within the database of your application. To minimize the impact of this information when it is leaked, Mendix recommends storing this data in a (symmetric) encrypted manner. The Encryption module available from the Mendix Marketplace provides a way to encrypt this sensitive information in a database record based on an encryption key that is stored at the Mendix application server.

7 Using a Third-Party Identity Provider

When developing an application, authentication is one of the basic considerations. Even though Mendix comes with a basic authentication mechanism, your application’s security is improved when authentication is delegated to an enterprise grade identity provider like ADFS.

Mendix offers the SAML module that enables your application to be connected with these service.

Your application can gain the following benefits from using an identity provider:

• User management is centralized (for example within Active Directory), which simplifies the on- and off- boarding of new employees or changed roles
• The Mendix app does not contain (hashed) passwords
• Identity providers can add extra layers of security, like two-factor authentication
• Stronger password policies are applied
• The user experience is improved by facilitating single sign-on (SSO)

8 Applying a Strong Password Policy

By default, Mendix forces a strong password policy. The same password policy that is configured in the Mendix Modeler is also used for apps running in a hosted environment (for example, on test, acceptance, and production).

It is very tempting to simplify the password constraints for development purposes (for example, making it possible to use a single character to login). However, Mendix recommends avoiding this approach so that deployments will continue to force a strong password policy.

The password policy can be set by via the guidelines described in Password Policy.

9 Renaming the Administrator User

Each application requires power users who should be able to administer technical functions (like configuring SSO). By default, the user who has these capabilities is called MxAdmin and has the Administrator role.

This information can be exploited by an attacker (for example, by trying to guess the password). Even though Mendix will block the user for about 5 minutes after three unsuccessful login attempts, renaming the default MxAdmin user is recommended.

The user name of the administrator can be changed in the Desktop Modeler’s Project Security settings on the Administrator tab.

When deployed to the Mendix Cloud, the information about the administrator user name and role is taken into account when using the Change admin password button on the environment. After changing the settings in the Desktop Modeler and redeploying the application, a successful admin password change will trigger the creation of a user in the app with the new name and role.

10 Using SSL on Consumed Web Services Whenever Possible

Most apps consume (web) services that could be located within an organization itself or at an external third party. When such a service is consumed by an application, your request crosses multiple networks and devices before it reaches its endpoint (the service). A potential attacker in between would be able to read and manipulate the conversation between the application and the service.

By using an SSL connection and adding the public key of the endpoint within your application, you will ensure the following:

• The conversation between you and the service has not been tampered with
• The conversation is not readable if it was ever intercepted
• The identity of your endpoint is confirmed

There are several scenarios possible for protecting your outgoing connections using encryption. These depend on the infrastructure possibilities and protocols used. For more information, see How to Secure Outgoing Connections from Your App.

You can add individual certificates in your project’s settings in the Desktop Modeler. Test, acceptance, and production environments require their certificates to be uploaded to the Mendix Cloud (for more information, see Certificates).

11 Preventing Your App from Being Embedded in an Iframe

Applications that can be embedded within an iframe can be misused by attackers. By using an overlay, it could trick users into clicking on buttons and make them perform actions within the application on their behalf without knowing it. This approach is called clickjacking.

By sending a header to the user’s browser, it can block the use of the Mendix application within an iframe and avoid this type of attack. The header is set by default to block embedding within an iframe, but can be configured using HTTP Headers in your node’s environment details within the Mendix Developer Portal.

12 Maintaining a High Level of Project Hygiene

As an application grows in functionality, it also increases the chance of containing logic that could be exploitable for an attacker. Also, over time, vulnerabilities within logic can be discovered. Keeping your project hygiene at a high level will reduce the chances of a vulnerable application.

To keep your project hygiene at a good level, perform the following steps:

• Remove unused modules, widgets, and Java libraries
• Remove microflows that are not being used (these appear as warnings in the Modeler)
• Avoid using components with known vulnerabilities (like Java or JavaScript libraries)

A good source of known vulnerabilities is the Common Vulnerabilities and Exposures website.

13 Configuring User Roles and Access

Which users and roles are defined within an application is different per app and project. However, there are some key guidelines to keep in mind when validating the user security:

• Anonymous access should be disabled if it has no function within the application
  • Some applications have anonymous access enabled, solely to serve a custom login form – this can be replaced by modifying the default login.html within your theme (which will also help the user experience with an improved loading time)
• Roles managing other user roles should be as strict as possible (configured via User management within the user role options)
• The role of the app’a administrator user (default MxAdmin) should only be able to create the actual administrative accounts (or configure SSO)