As designed Image Proxy didn't work on Images with .webp extension
- Thread starter rdn
- Start date
Moshe1010
Well-known member
Is it possible to extend (let's say with an add-on) the image proxy to support different formats?
digitalpoint
Well-known member
Does anyone use .webp? I guess that's largely irrelevant, because *someone* must.
But I definitely ran into the same issue here with SVG/SVGZ images that once worked... http://xenforo.com/community/threads/original-xf-images.29966/page-5#post-464407
But I definitely ran into the same issue here with SVG/SVGZ images that once worked... http://xenforo.com/community/threads/original-xf-images.29966/page-5#post-464407
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 https://www.owasp.org/images/0/03/Mario_Heiderich_OWASP_Sweden_The_image_that_called_me.pdf). Since it's being proxied, it would then run in the context of your forum. That's an XSS right there.
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 https://www.owasp.org/images/0/03/Mario_Heiderich_OWASP_Sweden_The_image_that_called_me.pdf). Since it's being proxied, it would then run in the context of your forum. That's an XSS right there.
digitalpoint
Well-known member
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).
http://www.schepers.cc/svg/blendups/embedding.html
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).
http://www.schepers.cc/svg/blendups/embedding.html
digitalpoint
Well-known member
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.
digitalpoint
Well-known member
Hmmm... Have you tested this with SVG attachments by chance?
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).
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).
Null
Well-known member
digitalpoint
Well-known member
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)
