Per today's API OWNERs meeting, a dumb question: is the XSS risk here largely down to script execution triggered by this pattern? Or non-script content in the inline'd SVG?
Thanks On Tuesday, January 17, 2023 at 10:52:29 PM UTC-8 Jun Kokatsu wrote: > On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan <bhee...@google.com> > wrote: > >> Thanks for adding me. Yes, this definitely seems like the pattern where >> we'd want a temporary enterprise policy to re-enable support for ~3 >> milestones after we remove support by default. >> go/chrome-enterprise-friendly >> <https://goto.google.com/chrome-enterprise-friendly> gets into the >> details of the why, >> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md >> >> is the step-by-step, and the enterprise team is always happy to advise as >> well. >> > > Thank you for the details on enterprise policy! I'll make sure to follow > those steps when I plan to remove the feature by default! > >> On Tue, Jan 17, 2023 at 10:51 AM Rick Byers <rby...@chromium.org> wrote: >> >>> On Tue, Jan 17, 2023 at 4:48 AM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> 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? >>>> >>> >>> Yeah that could be useful. But we've also got some leads already so >>> getting more leads may not be critical until we follow up on the ones we >>> have. Can we find a developer for one of those sites who will talk to us >>> about where that pattern is coming from in their toolchain and how they'd >>> migrate off it? Having the UKM data will also help in selecting the sites >>> that will have the most impact on our users (and hence our UseCounter >>> stats). Maybe we'll get lucky and find that, despite the long tail, 90% of >>> the usage is from just a few sites we can work with. >>> >> > Added UKM at https://crrev.com/c/4171733. > >> >>> 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. >>>> >>> >>> Good idea. Impacting a large number of small sites is still problematic >>> for a deprecation trial. Just reaching enough to make any change at all is >>> the hard part. Perhaps we can make replacing the usage easier than the >>> overhead of getting an applying an OT token? Still a deprecation trial >>> would probably be useful. Enterprise policy, certainly. +Brandon Heenan >>> <bhee...@google.com> can help advise on that. I'd also advise leaving >>> this enabled for WebView (at least to start), it feels like the sort of >>> chromium rendering quirk we've found Android apps to rely on >>> disproportionately in the past. >>> >>> 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. >>>>> >>>> >>> Interesting. So could we write a tool which, given the source html, >>> transforms it to simply inline the selected SVG? That would save some bytes >>> too, right? We've found in the past that when we give developers easy tools >>> to trivially adapt their code, then it makes moderate-risk deprecations go >>> quite smoother. I.e. when we get to the point of having a deprecation >>> warning (and report <https://wicg.github.io/deprecation-reporting/>) >>> for the usage, if we can simply say "for most cases we've found you can >>> just run your html through this tool to adapt it automatically", then that >>> would help a LOT in having the comfort to make the breaking change. Someone >>> from the devrel or tooling teams with experience in how developers approach >>> images in practice (eg. +Addy Osmani <ad...@chromium.org>) might be >>> able to advise on a pragmatic and helpful path. >>> >> > I've created a site to convert data: URLs in SVGUseElement to inline SVG. > https://data-urls-in-svg-converter.glitch.me/ > >> >>>>>> - 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. >>>>> >>>> >>> Right, yes, sorry. What I meant was we took the initiative to make a >>> breaking change to long established behavior - IMHO that makes the bar >>> higher than if Chrome had just had a bug in allowing something that was >>> never spec'd or allowed by other browsers. Still I think we can use this >>> positively in our outreach - say something like "the spec has changed to >>> not allow this, all the major browser engines agree that for security >>> reasons it should be disallowed. It already doesn't work in Safari and >>> other WebKit browsers, we want to help you fix your site to work in all >>> browsers". >>> >>>> >>>>>> - 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 🙂 >>>>> >>>> >>> Ok, good luck! Sorry this isn't as straightforward as a clear recipe. >>> But if we can get a couple developers telling us they were easily able to >>> fix their issue by using a tool or straightforward instructions we can >>> point other to, and we see the UseCounter drop significantly (say by half >>> or so) without major new red flags, then I'd personally be OK approving a >>> removal attempt. Of course it's common to learn during beta (or, worst >>> case, upon stable release) that the compat issue is worse than we thought >>> and so the change needs to be reverted (or flagged off with finch) in a >>> hurry. But I think we've learned a lot over the years about how to predict >>> and avoid that failure mode. Let me know if I can do anything else to help, >>> happy to meet to brainstorm further for example. Good luck! >>> >> > Thanks! I'll start outreach for a couple of sites we already know are > affected, and go from there! > >> >>> >>>>>> 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/d63c3823-20b6-457c-bff9-f85429421bf0n%40chromium.org.
