[Webkit-unassigned] [Bug 160656] CSP Wildcard support

[bugzilla-daemon at webkit.org]

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

--- Comment #1 from Daniel Bates <dbates at webkit.org> ---
(In reply to comment #0)
> In regards to "More restrictive wildcard" on:
> 
> https://webkit.org/blog/6830/a-refined-content-security-policy/
> 
> Where you are suggesting allowing "data:" for image and "data:, blob:" for
> media (the heading should really be "less restrictive").
> 

As the blog post explains we are intentionally "less restrictive" with respect to images and media for web compatibility. In general the behavior of * in WebKit is more restrictive than the behavior of * as described in the CSP Level 2 standard, which allows * to match an arbitrary scheme except those in {data:, blob:, and filesystem:}. The table in the blog post describes the matching criterion used by WebKit.

Additional remarks:

At the time this decision was made we observed some popular native apps and popular web sites that assumed * would allow data URLs for images. These observations were consistent with Mozilla's experience of breaking popular sites when they implemented the CSP Level 2 spec.-compliant behavior for * (see bug #154122, comment 2 for more details). It is likely that Mozilla's implementation of * has since changed. We should further investigate. Regardless, we should evaluate whether we can remove the exemptions we have for * to match data: for images, and data: and blob: for media while minimizing compatibility issues. We will need to consider the amount of app/site breakage together with an evangelism effort to get app writers and site owners to explicitly add data: and/or blob: schemes to their CSP policy.

> Please can you follow the spec instead:
> 
> https://www.w3.org/TR/CSP2/#match-source-expression
> 
> "If the source expression a consists of a single U+002A ASTERISK character
> (*), and url’s scheme is not one of blob, data, filesystem, then return does
> match."
> 
> This means is that websites that want to use "data:" for their images just
> add it to their directive (img-src * data:;), whereas websites that really
> don't use "data:" urls, can continue to use a wildcard without worrying
> about images that use this scheme (e.g. a malicious resource, delivered
> inline, which means there is no need to find somewhere to host it).
> 

Notice that this definition allows * to match an arbitrary scheme that is not blob:, data:, or filesystem:. For example, * will match a custom protocol, say app:.

> Keeping in mind that images, like TIFF's, can have buffer overflows ;-)
> 

Obviously there are disadvantages with allowing * to match data: for images, and data: and blob: for media. At the time we made the decision to allow * match these schemes we felt that the risks of a data/blob URL exploiting a image/media decoder bug were less than the web compatibility risks of * not matching these schemes. We should evaluate whether this trade off still makes sense.

> Might be related to Issue 153090.

Can you elaborate?

-- 
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/20160809/77872e52/attachment-0001.html>