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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Aug 9 10:56:01 PDT 2016


--- 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>

More information about the webkit-unassigned mailing list