On Sun, 2011-06-05 at 15:33 +0200, Jakub Narebski wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html