Thank you Rick for the detailed explanation! On Fri, Jan 13, 2023 at 10:30 AM Rick Byers <rby...@chromium.org> wrote:
> Eliminating this makes sense to me given the security benefit. Thank you > for pushing it! But it does seem somewhat risky from a web compat > perspective. 0.005% is above our "small but non-trivial risk > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.mqfkui78vo5z>" > rule of thumb. Here's a bit of an analysis according to our other compat > principles <http://bit.ly/blink-compat>: > > - Severity of breakage > > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.u5ya6jvru7dl>: > lower given this is likely only about some visualis, but this site > <https://jobs.nzz.ch/> is a good example of non-trivial UI breakage. > This pattern of putting a base64-encoded SVG into an SVG <use> element with > nothing else in the <svg> is weird, isn't it? Why would someone do that > rather than just put the SVG in directly, or put the data URL into an img > tag? > > I've looked into that site. And it seems like they are reusing a single SVG image (i.e. data: URL SVG image) which contains several images, and changing which image should be rendered by combination of symbol <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/symbol> + id (which is only possible in use element, and not in img tag). Migration can be done by hosting the same image in the same-origin endpoint, converting it to blob: URL and assigning that to the <use> element, or inlining each SVG image. > > - I don't suppose there's some creative way to allow this specific odd > pattern while still getting the security benefit, is there? > > Unfortunately, no. While we could read the href value of <use> elements and convert the data: URL to blob: URL, we won't know if the data: URL was set by the site owner, or a malicious attacker (through HTML injection). So while we could provide such a library, it does not provide the security benefit that we are seeking. > > - Unique sites impacted > > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.4k9u8ddizqrq>: > Finding a variety of small sites is actually a lot worse than if we had > found only a few bigger sites. It means there's probably some common tool > or pattern leading different designers/developers to do this and so likely > a relatively large number of individuals who would need to be involved in > fixing the breakage. Of course our HTTP Archive list of sites is just a > subset of who's fully impacted, so if the problem is a long-tail one as it > seems, HTTP archive data shows us only the tip of that long tail. > - Security > > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.iklh96dxj81w>: > it's definitely worth taking some comapt risk to reduce XSS surface area. I > don't fully understand the threat model though. Is this mainly a risk for > sites who are programmatically putting (potentially attacker-controlled) > strings into SVGUseElement hrefs? Or are you more worried about cases where > the attacker controls the HTML and can take advantage of this oddity in the > platform on any normal site? I'm just trying to gauge the magnitude of the > security benefit here to weigh it against the comapt risk, any help is > appreciated. > > We are worried about both (i.e. Server-side injection and DOM XSS). The fact that this has led to several browser security feature bypasses (e.g. Sanitizer API and Trusted Types) suggests that it's not a commonly known XSS sink, and therefore we believe that it's common for security mechanisms (e.g. sanitizers, linters) to miss this odd feature. > > - Ease of adaptation > > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.x5bhg5grhfeo>: > seems like it should be easy to use an alternative, at least for these > image cases, but I guess it's hard to say without knowing why people are > doing this. Is there perhaps some website design tool which is generating > this and will need to change? > > I think it is easy to migrate by hosting the same image to the same-origin endpoint. However, I do understand that it's just less work to use data: URL than using same-origin image or blob: URL. > > - Interop > > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.4hjbxw7513sw>: > The fact that this doesn't work in Safari is a vote in favor of breaking it > in chromium to achieve interop. It does work in Firefox though. > > For the interop, it's best to use a same-origin URL or blob: URL. And since both Mozilla and Webkit are supportive, I believe it's positive. > > - Standards conformance > > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.xcsa26ortrmi>: > This is allowed by spec today, so breaking it requires some more diligence > > Note that the PR <https://github.com/w3c/svgwg/pull/901> to SVG spec got merged. > > - Enterprise > > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.axcg738lzcs9>: > Being broken in Safari is an indication the risk will be higher in > enterprise software which is often chromium-only. We may need to go through > the enterprise breaking change process > <https://www.chromium.org/developers/enterprise-changes/>. > - Outreach > > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.t9ade4ywppcg>: > Given the relatively high usage, if we want to proceed with this plan I > think this is the main opportunity for mitigations. Can we try contacting > some of these sites we've identified to understand why they're using this > pattern? Is there a tool generating this pattern which we can get updated > before we make the change? I think we'd need a blog post capturing what > we've learned from talking with a few customers who have done this and how > they fixed it for their UI design flow. > > Sorry it's not looking to be an easy decision, but I hope this gives you > some ideas for how we might be able to reduce the risk to a point that we > could proceed. WDYT? > Yes, it sounds good to me! I will check what has to be done and do those step by step 🙂 > > Rick > > On Thu, Jan 12, 2023 at 3:11 PM 'Jun Kokatsu' via blink-dev < > blink-dev@chromium.org> wrote: > >> On Thu, Jan 12, 2023 at 10:44 AM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> On 1/11/23 6:49 PM, 'Jun Kokatsu' via blink-dev wrote: >>> >>> Contact emails >>> >>> jkoka...@google.com >>> >>> Specification >>> >>> https://svgwg.org/svg2-draft/struct.html#UseElementHrefAttribute >>> >>> https://github.com/w3c/svgwg/pull/901/files >>> >>> Summary >>> >>> Assigning a data: URL in SVGUseElement can cause XSS. And this also led >>> to a Trusted Types bypass. >>> >>> Therefore, we plan to deprecate and remove support for it. >>> >>> >>> Blink component >>> >>> Blink>SVG >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESVG> >>> >>> Motivation >>> >>> Assigning an attacker controlled string to SVGUseElement.href causes XSS >>> and a Trusted Types bypass >>> <https://github.com/w3c/trusted-types/issues/357> because of data: >>> URLs. If we fix this bug by requiring TrustedScriptURL assignment to >>> SVGUseElement.href under Trusted Types enforcement, many sites would need >>> to refactor code (even for same-origin URL or Blob URL assignment). >>> >>> Since Webkit does not support data: URLs in SVGUseElement and both >>> Mozilla and Webkit are supportive for the removal, we think that removing >>> support for data: URLs in SVGUseElement is the right way to solve this >>> problem. >>> >>> Additionally, data: URLs can only trigger script execution in script >>> loaders such as HTMLScriptElement.src or dynamic import >>> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import>. >>> However, SVGUseElement is an exception to this, which also caused a >>> bypass >>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1306450#c10> in >>> the Sanitizer API. We believe that this also led to several other bugs in >>> sanitizers and linters missing a check for this special case. >>> >>> The usage >>> <https://chromestatus.com/metrics/feature/timeline/popularity/4356> of >>> data: URLs in SVGUseElement is about 0.005%. >>> >>> Digging into the HTTP Archive shows usages in ~50 sites. There are 2 >>> major sites (slickdeals.net and hunter.104.com.tw) which use data: URLs >>> in SVGUseElement. >>> >>> The use in slickdeals.net is invisible (i.e. used in the footer but >>> doesn't appear), and hunter.104.com.tw is using it for a single icon in >>> the footer (which is already broken when rendered in Webkit). Rest of the >>> usages seems to be in individual small sites. >>> >>> I poked around the 10 sample sites at the bottom of the use counter: >>> >>> https://www.aspareanord.it/, https://www.umbria.camcom.it, >>> https://www.bisenzio.it/, https://www.comune.vernio.po.it/, >>> https://appaltinnovativi.gov.it/, https://www.gdf.gov.it/, >>> https://www.us.schott.com/, https://shop.wavin.com/, >>> https://jobs.nzz.ch/, https://www.learnapp.com/ >>> >>> For the 6 Italian sites (I guess the same agency made them?), the right >>> arrow icon next to "Vedi" would disappear. For a site like >>> https://jobs.nzz.ch - there's a number of visually significant design >>> icons that would be gone towards the bottom (and yes, it looks sort of >>> broken today in Safari). >>> >>> It's not the end of the world, looking at these 10 sites, but I wonder >>> how a developer would know how to fix this. Have you considered a DevTools >>> issue? >>> >> >> Thank you for the suggestion! Yes, I do plan to follow Deprecation steps >> <https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/core/frame/deprecation/README.md> >> and >> add a Devtools issue 🙂 >> >>> Initial public proposal >>> >>> TAG review >>> >>> TAG review status >>> >>> Not applicable. >>> >>> Because this intent removes part of a feature, and it is already shipped >>> in Webkit (i.e. never supported). >>> >>> Risks >>> >>> Interoperability and Compatibility >>> >>> Gecko: Positive >>> <https://github.com/mozilla/standards-positions/issues/718> >>> >>> WebKit: Positive >>> <https://github.com/WebKit/standards-positions/issues/108> >>> >>> Web developers: No signals >>> >>> >>> Debuggability >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? >>> >>> Yes <https://github.com/web-platform-tests/wpt/pull/37511> >>> >>> Flag name >>> >>> RemoveDataUrlInSvgUse >>> >>> >>> Requires code in //chrome? >>> >>> False >>> >>> Tracking bug >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1300195 >>> >>> Estimated milestones >>> >>> Deprecate for 2 milestones, then remove depending on breakages. >>> >>> Can you say more about what the deprecation looks like (i.e., blog post, >>> deprecation reports, devtools issue, etc)? >>> >>> >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5128825141198848 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF6VXw7jmQoZM47i3ybzn%3D5Pc4mw26Khv9U9aP_UzBt-dg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF6VXw7jmQoZM47i3ybzn%3D5Pc4mw26Khv9U9aP_UzBt-dg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF5KQOG5R8baUM41T4fR01QbGFjvvEsf629h%2BzASCn_F0Q%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF5KQOG5R8baUM41T4fR01QbGFjvvEsf629h%2BzASCn_F0Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF65KcSCkzVupRw4n8ZG%3DKKbG5GY62HzwNSZW4Z78ZYd_w%40mail.gmail.com.
