git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Matt McCutchen <matt@mattmccutchen.net>
Cc: git@vger.kernel.org
Subject: Re: Implementing CSP (Content Security Policy) for gitweb in the future
Date: Wed, 8 Jun 2011 12:27:19 +0200	[thread overview]
Message-ID: <201106081227.19495.jnareb@gmail.com> (raw)
In-Reply-To: <1307292370.23564.10.camel@localhost>

On Sun 5 June 2011 Matt McCutchen wrote:
> 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.

"Deploying" with gitweb doesn't allow for server-side scripting, so it
is "web apps" only as far as there can be web application done entirely
on client-side: HTML or HTML5 + JavaScript.  Well, there is demo of a
game played in HTML5+JavaScript played entirely in URL bar ;-)

With CSP you would be restricted to prerequisites (web page itself,
scripts, stylesheets, images) to be also hosted/deployed via gitweb.

What features would non server-side nontrivial web app need that would
be 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.

Could this virtualhost + DNS + same-origin sandboxing be used for gitweb?
If not, then perhaps it is better solution in other cases, but not for
gitweb.


P.S. I don't know how difficult implementing CSP support for gitweb would
be, given that gitweb is quite configurable wrt. external resources it
uses: $javascript, @stylesheets, various *logo variables...

-- 
Jakub Narebski
Poland

  reply	other threads:[~2011-06-08 10:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-04  8:43 [PATCH] gitweb: Fix usability of $prevent_xss Jakub Narebski
2011-06-04 21:15 ` Prevalence " Matt McCutchen
2011-06-04 21:53   ` Jakub Narebski
2011-06-05  9:03   ` Implementing CSP (Content Security Policy) for gitweb in the future Jakub Narebski
2011-06-05 12:52     ` Matt McCutchen
2011-06-05 13:33       ` Jakub Narebski
2011-06-05 16:46         ` Matt McCutchen
2011-06-08 10:27           ` Jakub Narebski [this message]
2011-06-08 17:31             ` J.H.
2011-06-10 12:01 ` [PATCH] gitweb: Make $prevent_xss protection for 'blob_plain' more usable Jakub Narebski
2011-06-13 16:47   ` Junio C Hamano
2011-06-13 21:49     ` Jakub Narebski
2011-06-13 23:12       ` Junio C Hamano
2011-06-14  1:33         ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201106081227.19495.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=matt@mattmccutchen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).