[Webkit-unassigned] [Bug 155432] REGRESSION (r197724): [GTK] Web Inspector: Images being blocked by CSP 2.0

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=155432

--- Comment #9 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #8)
> (In reply to comment #7)
> > > View in context:
> > > https://bugs.webkit.org/attachment.cgi?id=273962&action=review
> > > 
> > > > Source/WebCore/ChangeLog:8
> > > > +        The GTK+ port Web Inspector uses GResources for all internal
> > > 
> > > Is this only necessary for the Web Inspector? If so, how did you come to the
> > > decision to allow the interpretation of source * for resource URLs for
> > > images and audio/video sub resources on all web pages as opposed to
> > > modifying the img-src and media-src directives in the Web Inspector's CSP
> > > policy to allow GResources.
> > 
> > Because GResources are like a data URL in practice, so if we allow data URLs
> > I don't see why not allowing GResources. They are always safe, so I don't
> > think they should be blocked in any case.
> > 
> 
> Unless we know that there are popular web sites that make use of resource
> URLs and define a CSP that depends on * allowing such URLs then we should
> revert <http://trac.webkit.org/changeset/198201> and take a similar approach
> as in the fix for bug 155182 to add resource: to the image-src and media-src
> directives in the CSP policy for the Web Inspector.

No there isn't any website using resource URLs, because GResources are something internal to the application in the client side. We use GResources inside WebKit itself to compile all the resources (inspector files, but also webcire icons) in the shared library. That way we don't need to install the resources and find them in the file system at runtime, they are always available to any application linking to the library. GTK+ applications also compile their own GResources in their injected bundle library to make their own resources available to the web process. It's typically used for user scripts, custom error pages, about: pages, etc. So, GResources shouldn't be affected by the CSP at all, because they are never used by websites, but by applications as an implementation detail.

> Additional remarks:
> 
> We should not be making a exception for resource URLs in
> ContentSecurityPolicySourceList::isProtocolAllowedByStar(). Source * should
> be interpreted as strictly as possible so as to more closely match (2) of
> section Matching Source Expressions of the Content Security Policy Level 2
> spec. [1] and avoid surprising web developers. Following from the spec. we
> do not want * to match data URLs. As mentioned in the ChangeLog description
> for changeset 197724,<http://trac.webkit.org/changeset/197724>, I chose to
> make an exception for the image-src and media-src directives and allow data
> URLs to mitigate web compatibility issues (see remark [2]).
> 
> [1] <https://www.w3.org/TR/2015/CR-CSP2-20150721/#match-source-expression>
> [2] This decision was influenced in part by Mozilla's experience in
> restricting the interpretation of source * as remarked in bug 154122,
> comment 2.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160317/a4f7c32b/attachment.html>