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
<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 <mailto: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
<mailto: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/
<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://svgwg.org/svg2-draft/struct.html#UseElementHrefAttribute>
https://github.com/w3c/svgwg/pull/901/files
<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
<http://slickdeals.net>and
hunter.104.com.tw
<http://hunter.104.com.tw>) which use
data: URLs in SVGUseElement.
The use in slickdeals.net
<http://slickdeals.net>is invisible
(i.e. used in the footer but doesn't
appear), and hunter.104.com.tw
<http://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://www.comune.vernio.po.it/>,
https://appaltinnovativi.gov.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
<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
<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
<mailto: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
<mailto: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
<mailto: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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d63c3823-20b6-457c-bff9-f85429421bf0n%40chromium.org?utm_medium=email&utm_source=footer>.
