On Premise security

1
Hi   We are setting up an on premise Mendix app for the first time, we have gone through the steps on this link to configure IIS https://docs.mendix.com/howto50/deploying-mendix-on-microsoft-windows The site is all working fine but when going through the security checklist https://docs.mendix.com/howto50/security-checklist-for-your-on-premises-installation there are 2 points which we are unsure about, " Use a HTTP reverse proxy with SSL support Configure a reverse proxy (e.g. Nginx or IIS or Apache) as close to the application process as possible, that implements SSL on the http connection, so your end users who are using a web browser will connect to the application via the reverse proxy, using a https:// url. Make sure correct certificates matching the url used are in place, either recognized by Certificate Authorities present in modern web browsers, or by an internal Certificate Authority of your company, which has been distributed to the web browsers of all your users. On the reverse proxy, which acts as SSL termination point, insert the HTTP header ‘X-Forwarded-Scheme’, with a value set to ‘https’ into requests that are sent to the Mendix application. This will communicate to the Mendix Runtime that the end user is using the application over https, and will set the ‘secure’ flag on session cookies. When the secure flag on session cookies is notset, browsers will also send the cookie when trying to connect over a normal http connection. So, when secure is not set on the cookies, also when only implementing a redirect tohttps on the normal http port, session-cookies will be sent in the clear over the network! The X-Forwarded-Scheme request header has to be inserted at the reverse proxy because it is the only way that the Mendix Runtime will detect the use of https automatically. Use a HTTP reverse proxy with SSL support Configure a reverse proxy (e.g. Nginx or IIS or Apache) as close to the application process as possible, that implements SSL on the http connection, so your end users who are using a web browser will connect to the application via the reverse proxy, using a https:// url. Make sure correct certificates matching the url used are in place, either recognized by Certificate Authorities present in modern web browsers, or by an internal Certificate Authority of your company, which has been distributed to the web browsers of all your users. On the reverse proxy, which acts as SSL termination point, insert the HTTP header ‘X-Forwarded-Scheme’, with a value set to ‘https’ into requests that are sent to the Mendix application. This will communicate to the Mendix Runtime that the end user is using the application over https, and will set the ‘secure’ flag on session cookies. When the secure flag on session cookies is notset, browsers will also send the cookie when trying to connect over a normal http connection. So, when secure is not set on the cookies, also when only implementing a redirect tohttps on the normal http port, session-cookies will be sent in the clear over the network! The X-Forwarded-Scheme request header has to be inserted at the reverse proxy because it is the only way that the Mendix Runtime will detect the use of https automatically."   The first paragraph seems to be covered by us deploying the site through IIS successfully but I can't find any info about how to insert the X-Forwarded-Scheme header, where should that be done and how can we test to ensure it is working?   The second point on the security checklist we are struggling to understand is "Let the HTTP reverse proxy serve static content Highly recommended: Configure the reverse proxy to directly serve static content from the ‘web’ directory on the root location of the application url and the Mendix client system (located in the correct version to be used of the Mendix runtime distribution installed) on /mxclientsystem. The application process itself should only handle dynamic content (like the /xas/ and /ws/ sub-urls)." Could we have a clearer explanation of what needs to be done and how to do it?   Thanks    
asked
2 answers
3

Hi Paul,

I'll do my best with your questions, though I am not an expert with IIS:

1) X-Forwarded-Scheme

Setting it up:

I found this how-to article on setting http headers in IIS. Based on that, I think this is what you need to do:

  • In the configuration for your URL Rewrite rules, find the section called "Server Variables"
  • Add the variable 'HTTP_X_FORWARDED_SCHEME' and set its value to 'https'
  • IIS will convert the server variable 'HTTP_X_FORWARDED_SCHEME' into an http header: 'x-forwarded-scheme'

 

NOTE: I don't have access to IIS at the moment to try this myself. Please let me know if it works so I can get the documentation updated accordingly

Making sure it's working:

  • Bring your app online
  • Navigate to it over HTTPS
  • Log in
  • Check the session cookies in your browser to ensure they have the "secure" flag enabled

Here's a StackOverflow discussion on that last part.

2) Let the HTTP reverse proxy serve static content

Since we only create rewrite rules for the dynamic content requests that must go to the Mendix runtime, the static content is already served by IIS.

answered
0

Hi, thanks, I've now managed to check the cookies secure flag is being set using the Chrome developer tools ater adding the settings in IIS so it looks like it is now set up ok and working.

The original IIS set up documentation only created URL rewrite rules for the site which is where I was trying to add the server variables, but I needed a URL rewrite to be set up for the server. Once the server variables for HTTP_X_FORWARDED_SCHEME were added to the server level rewrite rule I saw the change in the cookies.

Thanks

answered