Discussion in 'Resolved Bug Reports' started by RoldanLT, Feb 5, 2014.
Image Direct URL: http://res.cloudinary.com/demo/image/upload/w_300/sample.webp
I responded elsewhere that this is intentional - we only allow PNG, GIF, and JPEG and we do basic verification on them.
Is it possible to extend (let's say with an add-on) the image proxy to support different formats?
Whats wrong with that extension?
@digitalpoint addon support that perfectly
Yeah I don't see why you wouldn't support more formats out of the box. Seems silly and really easy to implement.
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
Yeah i use webp images too (ngx_pagespeed auto converted png images) so would be nice to support webp.
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.
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...
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.
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).
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.
.webp images are already supported
But not all .webp works.
Still not working on .webp images generated by ngx_pagespeed.
Separate names with a comma.