As designed Image Proxy didn't work on Images with .webp extension


Well-known member

Image Direct URL:
I responded elsewhere that this is intentional - we only allow PNG, GIF, and JPEG and we do basic verification on them.
Well, silent re-encoding isn't relevant -- that's done based on the Accept header so it wouldn't apply.

In general, there are some potential security considerations here. We also don't want arbitrary content cached (so we do basic image verification). Worth noting that WebP isn't covered by getimagesize() (nor is SVG, but that's a bit different).

In terms of security, SVG can include JS (see Since it's being proxied, it would then run in the context of your forum. That's an XSS right there.
SVG can include JavaScript, but that JS will never execute if the SVG is rendered with an IMG tag. You more or less need to implicitly allow it by embedding it with an OBJECT tag. Because as you point out, imagine what sort of nastiness people could pull with it... Could replace people's AdSense or something.

I actually needed embedded JS in SVG for something legit (just for some manipulation of the image itself) and it was driving me crazy how it would work until it was an embedded image. Then figured out browsers disable it when using IMG tag (for good reason).
The browser executes the JS if you visit the URL directly though, so it's still an XSS unfortunately...
The browser executes the JS if you visit the URL directly though, so it's still an XSS unfortunately...
True, but so does any web page. If you follow a link to my website, JS will get executed. Would that be any different?

Not sure how that would be an XSS anymore than visiting any page via a link because the JS would run only when it's outside the scope of the page you clicked the link from. Maybe I'm missing something?
It's not really about manipulating the page, but stealing data or whatever you want with an XSS. Since the image is proxied, it's run in your site's security context, which means that an Ajax request could be made to your forum (which means getting the CSRF token and then making any request they potentially want). You just need to "trick" someone to viewing the image directly.
We only allow a whitelisted set of content types to be displayed inline (not including SVG).

Actually, looks like I may have made a mistake in my test. It doesn't seem to work as simply as I thought. You may be able to get the uploaded SVG embedded in a context where script does run (object, iframe, etc) and I would imagine it'd be running in the served domain context, though I'd have to confirm this.

SVG most definitely has been an attack vector before -- GMail was bitten by it, for example (involved code running in their domain context).
Ya, I didn't mean an attachment being inserted inline, rather an SVG attachment existing in your domain and becoming an XSS issue like you mentioned by someone visiting the attachment URL. Haven't looked into it myself (just on cell phone at the moment)
We just send application/octet-stream, which the browser saves. (Fortunately, MIME sniffing is mostly over.

A bit more playing and I'm pretty sure I can XSS with SVG. I think my test document just had some mistakes/over-simplifications.
Top Bottom