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

[Jakub Narebski <jnareb@gmail.com>]

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 and 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.

-- 
Jakub Narebski
Poland