TSU-07: Insecure custom authentication
TSU-07 concerns security issues that arise from custom-built authentication in Mendix applications. Mendix provides standard authentication using a username/password combination and sessions. In practice, this is often not sufficient. Applications may, for example, require additional forms of authentication, such as:
- Single Sign-On (SSO)
- authentication via external systems without a username/password
- additional security measures such as multi-factor authentication (MFA)
Incorrectly configured custom authentication? These are the consequences
- the “Custom” option for published integrations
- replacing the standard LoginAction listener
- Java code in custom request handlers
- additional authentication logic in microflows
Authentication is complex. If this custom authentication is implemented incorrectly, it can lead to unauthorized access to the application, integrations, or request handlers. The security of a mechanism (such as JWT or SAML) strongly depends on:
- a correct implementation of the mechanism and the algorithms used
- proper use of the mechanism
- secure configuration and generation of secrets
The more customization is required in these areas, the greater the risk of errors and, therefore, of security vulnerabilities.
Best practices for safe custom authentication in Mendix
When adding custom authentication to a Mendix application, it is important to limit custom development as much as possible. Where customization is required, you must thoroughly understand and apply the best practices of the chosen mechanism.
The following guidelines help with that:1. Choose standards, not custom-built solutions
- Do not design your own authentication protocols
Prefer a standardized mechanism that is well-researched and fits the functional and security requirements of your application - Do not build your own implementations of existing standards
Use existing, well-maintained, and well-tested solutions, for example via a Marketplace module or a standard Java library
2. Correctly modifying the login process
- When modifying the login process:
- ensure that all authentication steps are completed before a user session is created
- implement authentication without an active Mendix session or within an anonymous session
- do not perform authentication in a navigation microflow
- ensure that modified login behavior cannot be bypassed via the standard Mendix login. To achieve this, replace the standard LoginAction listener with a version that enforces the desired behavior.
3. Secure use of claims-based authentication (JWT, SAML)
- For claims-based authentication (such as JWT or SAML):
- validate all relevant claims, not just the identity (such as expiration, issuer, audience, etc.)
- use only claims for user mapping that cannot be modified by the user
- ensure that digital signatures are always required, correctly validated, and that any validation error always results in failed authentication
4. Protection against brute-force attacks
- implement detection and protection against brute-force attempts, for example temporary account lockouts.
5. Secure management of secrets
For authentication based on secrets (such as encryption keys, signing keys, or API keys):
- use cryptographically strong and sufficiently long keys
- do not use human-generated secrets
- ensure that secrets are unique per environment (dev, test, acceptance, production)
Vulnerabilities within TSU-07
- Bypassing MFA because a session is already active before MFA validation
- Bypassing MFA via built-in Mendix authentication
- Missing brute-force protection during OTP validation
- Missing brute-force protection for custom passwords
- Authentication bypass due to missing validation of digital signatures
- Authentication bypass due to missing protection against replay attacks
- Authentication bypass due to missing claim validation
- Identity spoofing through the use of modifiable identity claims
- Authentication bypass due to insecure generation of secrets