Two minor security fixes: construct secure URLs and mark cookies as secure

[vladimir-mencl-eresearch]

• Define a header to let Apache SSL VirtualHost tell Django session was received over HTTPS - and any redirect URLs should be constructed also as HTTPS
• Mark cookies as secure
• Add the Apache RequestHeader set directive into sample Apache configuration in the documentation
• Put the settings on Django side into settings.py (and not local_settings.py) as these should not need any deployment time customization.

[vladimir-mencl-eresearch]

Hi, FYI, I just found that once I set the Apache header (the change to Apache SSL VirtualHost configuration), Django starts interpreting the request as having arrived over SSL even without setting settings.SECURE_PROXY_SSL_HEADER. But, this behavior of uwsgi is undocumented, so I'd still rather explicitly tell Django which header to look for (the change in settings.py).

Cheers, Vlad

[zmousm]

Good catch. I agree we should enable SESSION_COOKIE_SECURE by default. As for SECURE_PROXY_SSL_HEADER, however, I see two issues:

• As noted in the docs, this should be enabled only when one explicitly acknowledges that Django is behind a proxy (that modifies the request scheme). As we are (still, perhaps unfortunately) suggesting mod_wsgi for deployment, this is not the case by default. Therefore I believe we could include it in settings.py but leave it commented out by default. As for the apache config, I believe that for this directive to make sense, it would be better to include it as part of a section that shows how to proxy the app to uwsgi (or say gunicorn), rather than let mod_wsgi handle it.
• I would prefer that we use the de-facto standard X-Forwarded-Protocol: https.

What do you think? If you agree, would you mind updating the patch accordingly?

[vladimir-mencl-eresearch]

Hi,

Our deployment uses just mod_proxy to pass the requests to uwsgi via HTTP. And we pass the requests from both 443 and 80. And in our case, uwsgi picks up the X-Forwarded-SSL: on header and marks the request as secure, without having to actually configure the header in Django (the Django setting was ment more as a back up). And uwsgi ignores the X-Forwarded-Protocol: https.

But I can work with that - I can set the header in our customized local_settings.py.

So the way forward I see is that I would:

• change the header name to X-Forwarded-Protocol: https
• comment out the header setting at Django side and also move it from settings.py to local_settings.py (because it's now a customizable item).
• change the Apache recommendation to use the header name and take it out of the mod_uwsgi snippet - and add a new section describing mod_proxy as an option.

Does that sound alright to you?

Cheers, Vlad

PS: In our own deployment, I'd then also clear the same header in the plain-http VirtualHost - thanks for the Django link!

[vladimir-mencl-eresearch]

Hi Zenon, would you be happy with this revision?

Cheers, Vlad

[zmousm]

Thanks! I am rebasing this on rewritten master (just to spare you the trouble) and merging it.