AuraQ has vast experience helping organisations find the gaps that can be filled to enhance their business. This could be to improve efficiency, integrate legacy systems or deliver new portals and strategic applications to create competitive advantage. Contact us to request a free, no obligation Gap Analysis.
21st Mar 2017
Protecting Mendix
In today’s connected society, developing software always comes with a risk. Someone else online could directly interact with what you have written and amend it for their own malicious reasons. In the past decade security within systems has become an essential industry that coincides with the development of any product that is to be published online, and utilising a development tool like Mendix comes with the merit that the necessary parts of security have already been handled.
Mendix Security
Mendix looks after your web applications by implementing the security at the core of their Mendix Business Server, and even if the deployment is on premise, the same architecture is used:
- A UI layer is implemented in the Mendix Client as JavaScript libraries running in the browser.
- Alongside this there are logic and data layers implemented into the Mendix Business Server, which is built in Java.
In the Mendix Client (UI layer), there are measures against JavaScript-based threats such as Cross Site scripting (XSS). This type of security vulnerability is found in web applications and enables attackers to inject scripts into web pages viewed by other users, which can then be used to bypass access controls and filter through user’s cookies. This problem needs to be addressed now more than ever as almost every site holds cookies that show your preferences and even passwords. Here is a great example of a reported vulnerability found in google maps that has been patched.
The Mendix Business Server addresses server-side threats such as SQL-Injection and Code Execution, and any requests that are perceived by the system as untrustworthy are detected thus protecting important and often confidential company data.
An SQL Injection (SQLi) refers to an injection attack where the attacker can execute malicious SQL statements that are controlled by the web applications database. If using Mendix, search fields at the top of data-grids could be vulnerable from attacks as users could inject their malicious code into these as the searches are database queries. These days SQLi is easily avoided and databases come with built-in counter-measures. Code execution is the ability to access someone else’s computing device and run their own malicious code by taking advantage of any flaws that may be in their system. In order to avoid security problems these holes would need to be patched very quickly.
These particular aspects of technical security do not need to be worried about when using Mendix as the platform itself foresees and handles any potential problems, however developers should still take into account the application level security. This should be defined by a developer, alongside system module level security, in the business modeller before the application can even be run in a production environment. There are three levels of security that a developer can use when implementing their product, these being:
- Off- this allows the developer to run the application locally without having to worry about security, and the built in users can see all pages and run microflows without any problems.
- Prototype/demo- here security is applied to signing in, forms and microflows and users can still access all data.
- Production- everything that is relevant will need its security to be set, and this is also used on specific module/application roles.
Figure 1. Application project security.
User Roles
An administrator assigns roles to end users of the application, and these roles are then defined at an application level by the developers. The user will get all the access rules specified in their role, and it is also possible to assign manager rights to a role so that users with this role can then manage other users. User roles are given module roles that define a role on a per-module level (e.g. normal user, approver, senior approver), which means that user roles with certain module roles will have all the rights that the module role specifies.
Module Roles
Module roles work slightly differently to user roles in that they actually define what the user can do on a page/microflow basis, as well as being kept within the module so that it can be published with these roles on the app store. The module logic is separate from the application logic, which allows for easy maintenance and validation of security settings:
- Pages/UI- this defines which users can access each page, and ties in with what navigation items the user will see along with whether buttons in a form redirect them to another page (which they will also need to have access to).
- Microflows/Logic: similar to pages/UI, this defines which microflows the user has access to. All microflows that can be accessed by the user have to have their security granted to them, but if you make SUB microflows that are used inside these module-role defined microflows, they inherit the given security so that it doesn’t have to be selected twice.
- Entity Access- on a module rule basis, this role can be given certain access into the entities.
Figure 2 shows some roles and their entity access rights. The ‘TimeManager’ role can see all the timesheets with the given statuses (as defined in an XPath), but not to the lesser statuses such as a ‘New_Timesheet’ created by a normal user:
Figure 2. Entity access by status of a timesheet
Furthermore, the rules are additive, meaning a user role can be given several module roles and they would all apply. This is one way of defining a user; by separating the module roles and then assigning them to users depending on what access is relevant to them.
Finally, determining which users can see which buttons can be defined in almost every widget’s settings. Each widget should have a ‘Visible For’ value that can then be defined by an entities role, for further security on a form basis.
Related Blogs
Drag