[PHP] Re: any security problems with this?
Ross wrote:
I have a page of functions that I include in my page head. In this I have a
function to connect. I can then just call this on each page when i need it.
Does doing it this way cause any potential security risks?
function connect() {
$host=localhost;
$user=x;
$password=xx;
$dbname=x;
$link = mysql_connect($host, $user, $password) or die ('somethng went
wrong:' .mysql_error() );
mysql_select_db($dbname, $link) or die ('somethng went wrong, DB error:'
..mysql_error() );
}
The function can only be run if you call it in one of your scripts, when
the database is needed. The user has no way of calling the function or
seeing the code, so there shouldnt be any security risks at all.
Darren
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: any security problems with this?
Unless some server config error causes that stuff to be output on the page? I tend to put such functions in a .inc file and amend the .htaccess to prevent download.
RE: [PHP] Re: any security problems with this?
Ross wrote:
I have a page of functions that I include in my page head.
In this I have a
function to connect. I can then just call this on each page
when i need it.
Does doing it this way cause any potential security risks?
function connect() {
$host=localhost;
$user=x;
$password=xx;
$dbname=x;
$link = mysql_connect($host, $user, $password) or die
('somethng went
wrong:' .mysql_error() );
mysql_select_db($dbname, $link) or die ('somethng went
wrong, DB error:'
..mysql_error() );
}
The function can only be run if you call it in one of your
scripts, when
the database is needed. The user has no way of calling the
function or
seeing the code, so there shouldnt be any security risks at all.
Unless, of course, his page of functions is named 'readme.txt' and lives in
document root.
JM
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: any security problems with this?
Dave Goodchild wrote: Unless some server config error causes that stuff to be output on the page? I tend to put such functions in a .inc file and amend the .htaccess to prevent download. If you were to include or require the .inc page and an error was to occur, it would still be printed out. All error printing should be turned off an a production server anyhow. Darren -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: any security problems with this?
Dave Goodchild wrote: Unless some server config error causes that stuff to be output on the page? I tend to put such functions in a .inc file and amend the .htaccess to prevent download. Unless some server config error causes it to ignore .htaccess. The basic rule when it comes to securing this stuff is to stick it outside the web root. That way only a monumentally stupid server admin or developer can make it possible for the average web user to get at it. Oh, hang on...! -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: any security problems with this?
On 6/12/07, Stut [EMAIL PROTECTED] wrote: Dave Goodchild wrote: Unless some server config error causes that stuff to be output on the page? I tend to put such functions in a .inc file and amend the .htaccess to prevent download. Unless some server config error causes it to ignore .htaccess. The basic rule when it comes to securing this stuff is to stick it outside the web root. That way only a monumentally stupid server admin or developer can make it possible for the average web user to get at it. Oh, hang on...! -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Just to throw this out there, you can put your information in the Apache config too and get the values from $_SERVER. This way it can be owned by root. See http://ilia.ws/files/quebec_security.pdf slide 59. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: any security problems with this?
Sure, I usually put these files outside the docroot - unless I am in some f**ked-up hosting environment that doesn't let me change the include path...
Re: [PHP] Re: any security problems with this?
On Tue, June 12, 2007 7:58 am, Eric Butera wrote: On 6/12/07, Stut [EMAIL PROTECTED] wrote: Dave Goodchild wrote: Unless some server config error causes that stuff to be output on the page? I tend to put such functions in a .inc file and amend the .htaccess to prevent download. Unless some server config error causes it to ignore .htaccess. The basic rule when it comes to securing this stuff is to stick it outside the web root. That way only a monumentally stupid server admin or developer can make it possible for the average web user to get at it. Oh, hang on...! -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Just to throw this out there, you can put your information in the Apache config too and get the values from $_SERVER. This way it can be owned by root. See http://ilia.ws/files/quebec_security.pdf slide 59. The downside of that is that something as simple as: ?php phpinfo();? will dump your password out as part of $_ENV or $_SERVER That's probably NOT a good idea in many environments, but an excellent idea in some. Security cannot be evaluated in isolation. And, of course, many users won't have access to httpd.conf, so that's not an option at all in those environments. One has to look at the Big Picture to make the final decision between: outside web tree in .php (or .inc) file in httpd.conf There are probably other arcane solutions out there but probably not very practical for most uses. I really can't recommend to keep it in the webtree with only .htaccess protecting it, personally, though many seem to think that's fine... I guess they never did anything bone-headed like: tar -cvzf export.tar httpdocs and then untar-ed it on another server, forgetting that .htaccess and other hidden files wouldn't be caught by tar that way, and then the password was just siting out there for the public to snarf... Until I ran across the images that didn't work because the ForceType in .htaccess wasn't there. So for a good 10 minutes [shudder] my database password was available on the Internet... I'm sure nobody else in the course of history will make this same bone-headed mistake. No. Never. :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: any security problems with this?
On Tue, June 12, 2007 8:08 am, Dave Goodchild wrote: Sure, I usually put these files outside the docroot - unless I am in some f**ked-up hosting environment that doesn't let me change the include path... If one finds oneself in such an environment, or one in which there *IS* no directory outside the webtree... Honestly, there are only a few thousand other webhosts out there with less f-ed up environments. Move. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: any security problems with this?
On Tue, June 12, 2007 7:47 am, Stut wrote: Dave Goodchild wrote: Unless some server config error causes that stuff to be output on the page? I tend to put such functions in a .inc file and amend the .htaccess to prevent download. Unless some server config error causes it to ignore .htaccess. The basic rule when it comes to securing this stuff is to stick it outside the web root. That way only a monumentally stupid server admin or developer can make it possible for the average web user to get at it. Oh, hang on...! Or, on a shared host, any other PHP user can write a script to fread the file and dump it out, unless your webhost has gone to extra lengths to set up different username/groups for every client, and set up separate Apache pools for each and... This gets quite expensive and drastically affects the number of clients one can cram into a single box, so it is rarely done this way in Real Life. This is not to say that you should never ever do this on a shared host; only that you ARE risking the password and everything in the DB to any other client on the same host, and you should Architect your project accordingly. E.g., using the same password as for your bank account is probably a Bad Idea :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: any security problems with this?
On 6/12/07, Richard Lynch [EMAIL PROTECTED] wrote: The downside of that is that something as simple as: ?php phpinfo();? will dump your password out as part of $_ENV or $_SERVER That's probably NOT a good idea in many environments, but an excellent idea in some. Security cannot be evaluated in isolation. And, of course, many users won't have access to httpd.conf, so that's not an option at all in those environments. One has to look at the Big Picture to make the final decision between: outside web tree in .php (or .inc) file in httpd.conf There are probably other arcane solutions out there but probably not very practical for most uses. I really can't recommend to keep it in the webtree with only .htaccess protecting it, personally, though many seem to think that's fine... I guess they never did anything bone-headed like: tar -cvzf export.tar httpdocs and then untar-ed it on another server, forgetting that .htaccess and other hidden files wouldn't be caught by tar that way, and then the password was just siting out there for the public to snarf... Until I ran across the images that didn't work because the ForceType in .htaccess wasn't there. So for a good 10 minutes [shudder] my database password was available on the Internet... I'm sure nobody else in the course of history will make this same bone-headed mistake. No. Never. :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? I figured this wasn't an option for most people, but thought I'd throw it out there. It works great at my company since we own our server to host client sites on. Hopefully nobody has phpinfo just sitting out on a production server. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: any security problems with this?
On Tue, June 12, 2007 2:41 pm, Eric Butera wrote: Hopefully nobody has phpinfo just sitting out on a production server. A quick Google: http://www.google.com/search?hl=enq=%22Zend+logo+This+program+makes+use+of+the+Zend+Scripting+Language+Engine%3A%22btnG=Google+Search will tell you that you hope in vain. In fact, Google says that there are about 151,000 production servers have phpinfo() just sitting out there... Granted, some of those will be intentional by people who know what they are doing and what they are risking. I'm guessing that with a little effort, you could even search for phpinfo() pages exposing passwords that are allegedly protected by being in root-owned httpd.conf -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: any security problems with this?
On 6/12/07, Richard Lynch [EMAIL PROTECTED] wrote: On Tue, June 12, 2007 2:41 pm, Eric Butera wrote: Hopefully nobody has phpinfo just sitting out on a production server. A quick Google: http://www.google.com/search?hl=enq=%22Zend+logo+This+program+makes+use+of+the+Zend+Scripting+Language+Engine%3A%22btnG=Google+Search will tell you that you hope in vain. In fact, Google says that there are about 151,000 production servers have phpinfo() just sitting out there... Granted, some of those will be intentional by people who know what they are doing and what they are risking. I'm guessing that with a little effort, you could even search for phpinfo() pages exposing passwords that are allegedly protected by being in root-owned httpd.conf -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? Guess that patch to prevent it from being spidered is a bit late. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: any security problems with this?
On Tue, June 12, 2007 3:51 pm, Eric Butera wrote: Guess that patch to prevent it from being spidered is a bit late. A noindex,nofollow patch for phpinfo() is a Good Idea, imho. Patch it, if it isn't already. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
