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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
*
****************************************************

"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 


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to