[Openstack-security] [gmurphy at redhat.com: Re: Why are we still seeing XSS flaws?]

Grant Murphy gmurphy at redhat.com
Thu Aug 14 06:23:05 UTC 2014


Might help if I included the list on my reply..

----- Forwarded message from Grant Murphy <gmurphy at redhat.com> -----

Date: Thu, 14 Aug 2014 16:18:50 +1000
From: Grant Murphy <gmurphy at redhat.com>
To: Paul McMillan <paul.mcmillan at nebula.com>
Subject: Re: [Openstack-security]  Why are we still seeing XSS flaws?
User-Agent: Mutt/1.5.23 (2014-03-12)

Hi Paul,

Thanks for a brilliant response. After spending a bit of time today
combing through the horizon code base I have to say you've hit the nail on
the head there. I put some of my notes up on an etherpad [1], they basically
backup the exact scenario you've described.

I'll raise this issue again at tonights OSSG meeting. I agree that in order
to fix this there will need to be an architectural overhaul. In the meantime
we can probably do a couple of things to try and drive down the technical
debt. Perhaps introducing some openstack-hacking rules that flag the types
of issues outlined in [1]?

1. https://etherpad.openstack.org/p/dashboard_xss_analysis

- Grant.


On Tue, Aug 12, 2014 at 08:30:02PM +0000, Paul McMillan wrote:
> Horizon uses the Django framework, which provides good escaping. The problem is, as Horizon has grown and changed, many contributors have been interested in solving their localized problem as fast as possible, which means that output sanitization has largely turned into an adhoc mismash of bandaids to fix each security issue as it is reported. At present, it is nearly impossible to reason about the safety of any particular string which gets rendered out, and so new bugs get added regularly as inexpert contributors follow existing code without understanding the underlying reasoning.
> 
> The fundamental issue here is that Horizon has mixed HTML into the codebase, rather than keeping it all at the templating layer. This means that it's passing around strings which have been marked safe when they should not be, and the default response from new developers is "I don't know why I'm seeing escape codes, I'll just mark this as safe". We can fix the underlying issues by removing HTML generation from the code, and moving everything back to the template rendering system as it should have been in the first place. Once we've done this, we can add an automated test which rejects any patch which includes a call to mark_safe(), or similar techniques.
> 
> I'm familiar with the horizon code, I'm familiar with how to do it right (I'm a member of the Django security team). I've had conversations with Horizon contributors, conversations in patches, and conversations on many of these XSS bug tickets, about how to fix the problem at the architectural level. Unfortunately, I'm not able to undertake the fairly large architectural project to fix this all by myself. I'm happy to sit down (preferably in person) with Horizon contributors who explicitly have time to do the work, and carefully work through what needs to be fixed. I'm not willing to write a report detailing exactly where things are wrong, which will then be ignored because fixing architectural flaws is lower priority than all other dev work.
> 
> This seems like it might  be a good thing to plan to do for several days at a summit, but we'd need buyin from several people qualified to undertake the work. I think if we had several devs who know the horizon codebase, and a commitment to 2 or 3 days of focused hacking, we could fix the flow of this type of bug nearly permanently.
> 
> It's time to stop the bandaids.
> 
> -Paul
> 
> On Mon, Aug 4, 2014 at 10:44 PM, Grant Murphy <gmurphy at redhat.com> wrote:
> 
> > Hi,
> >
> > I've been trying to put together some historical information about the
> > security vulnerabilities that we are seeing in OpenStack [1]. The one thing
> > that I've noticed is that we don't seem to be learning from our mistakes.
> >
> > The particular example that I'd like to call out is XSS.  This is a
> > very well known problem with a simple solution. Most template
> > frameworks when used correctly will automatically escape input unless
> > autoescape is explicitly disabled. So why are we still seeing this class of
> > bug turn up in 2014?
> >
> > I'd like to propose that the OSSG does a review of horizon's current
> > strategy for mitigating this type of flaw and find a better way forward
> > for future releases. Is anybody able to help out with this?
> >
> > [1] http://openstack-security.info  (#wip)
> >
> > --
> > Grant
> >
> >
> > _______________________________________________
> > Openstack-security mailing list
> > Openstack-security at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> >
> >
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

-- 
Grant Murphy / Red Hat Product Security




----- End forwarded message -----

-- 
Grant Murphy / Red Hat Product Security

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140814/d6727d37/attachment.sig>


More information about the Openstack-security mailing list