HTTP Strict Transport Security not enabled on Horizon Dashboard

Bug #1191050 reported by Joaquin Berrios
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Invalid
Undecided
Unassigned
OpenStack Security Notes
Fix Released
Undecided
Unassigned

Bug Description

Versions: 2012.2

The Horizon Dashboard does not enable HTTP Strict Transport
Security. As a result, browsers can be tricked into making HTTP
connections even if all connections to Horizon should be
protected via TLS. Therefore, web sessions are susceptible to
MitM attacks such as cookie/session stealing.

HTTP Strict Transport Security (HSTS) is a mechanism through which web
hosts can instruct browsers to only connect over SSL/TLS for future
connections. It helps prevent Man-in-the-Middle (MitM) attacks that
attempt to trick victims' browsers into dropping out of SSL/TLS. HSTS
can also help mitigate other weaknesses such as web applications which
omit the secure flag when setting session cookies. HSTS is currently
implemented in Firefox and Chrome, but will ideally be included in
other popular browsers as well.

For more information see
https://www.owasp.org/index.php/HTTP_Strict_Transport_Security

Tags: cwe-420
Jeremy Stanley (fungi)
Changed in ossa:
status: New → Incomplete
Revision history for this message
Jeremy Stanley (fungi) wrote :

I'm inclined to say this is at least public... it seems to me that there's no reasonable expectation by the user that Horizon implements HSTS unless it claims to do so in its documentation. I also think this is more appropriately approached as a security hardening bug rather than a vulnerability in the application.

Revision history for this message
Thierry Carrez (ttx) wrote :

Agreed. I think it would make a nice security feature addition, but that's certainly not an exploitable vulnerability.
Will open publicly and tag as "security" if nobody complains in the next days.

Revision history for this message
Thierry Carrez (ttx) wrote :

Also looks like it can be implemented on Django's side using django-hstsmiddleware. So it could be documented as a deployment option, and potentially an OSSN could be issued to recommend using that in real-life deployments.

Revision history for this message
Thierry Carrez (ttx) wrote :

If nobody objects, I'll consider this a recommended deployment option, make this public and recommend it's documented on a future OSSN.

Revision history for this message
Thierry Carrez (ttx) wrote :

@Joaquin: would that work for you ?

Revision history for this message
Thierry Carrez (ttx) wrote :

@Joaquin: unless we hear from you very soon we'll open this bug publicly and add it to the OSSN queue.

Revision history for this message
Joaquin Berrios (joberrio) wrote :

Hello, sorry for the delayed response. Updating the recommended deployment options seems like a reasonable was to address this. Thanks.

Revision history for this message
Thierry Carrez (ttx) wrote :

Would make a great "recommended Django deploy options for Horizon" OSSN together with bug 1191051

information type: Private Security → Public
no longer affects: ossa
Changed in horizon:
status: New → Invalid
Revision history for this message
Robert Clark (robert-clark) wrote :

Picking this up now. Sorry for the delay.

Revision history for this message
Robert Clark (robert-clark) wrote :

If I recall correctly, django doesn't really do the SSL itself, it offloads to Nginx/Apache or whatever else is sat in front of it.

That being the case, this should be a general OSSN for Horizon configuration - deploy it secure, do it right.... happy with that approach?

Revision history for this message
Robert Clark (robert-clark) wrote :

Further to my previous comment, I don't think this is something that can be fixed in django (I'm no expert) but here's the config changes that would enable HSTS in Apache and Nginx...

APACHE:
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>
Header add Strict-Transport-Security "max-age=15768000"

NGINX:
add_header Strict-Transport-Security max-age=15768000;

I'll go ahead and create an OSSN advising that as Horizon is a high value target we recommend deploying it with HSTS and this is how to do it.

I think I'll also raise a bug against the docs to have this as the default, I can't see why you _wouldn't_ want HSTS if you've already gone to the trouble of enabling SSL - http://docs.openstack.org/trunk/openstack-compute/install/yum/content/installing-openstack-dashboard.html

Does all this seem reasonable?

Changed in ossn:
status: New → In Progress
Revision history for this message
Joaquin Berrios (joberrio) wrote :

It does indeed. Thank you for the feedback.

Revision history for this message
Robert Clark (robert-clark) wrote :

[DRAFT] HTTP Strict Transport Security not enabled on Horizon Dashboard
----

### Summary ###
 Deployers using Horizon for production or internet facing operations should strongly consider configuring HSTS for their deployment

### Affected Services / Software ###
Horizon, SSL, TLS, Apache, Nginx

### Discussion ###
HTTP Strict Transport Security (HSTS) enforces that all communications with a server go over SSL. This mitigates the threat from attacks such as SSL-Strip which replaces links on the wire, stripping away https prefixes and potentially allowing an attacker to view confidential information on the wire.

HSTS can be enabled in Apache and Nginx, the two primary ways of serving Horizon at scale

### Recommended Actions ###
Apache Configuration:
-------------------------
Add this to the relevant vhost:
Header add Strict-Transport-Security "max-age=15768000"

We suggest also using mod_rewrite to ensure all visitors to Horizon land on a secure page
Add this into your main configuration file
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>

Nginx Configuration:
------------------------
add_header Strict-Transport-Security max-age=15768000;

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1191050
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

Revision history for this message
Robert Clark (robert-clark) wrote :

[DRAFT] HTTP Strict Transport Security not enabled on Horizon Dashboard
----

### Summary ###
 Deployers using Horizon for production or internet facing operations should strongly consider configuring HSTS for their deployment

### Affected Services / Software ###
Horizon, SSL, TLS, Apache, Nginx

### Discussion ###
HTTP Strict Transport Security (HSTS) enforces that all communications with a server go over SSL. This mitigates the threat from attacks such as SSL-Strip which replaces links on the wire, stripping away https prefixes and potentially allowing an attacker to view confidential information on the wire.

HSTS can be enabled in Apache and Nginx, the two primary ways of serving Horizon at scale

### Recommended Actions ###
Apache Configuration:
-------------------------
Add this to the relevant vhost:
Header add Strict-Transport-Security "max-age=15768000"

We suggest also using mod_rewrite to ensure all visitors to Horizon land on a secure page
Add this into your main configuration file
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>

Nginx Configuration:
------------------------
add_header Strict-Transport-Security max-age=15768000;

As always, test these configuration settings before deploying them to production in order to catch any bugs etc.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1191050
Documentation Bug : https://bugs.launchpad.net/openstack-manuals/+bug/1210409
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

Revision history for this message
Robert Clark (robert-clark) wrote :

Posted to ML 19-9-13

Changed in ossn:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.