4 ms·
> So if you allow file uploads or printing arbitrary user data in your service, you should always verify the contents as well as sending a Content-Disposition h
by staunch 12y ago
> So if you allow file uploads or printing arbitrary user data in your service, you should always verify the contents as well as sending a Content-Disposition header where applicable.
The idea that you can "verify the contents" is pretty much just wrong. You actually have to parse the files and write out your own known-safe version. It's a real pain in the butt to do that correctly and securely across a wide variety of file types.
Even parsing arbitrary user uploads with something like ImageMagick is probably exploitable, simply because those libraries weren't designed to handle hostile input.
- meowface 12y agoThis isn't too related to what the blog post was discussing, but just to give an example of how you're right: If a PHP page is allowing file uploads and only verifies the content of the data, but nothing else, then no protection is offered against arbitrary code execution. It's easy to craft a JPEG header and then place `<?php ... ?>` right after it; you could even append it to a valid JPEG body, too.
- rhizome 12y agoIsn't it a reasonable workaround to scan the file for content-type and make the file available once it passes the criteria for the upload? Find a php file uploaded with an extension of .jpg? "Sorry, there was a problem with your file. Please try again."
- ubernostrum 12y agoAnd then you run into polyglot files which are valid for multiple types...
- deleted 12y ago[deleted]