Question

Security prevent MIME attacks

0

From a pen test we got feedback that we should add an additional header in the index file to prevent MIME attacks. For more info see here Is there anyone who knows if this wil have side effects on mendix?

asked 2016-10-03

Ralph Lenssen

2 answers

2

In my opinion this would only be a risk if your application allowed uploading of filedocuments by anonymous users. I do not think that there are much of those Mendix applications. The risk of the mime attack is that somebody uploads a malicious document that other Mendix users then download and thus get their system infected. Since all the filedocument uploading is tracable in the Mendix application (unless anonymous users can do this) I do not think this a risk.

Regards,

Ronald

answered 2016-10-04

Ronald Catersels

Jasper van der Hoek · Accepted Answer · 2016-10-04

I just ran a few test, but it seemed that due to the design of the platform it didn't seem vulnerable to this attack anyway.

A few moments ago on a local app I tried uploading an html/javascript page as image but I was unable to find any way to get this page to execute through mime sniffing, no matter what I tried.
Recent version of Chrome and Firefox don't allow for Mime sniffing anymore, only in IE I was able to enable this (local LAN enables this by default, on internet it is disabled). But it never executed my html, I showed the txt but never executed anything.

I could find two potential cases for Mime sniffing to be a problem, if users can execute an uploaded file through the browser (executing asp/php/java/.net files on the server). In Mendix this isn't possible since uploaded files aren't accessible through regular http requests. Only though the Mendix api you can download or view a file.
Alternatively if no mime type is specified while rendering it in a browser tab older browsers would use mime sniffing to determine how to render the file. However when the platform can't determine the mime type (for example no extension) it instructed the browser to do a download rather than showing it in the browser.

My quick conclusion would be that this isn't an issue with Mendix (6.2), but I can also understand that security audits & pen-tests just want to check all boxes to prevent any problems.
Even if it's just to check this of the list, our R&D team could look into adding this header (please enter a ticket for our R&D team to do so). On premise you could add this header through your webserver.
But it could be a good idea for our R&D team to add this in the platform as a standard header.

Additionally it is like Ronald mentions, this is only a big concern if anonymous users can upload publicly available documents (and download each other uploads). Otherwise you are doing this to prevent your users to effect each other, and you'll always be able to identify the user who upload the document through the entity info (owner/changedBy).