I don't understand why it wasn't immediately understood that SVG is as dangerous as HTML.
It is not, and never was, an image format. It's a markup language.
The woes of sanitizing SVGs
21–30 of 118 posts
Re: The woes of sanitizing SVGs
#22I did not expect to see GarboMuffin.
Re: The woes of sanitizing SVGs
#23[flagged]
Re: The woes of sanitizing SVGs
#24My first thought is "support a tiny subset of svg that probably still covers 90% of real-world use cases". I do feel that's there's two distinct types of svg - "bunch of paths with fills" and "clever dangerous stuff" where most real SVGs are of the former type. Fully expect this to be shot down by someone that's thought about this problem for longer than the 120 seconds I just spent. :)
I think you're right but the lack of industry standard for this kind of thing kills it. People want to be able to take the output of whatever tool they use that exports SVG and put it in a browser. Which isn't an unfair request. But you wouldn't have a guarantee it wouldn't filter out the tool using some obscure SVG functionality. I'd love to see an agreed standard like OpenGL vs OpenGL ES for SVG. SVG-ES. Everyone a…
[deleted]
Re: The woes of sanitizing SVGs
#25I'm glad this article includes the only credible fix for the HTTP leak problems: CSP. A useful thing I learned recently is that, while CSP headers are usually set using HTTP headers, you can also reliably set them directly in HTML - for example for HTML generated directly on a page where HTTP headers don't come into play: "> It feels like this shouldn't work, because JavaScript in the untrusted content could use the…
I did not know about `srcdoc`, but it looks like that's still vulnerable to injection by using a double quote and to escape the sandbox. If this is constructed in a hygienic way using DOM manipulation, it seems like it could work, but it definitely seems possible to screw up.
Re: The woes of sanitizing SVGs
#26I'm glad this article includes the only credible fix for the HTTP leak problems: CSP. A useful thing I learned recently is that, while CSP headers are usually set using HTTP headers, you can also reliably set them directly in HTML - for example for HTML generated directly on a page where HTTP headers don't come into play: "> It feels like this shouldn't work, because JavaScript in the untrusted content could use the…
Nice, favorited... thinking this could be useful for an email reader to support css, but not scripts.
Re: The woes of sanitizing SVGs
#27I'm glad this article includes the only credible fix for the HTTP leak problems: CSP. A useful thing I learned recently is that, while CSP headers are usually set using HTTP headers, you can also reliably set them directly in HTML - for example for HTML generated directly on a page where HTTP headers don't come into play: "> It feels like this shouldn't work, because JavaScript in the untrusted content could use the…
I did not know about `srcdoc`, but it looks like that's still vulnerable to injection by using a double quote and to escape the sandbox. If this is constructed in a hygienic way using DOM manipulation, it seems like it could work, but it definitely seems possible to screw up.
s/"/"/g
Re: The woes of sanitizing SVGs
#28I'm glad this article includes the only credible fix for the HTTP leak problems: CSP. A useful thing I learned recently is that, while CSP headers are usually set using HTTP headers, you can also reliably set them directly in HTML - for example for HTML generated directly on a page where HTTP headers don't come into play: "> It feels like this shouldn't work, because JavaScript in the untrusted content could use the…
And any additional CSP directives can only narrow what's allowed. Also works with headers plus - s can restrict the CSP even more than what the headers specified, but they can't widen it.
Re: The woes of sanitizing SVGs
#29I'm glad this article includes the only credible fix for the HTTP leak problems: CSP. A useful thing I learned recently is that, while CSP headers are usually set using HTTP headers, you can also reliably set them directly in HTML - for example for HTML generated directly on a page where HTTP headers don't come into play: "> It feels like this shouldn't work, because JavaScript in the untrusted content could use the…
I did not know about `srcdoc`, but it looks like that's still vulnerable to injection by using a double quote and to escape the sandbox. If this is constructed in a hygienic way using DOM manipulation, it seems like it could work, but it definitely seems possible to screw up.
If you're constructing your unsandboxed parent document HTML using string concatenation, you might as well not use the sandboxed iframe at all. But presumably someone who bothers to sandbox untrusted content also knows about setAttribute(), or the srcdoc JS property.
Re: The woes of sanitizing SVGs
#30For the "" stuff: regardless of how the thing is spelled or otherwise obscured, the HTML5 parser eventually knows when it's gotten hold of a script tag. Oops, we got one in a NOSCRIPTTAG context. Let's poop out.
Tag names, attributes, attribute values, event callback default-cancelers... so many ways to declare that this node and its children shouldn't parse/evaluate scripts.
As Jay-Z said: "I've got 99 solutions, fixing a problem ain't one"