Re: Implementing CSP (Content Security Policy) for gitweb in the future

From: Matt McCutchen <matt@mattmccutchen.net>
Date: Jun 5, 2011, 16:46 UTC
Message-ID: <1307292370.23564.10.camel@localhost>
In-Reply-To: <201106051533.51735.jnareb@gmail.com>

On Sun, 2011-06-05 at 15:33 +0200, Jakub Narebski wrote:

Show 25 quoted lines

> On Sun, 5 July 2011, Matt McCutchen wrote:
> > On Sun, 2011-06-05 at 11:03 +0200, Jakub Narebski wrote:
> 
> > > In the future however it might be better solution for gitweb to implement
> > > (as an option) support for CSP (Content Security Policy), which IIRC did
> > > not exists in 2009, in addition to current $prevent_xss.
> > 
> > Sure.  CSP is not a substitute for designing to prevent harmful HTML
> > injection, but a mitigation for some of its worst effects in case some
> > injection points are overlooked.  There's no reason not to enable it by
> > default with $prevent_xss, though third parties adding functionality to
> > gitweb would need to know to disable it or modify the policy
> > accordingly.
> 
> I propose CSP support _in addition to_ and not replacing $prevent_xss
> (which would be nice to have more fine-grained control over).
> 
> Well, while we can whitelist HTML fragment from README.html, or render
> README.md / README.rs / README.pod etc. instead of blocking it like gitweb
> currently does if $prevent_xss is enabled, I don't think it would be
> feasible to do the same for text/html 'blob_plain' pages. 
> 
> Serving HTML pages etc. from 'blob_plain' view with path_info links
> is quite useful feature; this way one can use gitweb as a cheap and easy
> way to deploy web pages

Yes.

> and web apps;

Probably not: the browser features needed to make a nontrivial web app are probably the same ones that are dangerous to other web apps.

> or just test results of development.
> CSP would serve this purpose well; current $prevent_xss behavior of
> serving as attachment (forcing download), or serving them as text/plain
> as e.g. GitHub does simply remove this feature.

CSP is not intended to be used by itself as a sandbox, although it might almost work for the purpose. It would be more appropriate to set up a wildcard virtual host and appropriate rewrite rules to expose each repository at a different DNS name and take advantage of the usual same-origin policy.

-- 
Matt