Re: PHP File Upload Security Hole - Still No Fix?

From: Date: Tue, 05 Sep 2000 20:28:18 +0000
Subject: Re: PHP File Upload Security Hole - Still No Fix?
References: 1 2 3  Groups: php.dev 
Request: Send a blank email to php-dev+get-32238@lists.php.net to get a copy of this message
Jon Ribbens wrote: > Stanislav Malyshev <stas@zend.com> wrote: > > JR>> It was caused by the register_globals *ethos* that it is fine to > > JR>> mix trusted and untrusted data with no way of telling which is > > JR>> which. > > All data is untrusted. We just make it a bit easier to check them. > No, data from the user is untrusted. Data that PHP itself provides > (i.e. the filename of the local file) is (and has to be) trusted. This is poor coding practice, especially with large projects. All variables are untrusted entities, regardless of where you "think" they came from. What may seem like a PHP supplied variable today may turn out to be a user-supplied variable tomorrow, intentionally, or otherwise. Some examples: 1. An include file is normally given PHP cleaned, and checked, variables. six months down the road, somebody uses that same include in another project, without cleaning and checking the variables. 2. A function you use in one PHP script is copied and pasted into another script, where the function is now recieving "dirty" data. 3. A script which normally expects "clean PHP data" is fed dirty data from a client machine. _This was the attack in question_. > Data from other parts of the script is trusted. This security problem does *not* come from other parts of the script. It is a *client side attack*, based on *client supplied variables*. What PHP wasn't doing was cleaning the data for you. > > Well, this is pretty new addition - maybe it didn't get in the docs yet. > > If you need it too bad just cry on phpdoc@lists.php.net and somebody will > > do it. PHP is not 100% documented yet, this is known fact and it will > > never be 100% documented in given amount of time, given the ongoing > > development and general nature of the project. > That's fair enough, but this particular documentation omission is a major > security hole. If you care about security at all, it must be fixed. The documentation on possible upload problems was being updated before you had even written this. Documentation is published nightly. > You always have something to fear. It means that trusted data from your > own PHP scripts is indistinguishable from untrusted data from user input. No, this data was not from inside a script. > This is a Very Bad Thing. The file upload problem is simply one sympton > of a much more general sickness. The sickness of bad coding practice is what lead to bondage and discipline languages in the first place. I agree it is a problem. Please help with solutions. -Bop -- Brought to you from boop!, the dual boot Linux/Win95 Compaq Presario 1625 laptop, currently running RedHat 6.1. Your bopping may vary.

« previous php.dev (#32238) next »