How to prevent connection string from being public?

[James Henson]

I'm using a MySQL database from within some Perl cgi's. To
make the connection, I have to supply the username/password
in the connection string. This info is readable for anyone
that can view my code, e.g. all other users that can access
the webserver directly, or by some possible exploit.

How can I avoid this? I can't have my own webserver, obviously.

I have set up the database server so it only accepts connections
from the webserver box, but that doesn't help with the above
problem.

Any pointers?

James

 

[ctcgag]

I'm using a MySQL database from within some Perl cgi's. To
make the connection, I have to supply the username/password
in the connection string. This info is readable for anyone
that can view my code, e.g. all other users that can access
the webserver directly, or by some possible exploit.

How can I avoid this? I can't have my own webserver, obviously.

I made my own module that has the connection string. It's a simple
function that returns the connection. That way I only need to
change one thing when the connection string changes. However,
that doesn't solve your problem, it just shifts it from hiding
many things to hiding one thing. If Apache (assuming that's our server)
is to run your scripts, it needs to see them. So this is an
Apache and/or system administration problem, you'll have to discuss it
with your Apache and/or system administrator.


Xho

 

[James Henson]

I made my own module that has the connection string.

I currently have it in an included piece of Perl, as
this makes setting up the app a lot less time consuming.

However, that doesn't solve your problem, it just shifts it from hiding
many things to hiding one thing. If Apache (assuming that's our server)
is to run your scripts, it needs to see them.
So this is an Apache and/or system administration problem, you'll have to
discuss it with your Apache and/or system administrator.

She doesn't know the answer either. The cgi's should be readable,
so the user/passwd is exposed. I'll try to find another admin.

Thanks,
James

 

[James Willmore]

I'm using a MySQL database from within some Perl cgi's. To
make the connection, I have to supply the username/password
in the connection string. This info is readable for anyone
that can view my code, e.g. all other users that can access
the webserver directly, or by some possible exploit.

How can I avoid this? I can't have my own webserver, obviously.

I have set up the database server so it only accepts connections
from the webserver box, but that doesn't help with the above
problem.

Any pointers?

This _appears_ not to be a Perl issue. If the username/password is
passed as a parameter in a CGI script, the simple solution is to use
an SSL connection. If the username/password is in a file that all on
the webserver have shell access to, there's an issue of file
permissions to be addressed.

If you post some code, maybe this will (dis)prove the above
statements.

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
In 1880 the French captured Detroit but gave it back ... they
couldn't get parts.

 

[Vorxion]

I'm using a MySQL database from within some Perl cgi's. To
make the connection, I have to supply the username/password
in the connection string. This info is readable for anyone
that can view my code, e.g. all other users that can access
the webserver directly, or by some possible exploit.

How can I avoid this? I can't have my own webserver, obviously.

I have set up the database server so it only accepts connections
from the webserver box, but that doesn't help with the above
problem.

Any pointers?

It's not possible. To some degree, you're exposed by the need for having
it in either the script or in a config file.

Assuming a *nix platform, make sure you're running it as a user -other-
than the one httpd runs as (try cgiwrap for instance), make sure the
scripts are mode 0700 and configs are mode 0600.

That's about as good as you'll get given the nature of the beast.

You -can- do things like custom-encode them, or hard-code packed strings of
the data and then unpack them or custom-decode them at execution. This is
only an added layer of obscurity if someone really analyses your code to
find out how it's derived. It simply keeps them from being there in
plaintext--that's all.

Basically, if you take the user/mode steps listed above, the one thing you
have to worry about is someone breaking that particular account. If
someone cracks the entire system, you have -far- bigger worries than your
mysql password. (It's -really- easy to cripple a system entirely to
the point it won't boot without a good hunt or a reinstall.)