Home > Archive > PHP Language > May 2006 > how safe are passwords embedded in php pages?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
how safe are passwords embedded in php pages?
|
|
| Joe Butler 2006-05-23, 9:57 pm |
| I'm kind of new to php / apache / MySQL... and wondered what failures would
need to occur on an apache server so that a raw php page (including embedded
user/password) was served up to a browser instead of the expected generated
output?
And even if the user/pass was served to a browser is it a serious matter
(assuming the user/pass was not a valid site logon)?
| |
| Michael Vilain 2006-05-24, 3:58 am |
| In article <4473bd7b$0$211$db0fefd9@news.zen.co.uk>,
"Joe Butler" <ffffh.no.spam@hotmail-spammers-paradise.com> wrote:
> I'm kind of new to php / apache / MySQL... and wondered what failures would
> need to occur on an apache server so that a raw php page (including embedded
> user/password) was served up to a browser instead of the expected generated
> output?
>
> And even if the user/pass was served to a browser is it a serious matter
> (assuming the user/pass was not a valid site logon)?
If you have a dedicated server where only _you_ have a site setup, then
I think this is pretty safe. Unless you do something massively stupid
with a php script that allows a page to download the php file to the
client browser, apache built with mod_php will interpet the pages.
If, however, you share the server with other sites, you have a security
problem. Especially if shell access is allowed. If the sy min hasn't
really thought about security and compartmentalization, your php pages
could be viewable by other accounts on the system. For example, many
installations run apache under the "nobody" or a "www" user. That user
must be able read the php files in your web document directory. So,
that directory and all subdirectories must have nobody or www group
ownership with the proper permissions set _and_ regular users should not
be in the www group. ACLs should be setup so that all files and
directories created in the web document directory are assigned to the
nobody or www group with the proper permissions. Some systems don't
offer this sort of ACL. I know Solaris does. Can't say about Linux,
*BSD, or Windows.
How do you get around this? Here's a discussion:
http://shiflett.org/articles/security-corner-mar2004
He's got lots of other good topics:
http://shiflett.org/articles/security-corner-sep2004
http://shiflett.org/articles/security-corner-jul2004
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
| Joe Butler 2006-05-24, 6:58 pm |
| Thanks. That was very informative. I had no idea things could be so bad.
I now know what sort of thing to be looking out for, and I'll try some of
those tricks in the articles, just to confirm the current situation.
"Michael Vilain" <vilain@spamcop.net> wrote in message
news:vilain-FC2C7A.22540923052006@comcast.dca.giganews.com...
> In article <4473bd7b$0$211$db0fefd9@news.zen.co.uk>,
> "Joe Butler" <ffffh.no.spam@hotmail-spammers-paradise.com> wrote:
>
>
> If you have a dedicated server where only _you_ have a site setup, then
> I think this is pretty safe. Unless you do something massively stupid
> with a php script that allows a page to download the php file to the
> client browser, apache built with mod_php will interpet the pages.
>
| |
|
| On Wed, 24 May 2006 02:57:31 +0100, Joe Butler wrote:
> I'm kind of new to php / apache / MySQL... and wondered what failures
> would need to occur on an apache server so that a raw php page (including
> embedded user/password) was served up to a browser instead of the expected
> generated output?
>
> And even if the user/pass was served to a browser is it a serious matter
> (assuming the user/pass was not a valid site logon)?
Anyway , you should put your usernames, DB passwords and any senesitive
information in defines in a params.inc.php file (easy administration).
Tha file should be OUTSIDE of the DocumentRoot of your site.
(a good provider should give you a FTP space that includes the
DocumentRoot as a STRICT subdirectory., so that such .inc.php files be
outside the DocumentRoot and be not readable in case of
misbehaviour/misconfiguration of the virtual server.
Johan
|
|
|
|
|