This post seems to be hinting that this is potential security issue, but I'm not sure how it would be. All I can imagine this buying you is the ability to serve JS from someone else's domain, but the domain JS is served from doesn't change its security privileges; that's based on the domain of the HTML file the JS is included in.
When GIFs serve JavaScript
11–17 of 17 posts
Re: When GIFs serve JavaScript
#12This exploit seems to require a tag.
But if you let your users insert a tag into any text field, this exploit is the least of your worries. Why encode your attack into a GIF file when you can just open a tag and attack away in the comfort of a WYSIWIG editor?
A more interesting attack vector is the static HTML file that the attacker used as a vehicle for his tag. If your users can upload an HTML file, or any other file that the browser might display as an HTML document (IE loves to guess the content type), you are vulnerable to XSS, no matter how thoroughly you filter all the other form fields.
One of the easiest ways to mitigate this vulnerability is to force browsers to download/save all user-uploaded files instead of displaying them. Configure your file server to add a Content-Disposition: attachment; header to all user-uploaded files.
Re: When GIFs serve JavaScript
#13I wish there was a way to run the embedded javascript when the image is loaded. I have a legitimate use case for it (imagine you send an image URL as a JSON response and wanted to track it was loaded, or send other params back to the service)
Re: When GIFs serve JavaScript
#14This exploit seems to require a tag. But if you let your users insert a tag into any text field, this exploit is the least of your worries. Why encode your attack into a GIF file when you can just open a tag and attack away in the comfort of a WYSIWIG editor? A more interesting attack vector is the static HTML file that the attacker used as a vehicle for his tag. If your users can upload an HTML file, or any other fi…
> One of the easiest ways to mitigate this vulnerability is to force browsers to download/save all user-uploaded files instead of displaying them. Configure your file server to add a Content-Disposition: attachment; header to all user-uploaded files.
But I can imagine many scenarios were the whole purpose of letting the user upload images is so that you can inline display them on the web (such as a forum avatar picture). Requiring the manual downloading of the image wouldn't be an acceptable solution for most people there.
Re: When GIFs serve JavaScript
#15So the site has to allow script tags for this to work? If that's the case, then you could simply put the code in the script tag and not have to mess around inserting it into a gif.
Re: When GIFs serve JavaScript
#16This exploit seems to require a tag. But if you let your users insert a tag into any text field, this exploit is the least of your worries. Why encode your attack into a GIF file when you can just open a tag and attack away in the comfort of a WYSIWIG editor? A more interesting attack vector is the static HTML file that the attacker used as a vehicle for his tag. If your users can upload an HTML file, or any other fi…
> One of the easiest ways to mitigate this vulnerability is to force browsers to download/save all user-uploaded files instead of displaying them. Configure your file server to add a Content-Disposition: attachment; header to all user-uploaded files. But I can imagine many scenarios were the whole purpose of letting the user upload images is so that you can inline display them on the web (such as a forum avatar pictu…
If you use a proper tag to embed an image in a webpage, it will display correctly even if the server sets a Content-Disposition header to force download. The header only makes a difference when you explicitly navigate to the URL of the user-uploaded resource.
Re: When GIFs serve JavaScript
#17This is neither particularly new, nor particularly dangerous.
One possible attack vector would be abusing a filename/MIME mismatch to trick people into executing it locally.
If you have a website that allows image uploads and keeps the original filename, you could create an image that displays normally when displayed on the web, but executes arbitrary code when downloaded and executed locally.
This was inspired by the 2011 incident that lead to the use on CAPTCHA on 4chan. A spambot known as Cornelia would flood the boards with copies of itself that contained instructions how to execute it in the image data. Of course, that only worked because people would knowingly execute a virus just to spite the mods.