Re: Securing PHP code

Ok :) The only reason that I was so adamant about it was I had a 'heated' discussion with a business associate who's server was compromised - and he was, lets say, insistant that the fact that there were database passwords in a php file inside the webroot was the reason it was insecure. I just wanted to know if I was wrong in saying that the passwords were not compromised without the server access being compromised.... (not to mention the clear text password accesses, the wildcarded mysql access on a remote host passed in clear text, the lack of ssl on pages collection cc information, same root passwords across the network and dictionary hackable passwords for users :) Oh, and did I mention the non ssh telnet access from internet café's?) Thanks :) On 6/25/03 5:49 PM, "Mike Migurski" <mike@saturn5.com> wrote: >>> Why rely on some access restriction when you don't have to? You include >>> code using a filesystem path. There is no need for it to reside under >>> document root. Yes, you can make it so that certain things are not >>> served directly by the Web server, but why take the extra risk? You >>> gain nothing. What if you make a mistake? What if you install a new >>> version of Apache and that file accidently gets served raw? >> >> Fair enough - but that still does not answer my question. Is there a way >> to get a php document served raw if apache or whatever server is >> configured correctly? > > I don't believe so, no. > > >> So back to the original question: >> >> "Maybe I am missing something totally obvious, but if the server is set >> up to properly parse php files - having configs outside of the doc root >> should not make much of a security difference? " >> >> Is this a true statement or not? (of course we have to make the >> assumption that server access has not been compromised....) > > It's a true statement /if/ the server configs don't change -- but why risk > it? seriously... if you're concerned about those values being compromised > stick 'em someplace where you /know/ they won't get served up, no matter > what happens to the webserver. I usually put them in .htaccess first, then > move them to httpd.conf on production: > > http://httpd.apache.org/docs/mod/mod_env.html#setenv > http://php.net/getenv > > Also it helps with version control, since you can keep the > environment-specific stuff out of CVS (and PHP entirely). > > --------------------------------------------------------------------- > michal migurski- contact info and pgp key: > sf/ca http://mike.teczno.com/contact.html -- Cheers Mike Morton **************************************************** * * Tel: 905-465-1263 * Email: mike@webtraxx.com * **************************************************** "Indeed, it would not be an exaggeration to describe the history of the computer industry for the past decade as a massive effort to keep up with Apple." - Byte Magazine Given infinite time, 100 monkeys could type out the complete works of Shakespeare. Win 98 source code? Eight monkeys, five minutes. -- NullGrey