Open Stack

Hi,

I was initially going to file this on https://bugs.launchpad.net/ossn/ as a
bug, but its not a exploitable vulnerability and more a defence in depth /
increase security posture recommendation for Horizon I thought the list
would be best place to spark initial discussion, its also very similar in
nature to the HSTS header issue https://bugs.launchpad.net/ossn/+bug/1191050 ,
but probably a lot more work to implement :-(

Although Horizon does a very good job of escaping user input and does not
have a track record of Cross-Site Scripting vulnerabilities, its security
posture could be increased long term by the use of the
Content-Security-Policy header. This would protect against any new
functionality tat falls short of current XSS filtering, and also framework
and middleware vulns that Horizon doesn't really have control over. Its use
when configured correctly pretty much eradicates XSS bugs (along with some
other cross-site includes) and is a huge step forward in client-side
browser security.

If your not familiar with the CSP header and how it works, it basically
prevents inline JavaScript, and has fine grain control regarding where
client-side script is loaded from.

The reason I said in the first paragraph that its probably a lot more work
is that the web application needs to move any JavaScript it uses into .js
files and include those from within the HTML, so something that was
originally[1]:

<script>
  function doAmazingThings() {
    alert('YOU AM AMAZING!');
  }</script> <button onclick='doAmazingThings();'>Am I amazing?</button>

Becomes:

<!-- amazing.html --><script src='amazing.js'></script><button
id='amazing'>Am I amazing?</button>

// amazing.jsfunction doAmazingThings() {
  alert('YOU AM AMAZING!');}
document.addEventListener('DOMContentReady', function () {
  document.getElementById('amazing')
          .addEventListener('click', doAmazingThings);});


Once you have moved all your JS out of the HTML and into .js files, you can
set the CSP header to only load script from your domain:

Content-Security-Policy: default-src 'none'; script-src
https://horizon.mycloud.net;


So with that set, even if you had a parameter vulnerable to reflected XSS
as follows:

https://horizon.mycloud.net/login/user=admin<script>alert('i am stealing
your session token')</script>

It wouldn't get executed - demonstrating the excellent defence in depth.

Finally, as the CSP may be organisation specific, it may be best to allow
the exact policy to be configureable and a note in the security guide, but
for this even to be a possibility the JavaScript needs to be cleaned up and
moved out :-(

Heres a few posts on how twitter have gone about it:

https://blog.twitter.com/2011/improving-browser-security-csp
https://blog.twitter.com/2013/csp-to-the-rescue-leveraging-the-browser-for-security

I'm happy to provide more help, test and work with anyone if this moves
forward, and Hi, I'm Myles :-)

[1] Example taken from
http://www.html5rocks.com/en/tutorials/security/content-security-policy/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131107/efccac44/attachment.html>