<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - CSP Wildcard support"
href="https://bugs.webkit.org/show_bug.cgi?id=160656#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - CSP Wildcard support"
href="https://bugs.webkit.org/show_bug.cgi?id=160656">bug 160656</a>
from <span class="vcard"><a class="email" href="mailto:dbates@webkit.org" title="Daniel Bates <dbates@webkit.org>"> <span class="fn">Daniel Bates</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=160656#c0">comment #0</a>)
<span class="quote">> In regards to "More restrictive wildcard" on:
>
> <a href="https://webkit.org/blog/6830/a-refined-content-security-policy/">https://webkit.org/blog/6830/a-refined-content-security-policy/</a>
>
> Where you are suggesting allowing "data:" for image and "data:, blob:" for
> media (the heading should really be "less restrictive").
> </span >
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 <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - CSP: Source '*' should not match URLs with schemes blob, data, or filesystem"
href="show_bug.cgi?id=154122#c2">bug #154122, comment 2</a> 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.
<span class="quote">> Please can you follow the spec instead:
>
> <a href="https://www.w3.org/TR/CSP2/#match-source-expression">https://www.w3.org/TR/CSP2/#match-source-expression</a>
>
> "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).
> </span >
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:.
<span class="quote">> Keeping in mind that images, like TIFF's, can have buffer overflows ;-)
> </span >
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.
<span class="quote">> Might be related to Issue 153090.</span >
Can you elaborate?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>