Posted by Jack Jackson on 06/24/05 21:03

Thank you for ALL this great information, Richard! I really appreciate
all the help.

JJ
Richard Lynch wrote:
> On Thu, June 23, 2005 7:42 am, Jack Jackson said:
>
>>I cannot see a way to validate or examine Word or Excel files for
>>validity (and assume that older word files would validate differently
>>from newer ones).
>
>
> If your PHP does not have the mime_type functions, you could probably use
> http://php.net/exec with the "file" utility which does much the same thing
> under Un*x-like systems.
>
> "man file" on the command line for more info.
>
>
>>The PEAR http upload script mentioned twice in the user notes at that
>>manual page does not *seem* to validate other than denying certain
>>extensions like php, php3, etc. I could be wrong of course.
>
>
> Does it catch .asp, .cgi, .pl, .htm, .html, .jpg, .png, .gif, .jpeg, .pdf,
> and .swf?
>
> Cuz at certain directories on *my* server, those are all PHP scripts!
>
> Well, okay, .pl and .cgi aren't. Actually, I think I still have a .cgi
> somewhere that *is* a PHP script... It's equally dangerous either way.
>
> Maybe someday they will be on your server, too, once you run into the
> zillion IE bugs where the URL counts for more than the Content-type:
> header.
>
> It's really Bad Practice to rely on the last N characters of a filename as
> some kind of Security Measure to stop a serious attack...
>
>
>>Also, it seems that directories must be blown wide open (777) to allow
>>the script to copy the file over from /tmp. My ISP won't allow
>>directories to be set to 777 under public_html/ -- but we need to access
>>the files via web browser which is the whole point.
>
>
> Well, requring 777 just plain sucks...
>
> You *should* have a directory writable by the PHP user/group as the
> minimum requirement.
>
> If PEAR really and truly requires 777, then that feature of PEAR sucks,
> and you shouldn't use it. Sorry, PEAR guys. Gotta call 'em as I see 'em.
>
> And if the best it can do is outlaw .php .php3 ..., then that ain't much
> either. I'd rather code it myself than have that weak of a safety.
>
>
>>So my questions:
>>1. How do you validate Word and Excel files before upload?
>
>
> You don't.
>
> Any validation done before upload is done on the client, and is therefore
> something that can be easily bypassed by the savvy user.
>
> It might be useful as a User-Interface feature to catch obvious stupid
> mistakes by honest folk...
>
> But it's USELESS as a Security Measure to stop Bad Guys.
>
> Oh yeah:
>
> You may need to use move_uploaded_file to move the files to a staging area
> before you use exec/file on them...
>
> At least, under *MY* webhost's setup, I can't directly read PHP uploaded
> files from /tmp, even though PHP can move_uploaded_file() them... That may
> have been changed/fixed, but it's a possible configuration issue.
>
> So, use move_uploaded_file to let PHP do its checks, but put stuff in a
> staging area that the PHP user can read/write, and is *NOT* in the
> web-tree.
>
> Then, do all of YOUR checks. getimagesize, exec("/usr/bin/file $file"...)
> etc.
>
> If that all passes, move the file (again) to its final destination, which
> should *still* be out-side the web tree on most shared servers.
>
> Write a PHP script that only allows files already listed in your database
> to be served up, and which readfile's the data from outside the webtree to
> spew it out.
>
> *IF* you are on a dedicated server, or *IF* your webhost has a unique
> UID/GID for you to have directories that no *OTHER* user on that webhost
> can write to your PHP-writable directories/files, *then* it is
> probably/maybe just as safe to put stuff in your webtree as to readfile it
> from outside the web tree...
>
> Even then, I'd only do the direct to webtree if performance was a major
> issue. It just doesn't make sense to me to let untrusted users put stuff
> in the webtree where they might manage to trick the server into executing
> it as Perl, PHP, JSP, ASP, or [deity] knows what code to do Evil things.
>
> It's gonna be a lot tougher for them to fool PHP's readfile into executing
> code. Hell, if they can do that, they already own your server.
>
>
>>2. How can I make a passthrough from a file above public_html to one
>>below it so that people can surf in with a browser and download files
>>which have been uploaded by the script?
>
>
> There's an easy one. :-)
>
> Put the files *OUTSIDE* your webtree.
>
> Then write a PHP script that takes an ID of a valid uploaded file that
> your previously stored in your database, looks up the path to that file,
> and use http://php.net/readfile on it.
>
> You were real close with passthrough which is http://php.net/passthru
> which is kind of the same, only not.
>
> You'd only put files in the webtree if PHP readfile proved too slow, *AND*
> you were sure no user on the box could ever manage to infiltrate a
> damaging file into the webtree...
>
> That second one is a pretty Tall Order...
>
> I can see somebody justifying it, but, honestly, if the overhead of
> readfile is that big of a deal, then maybe you're living too close to the
> edge on performance in the first place, and it's time to buy more/better
> hardware anyway.
>
> So, in MY opinion, you should NEVER put uploaded files from untrusted
> users in the webtree.
>
> Sure, if it's the site's "admin" user or some trusted user who you have a
> Reasonable Expectation that they simply wouldn't upload Bad Stuff, putting
> in the webtree isn't quite as bad...
>
> But you have to consider the ultimate source of the content.
>
> Are they just uploading what somebody else sends them for a headshot?
>
> You really think there isn't somebody out there that couldn't generate a
> reasonable-looking headshot that, if passed through PHP, would do Bad
> Things on your server?
>
> Jeez, I think even *I* could manage that. Throw some PHP code into the
> Comments section.
>
> If they can manage to get that file to end up in a directory of PHP
> scripts that generate GD images, and those scripts end in .gif to fool the
> broken IE browsers as some of mine do, it could be Game Over.
>
> Maybe this can't happen on your server today, but can you guarantee you'll
> NEVER have sombody playing around with GD and using ForceType to solve the
> IE bugs?
>
> Put it outside the webtree and use readfile, and you can't go wrong.
>

[Back to original message]