When I saw this, the first thing I immediately thought was: why don't webcomic authors use this to fix the problem of people linking directly to their images instead of the pages their images are on? This could revolutionize how webcomics and social aggregators interact.
A file that's both an acceptable HTML page and a JPEG (view source on it)
121–130 of 133 posts
Re: A file that's both an acceptable HTML page and a JPEG (view source on it)
#122When I saw this, the first thing I immediately thought was: why don't webcomic authors use this to fix the problem of people linking directly to their images instead of the pages their images are on? This could revolutionize how webcomics and social aggregators interact.
Hotlinking isn't actually a big problem these days, or at least I don't hear anyone complaining about it. A bigger issue is people who take the comic, remove any watermarks, and then upload it somewhere else.
I don't know why they remove the watermarks, but that step alone invalidates your suggestion.
Re: A file that's both an acceptable HTML page and a JPEG (view source on it)
#123He should do it with his 404 page, too:
http://lcamtuf.coredump.cx/squirrel/404.html
:)
Re: A file that's both an acceptable HTML page and a JPEG (view source on it)
#124Earlier quoted context omitted.
You can put HTML files in public folders. Files in public folders are loaded on a separate domain.
No, I mean for new users they are doing away with the public folders. You can now get a public link to any folder in your dropbox, it's just it goes to a splash page where they let you view the pic, or download the html. Basically new users won't be able to use their dropbox public folder as a webserver because of that anymore, no hotlinking images with dropbox links.
I know. My point was that this isn't a good justification to remove the public folder, as people could always put HTML files there and it was safe to do so.
Re: A file that's both an acceptable HTML page and a JPEG (view source on it)
#125Earlier quoted context omitted.
Very interesting, thanks! By the way, the for loop seems to be irrelevant to the invocation, (1,eval) just returns eval. (1,console.log)("hi") looks like it should work, except it raises an error. (1,2)+3 returns 5, however, and (1,console.log) returns the log function.
it's a performance thing. i forgot the details, but if you change the `(1,eval)` to `eval`, it's all much slower. something with the scope of the code that's being eval'ed, if i recall correctly.
(1,eval)('2*2') evaluates in the global context, so it may be slower I would think. Here's a really long and insanely detailed post about this odd feature: http://perfectionkills.com/global-eval-what-are-the-options/
Re: A file that's both an acceptable HTML page and a JPEG (view source on it)
#126How does it work?
Re: A file that's both an acceptable HTML page and a JPEG (view source on it)
#127Earlier quoted context omitted.
If you can control the filename, you can do things like embed 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.
Re: A file that's both an acceptable HTML page and a JPEG (view source on it)
#128I've always wondered how the site snag.gy does something similar. Take this link, for example (you'll have to disable AdBlock if you want to see the ad): http://i.snag.gy/0obAy.jpg (ignore the image itself; it was one of the first to pop up in my history) The source is just the image, and you can embed the image, but there's an ad under the image. Also, right click -> view image or copy image location point to the sa…
I suspect that's doing some kind of autodetection to decide which version of the page to serve. (Perhaps based on what MIME type the browser requests.)
Yep. In Chrome, pasting the URL in the address bar:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept:*/*Re: A file that's both an acceptable HTML page and a JPEG (view source on it)
#129You 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 yo…
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?
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.
Re: A file that's both an acceptable HTML page and a JPEG (view source on it)
#130Earlier quoted context omitted.
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.