We have performed a penetration test and the following was the outcome:
Test result
We noticed that there are .xml and .gz files available on the web server. The files contain sensitive information about the design and configuration of the application frontend. This could lead to an attacker gaining unauthorized access to this information and performing targeted phishing attacks against application users.
The files that can be viewed are both archive (gz) and regular (xml) files regarding the pages of the application. For example;
http:// ... (app-url) ... /pages/nl_NL/Administration/Account_New.page.xml.gz and
http:// ... (app-url) ... /pages/nl_NL/Administration/Account_New.page.xml
This goes for all other pages in the application, regardless of whether a user has access to them or not (even anonymous users have access to them).
When contacting the servicesdesk we got the following answer:
These pages are served as static content and as such accessible by anyone that can access the web server. Assuming (this would need to be investigated) it could be done through the application server instead, so the static pages are no longer needed and no longer accessible, this would mean a fundamental change in how pages are served and as such we would classify this as a feature request.
Herewith I would like to request a feature request regarding the solution suggested by the servicedesk
Update from Mendix support:
We are aware that some static files are publicly accessible for Mendix applications. This is needed to make your Mendix application work correctly, even before signing in, specifically offline applications. These files do not contain any sensitive data by default. A user will still need a valid session to use any of the information obtained. This means that any metadata information you get from the static files is still restricted by the security model as defined in Studio Pro. E.g. entities are still only accessible by those users that have a valid session with a user role that is defined (in Studio Pro) to have entity access to the entity. The same applies to access rights for microflows, pages, and so forth.
After discussion within Mendix with our R&D and Security departments, we currently classify this as a medium risk issue. It is on our product roadmap to implement this in a more secure way in a future version of Mendix. This means that in the supported Mendix versions the current implementation will remain in place.
Is this issue fixed in mendix 7 version ? Anyone have any update
This specific security risk was also found in our project's penetration test.
Can you give an update when this will be put on the roadmap Danny Roest?
Hi Danny,
We have taken the application down due to this security issue.
Can you provide us with any kind of progress on the subject?
Thanks.
Tim
Hi Tim
Unfortunatly I cannot give you the exact details how it is implemented because this has to be researched, is dependent on other things and too far in the future to know exactly. What I can tell you is that the metadata of the pages (now page xml, in the new future something similar) will not be publicly available and the access will be checked for the right authorization.
As this is part of the longer term roadmap item I cannot give a (rough) date, because it will be too uncertain and can change.
Danny,
I ask you specifically for the exact details of the change and a rough implementation date.
Please provide us insight.
Tim
Hi Tim,
We are currently working on improving our client fundamentally and moving to ReactJS. With this approach, the current page XMLs will be replaced by a new (React like) mechanism. When doing this, the plan is to take subject into account and secure the non public page definitions. Regarding a timeline, I cannot give an exact one as this is a large project. I will not be there within a couple of months.
I hope this answers your questions.
Our answer to this pen test finding is the following currently:
These xml pages are served as static content and as such accessible by anyone that can access the web server. Assuming (this would need to be investigated) it could be done through the application server instead, so the static pages are no longer needed and no longer accessible, this would mean a fundamental change in how pages are served and as such we would classify this as a feature request. This is currently not on our product roadmap as we do not consider this a security risk, because of the following reasons:
- to access the pages you would need to guess the page names correctly. This is far from trivial to do.
- even if you manage to guess the page names correctly. The only real breach is learning the names of entities, attributes and user roles. You still won't have access to any actual data or logic without a valid session and the associated user role and security rights (the user role controls page access, microflow access, OData access and entity access). So if you have configured the security model properly, the tools for which are provided out-of-the-box by the Mendix Business Modeler, there is no real security risk in being able to access some model metadata.
- the developer can already obfuscate all metadata by changing the names of pages, entities, attributes, user roles and so forth to something unintelligible. In your example you could rename the page Account_New to "ABCDEFGH" for example.
Danny, can you provide any insight in when it will be implemented?
So far this is a blocking issue for the go-live of our application. Will it be there in 1 week, month or in 1 year?
Thanks.
Tim
Thank you for responding. Two questions:
1) What exactely are you going to change?
2) When will it be implemented approximately?
The page xml's do not expose data, so no customer data for example is exposed. However, details of the application are exposed. We are working on improving the client one of the things that will change are the page xml's.
I will put this feature on the roadmap.