When GIFs serve JavaScript | Hacker News Reader

When GIFs serve JavaScript

iamajin.blogspot.com

79 pointsbinarymax16 comments

Off-topic: Hilarious how broken Blogspot seems to be. Half the time I load this URL, I get a different post on the same blog ("Static DOM XSS Scanner") but still with the intended URL. Whatever this fancy JavaScript loading thing they are doing is utter bullshit.

The same thing happened to me. It's kind of ironic that to read an article about serving javascript in GIFs, I had to turn all of my js filters off.

Blogger is seriously horrible.

> I had to turn all of my js filters off.

I could read the article by enabling JS only for 1st-party + www.blogblog.com + www.blogger.com.

Thanks for pointing it out, I actually thought that was the article and didn't realise my mistake until I saw your comment.

Turning off javascript gives a blank page. Absolutely blank, not a single piece of content, not even - and this would still be terrible, just a tiny, tiny bit better than downright ridiculous - a message saying "you need javascript enabled to view this content". Say what you like about webapps requiring javascript (an argument for another day), there is no excuse for a blog requiring it.

I'm glad you mentioned this because I initially got the Static XSS Scanner and was about to flag the article as "full of lies"

So blogspot.com is being merged with Google+? I only rarely bother to disable my JavaScript/ad blockers to read things there.

Looking at the source, it's a big pile of minified/obfuscated javascript crap. I can't be bothered to decode it.

Aha, thanks for that, I was wondering why the post had nothing to do with GIFs.

This exploit seems to require a <script> tag.

But if you let your users insert a <script> 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 <script> 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 <script> 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.

> 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.

If you use a proper <img> 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.

This 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.

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.

Would this be blocked by the X-CONTENT-TYPE-OPTIONS header? (source: http://ibuildings.nl/blog/2013/03/4-http-security-headers-yo... )

I 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)

So 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.

Reply on news.ycombinator.com