Re: hiding passwd in cmdlines that appear in the process list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/30/06, Richard Lynch <ceo@xxxxxxxxx> wrote:

On Thu, November 30, 2006 9:59 am, Edwin Barrios wrote:
> I don't know if my solution is better or not. but in one of my
> programs i
> had to make a backup online then my solution was to use shell vars to
> put
> important information like db_password . When we use putenv function
> those
> var only exists on the current shell and on its subshells. In your
> case the
> following code :
>
> <?php
>   putenv("DBNAME=".DB_NAME);
>   putenv("DBUSER=".DB_USER);
>   putenv("DBPASSWD=".DB_PASSWD);
>
>   system('mysql -h localhost --user=$DBUSER  --password=$DBPASSWD -D
> $DBNAME
> < "/my/import/script.sql" 2>&1');
>
> ?>

This solution, as most good ones, has pros and cons:

Pro:
Does keep the password from being exposed in the normal course of
operations.

Con:


This is not triue because a shell vars declered on a shell is only exposed
to its subshells, that means that only exec's and system functions calls
into the php itself resive those vars declared into the php !

You can see this argument in the following code

?php
 error_reporting(E_ALL);


 echo "OLD <pre>";
 system("env");
 echo "</pre>";

 putenv("DBNAME=sidf");
 putenv("DBUSER=p");
 putenv("DBPASSWD=p");

 echo "NEW <pre>";
 system("env");
 echo "</pre>";

?>

and reloading these a couple of times.

A simple debug statement to dump out all of ENV / $_GLOBALS will
expose the password.

So you have to ask yourself if you and all your employees and all the
scripts you ever install, including any forums etc, are for sure never
ever going to dump that password out in an attempt to debug something
else.

For a solo developer or even a small team, with all custom hand-coded
stuff, this is pretty easy.  But once your application blows up and
you have a larger team, or you start caving in to client demands to
install badly-written forums/carts/blogware, you are open to a
potential security hole which:
  has two seemingly unrelated contributing causes
  the two causes can be years apart in time
  both are simple straight-forward "obvious" Right Things to do

So you have to weigh carefully the Risks, and DOCUMENT what you did
and DOCUMENT what *not* to do in the future to expose this sensitive
data.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux