Hacker News Reader

Comment by eric_arrr | Hacker News Reader

You can also use this trick to launch cross-site script attacks against sites that allow you to upload images.

Step 1: upload the "image" to the site. Let the site do whatever it does to ensure it has received a valid image. Nine validators out of ten will happily accept the file; the case that is likeliest to shoot you down is if the site modifies the image by cropping, resizing, or watermarking it.

Step 2: point your victim back to the uploaded "image" as though it's actually a page, and presto!, it's a page -- a page with malicious javascript in it.

Step 3: profit!

View on HN

There used to be a vulnerability where you could combine jars and gifs to similar effect; gifs are read front to back and jars (well, zip archives) are read back to front, so all you needed to do was concatenate them, upload your gifar, embed an applet pointing to the gifar into a page you owned and get a person to visit. Pretty sure it was patched ages ago though :)

But almost any site will be sending the image along with a Content-type header, so your browser would still open it up as an image, not an HTML page with JavaScript? Or no?

If you can control the filename, you can do things like embed <?php something_malicious(); ?> into an image, put it up as foo.jpg.php, and then execute it by hitting the 'image' directly. That's... sadly common.

Filename validation, I would imagine, is far more common than content validation.

If you are inspecting binary data for validity, and not checking the parameter (filename) that affects how Apache serves your file, you are doing something wrong.

Checking a filename may leave bugs to exploit. It's quite unlikely, but why break your head over a possible way to exploit your validation when you can just rename the file to something of your liking? Check the file for a png, jpg, etc. header, append that as extension (erroring when none was found), and done; no risk of it being executed.

You'd think this would be enough protection, but it turns out that some browsers (looking at you, IE) actually try to infer the content type from the page content. See http://msdn.microsoft.com/en-us/library/ms775147(v=vs.85).as... for more info.

This is why you should really be careful to get Content-Type correct and use X-Content-Type-Options: nosniff.

Congratulations, the user is on your website, running your malicious javascript. Which is going to do what, exactly? It doesn't have access to any other site's cookies or information.

I think (s?)he meant upload the image to someone else's site. The malicious code be running on that site... not your own. So then it does have access to that site's cookies.

nope, in this case the image will be interpreted as an image, not a script.

Right. I just took the example squirrel page, saved it, altered the comment section of the image to insert some javascript code alert('Hello') and opened it in my browser. It works but only if it is interpreted as html. So you'd need to be able to control it more.

Yeah, what jack-r-abbit said: the point is you've got malicious script embedded in a page from somebody else's web site, so you have access to cookies and can inspect and/or manipulate the user's session arbitrarily.

Nope, you have an image embedded in somebody else's web site, the script never runs.

Also that's completely different than what you originally said.

Andy, you're very confused.

Look. You are the one making the claim that you can exploit this. I call bullshit. So either prove it, or drop it. Accusing me of being "confused" does not provide evidence for your claim.

I'm not sure where I appeared to contradict myself in my earlier posts, so I'm unsure how to clarify this for you. Best I can do is this:

Here is a link to a variation of the "image" file which is the subject of this post: https://dl.dropbox.com/u/131649/squirrel.html

I have embedded harmless (-- honest! --) script in the file to demonstrate that your browser will execute the script in the context of the site where the file is hosted.

So, click the link. (Again I promise that no harm will come to your computer.) Now imagine that dl.dropbox.com is, instead, some hypothetical site where users are expected to upload images, but not HTML documents containing arbitrary script, and the security implications should be fairly obvious.

Be incredibly annoying and make you look like an idiot? e.g. the MySpace worm http://namb.la/popular/tech.html

well, after all samy is my hero.

Reply on news.ycombinator.com