Would it be possible to turn <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=30?q=ukm%20usecounter&ss=chromium> the usecounter into a UKM to get a better view of the number of impacted origins, beyond just the homepage?
I wonder if this would be a good candidate for a deprecation trial + enterprise policy. That would solve this injection vector for the broader web, while giving impacted folks some more time to move away from this pattern. On Fri, Jan 13, 2023 at 9:11 PM 'Jun Kokatsu' via blink-dev < blink-dev@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF65KcSCkzVupRw4n8ZG%3DKKbG5GY62HzwNSZW4Z78ZYd_w%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/CAL5BFfVrR4WakWXOFzq4zJ8WBHHj7vAVtoi6r19j8f3ty%3D0WHA%40mail.gmail.com.
