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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/08/2011 03:27 AM, Jakub Narebski wrote:
> 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...
> 

The long and the short of it is, until browsers other than
Mozilla/Firefox support CSP, it's a dead standard and we shouldn't spend
any time on it.  There are few enough resources on gitweb as it is to be
tilting at windmills.

- John 'Warthog9' Hawley
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]