Open mikewest opened 3 years ago
Thanks! I know we don't handle non-HTML really well yet. Both in spec as well as in implementations. #72 talks some more about this.
I know we don't handle non-HTML really well yet. Both in spec as well as in implementations. #72 talks some more about this.
Seconded. The spec still pretends that SVG doesn't exist, which opens up this hole.
The specific vector here seems to be <svg:use>
, which I guess should be either baseline-forbidden, or get treatment similar to <template>
.
Meanwhile, the spec knows SVG exists, but we haven't agreed on a "baseline" config for it yet. We should close this bug once that is there.
If it matters, Chromium has a for-testing configuration supporting SVG & friends, which does not have <svg:use>
in the baseline and thus unconditionally blocks it.
Do all implementations block data:
URLs in svg:use
these days? Does that open the door to allowing it?
(See also #103.)
with data:
URLs being unsupported, the remaining XSS risks with <svg use>
are URLs pointing to same-origin / same-document resources. Right?
What was the conclusion here and why? We should have something before we close an issue.
OK. <svg><use>
is at this point similar in capabilities to an <iframe>
, except that the included resources must be same-origin. We should make sure that we handle it the same way
A friendly, clever person submitted the following as a bypass of the
javascript:
URL handling in https://wicg.github.io/sanitizer-api/#handle-funky-elements: