4 ms·
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
by eric_arrr 14y ago
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!
- crazygringo 14y agoBut 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?
- daeken 14y agoIf 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.
- mkopinsky 14y agoFilename 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.
- lucb1e 14y agoChecking 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.
- navytank 14y agoYou'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).aspx http://msdn.microsoft.com/en-us/library/ms775147(v=vs.85).as... for more info.
- AndyKelley 14y agoCongratulations, 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.
- jack-r-abbit 14y agoI 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.
- AndyKelley 14y agonope, in this case the image will be interpreted as an image, not a script.
- jack-r-abbit 14y agoRight. 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.
- __alexs 14y agoBe incredibly annoying and make you look like an idiot? e.g. the MySpace worm http://namb.la/popular/tech.html http://namb.la/popular/tech.html
- zethraeus 14y agowell, after all samy is my hero.
- eric_arrr 14y agoYeah, 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.
- HeyImAlex 14y agoThere 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 :)
- __alexs 14y agoThis is why you should really be careful to get Content-Type correct and use X-Content-Type-Options: nosniff.