Re: [GENERAL] cgi with postgres - Mailing list pgsql-general

Peter Eisentraut wrote:
>
> On 2000-01-14, Alfred Perlstein mentioned:
>
> > > issue: how to secure cgi's that access postgres
> > >
> > > problem: passwords for postgres database are stored
> > >       in plain text in scripts. (lets assume, perl,
> > >       not a compiled language)
> > >
> > > points:
> > >     make cgi dir 711
> > >     big deal, they can get the name of the file
> > >     from the web, and copy it.
> >
> > how about sourcing a conf file that's in a 700 dir?
>
> Security through obscurity is little security indeed.

1. If anybody can read your web page, well, then, you
would need to make a "reader" account in your DBMS.
That way, anybody can get the username and password,
and it may not matter. As long as this user only has
perms to the database (as in, no shell, no other perms
on the box), it's about as secure as any other service
that passes user/pass over the 'net in readable form....

2. Deeper accounts can be controled via .htaccess,
via apache. Again, this has holes, but now the potential
hacker has two hoops to jump through.

3.  Access to specific virtual hosts can be controlled
via packet filtering, for more secure connections to
an admin page. Yet another hoop.

4. Security through obscurity _can_ be of great value,
if your threat scenario is primarily individuals who
wouldn't know where to look, or what to look for. If
your threat scenario includes individuals who do have
that skill level, yup, it's not that much protection.
It's like hiding the lock on a door. It's provide security
against lock pickers, but no security against the guy
with a sledge hammer. A hoop for those with little
imagination or knowledge....

Security is not something you can program, buy, or build,
it's a mindset.  For each hoop you require users to jump
through, it's another hoop for a  hacker to jump through.
Since you _will_ be hacked, by somebody, eventually, you
have to balance the level of security with the level of
*value* it offers. For example, disabling cgi's helps quite
a bit, from a security standpoint, but it makes users
cranky. Is that crankyness worth the security of removing
all cgi's? If your transactions are worth several thousand
a day,  of course it is.  Are your databases so valuable that
you don't want to allow users write access? Don't put
them on writable media.  Do you need to guarantee that
only specific users have access to specific transactions
in a specific database? Then cut the cord on internet access,
entirely.

Back to the original question:
>issue: how to secure cgi's that access postgres

For *absolutely secure* environments, remove the cgi's, erase
the database, take the box in back, and burn it, then crush it
into little bits, then sprinkle the ashes over no less than a
300 km radius, in non-equal distribution. ;-)

For slightly less security, you should follow two basic, old-school
rules: Something you know, and something you have. For each level
of security, you should require at least one measure of each. For
vanilla access, they would *know* where the server is, and *have* one
pasword. More secure: They would *know* a non-htttp-linked, non-listed,
CGI file to access, and *have* a specfic IP they are coming from. Next,
maybe knowing another access code, and having a stored cookie
which is checked against... and on, and on, so by the time they have
a high level of access, they've managed to use passwords, RSA keys,
their IP, a fingerprint, an eyeball scan..... but it's still not quite as
secure as destroying all of the data. :-) Up to that point, it's just
a matter of making enough hoops to jump through that it keeps
most of your threat assesments at bay, and using them in an
_additive_ fashion.

Additive? Well, a retinal scan and password combo is only
two hoops, but a retinal scan, and password, and RSA key, and
initiating IP, and facial scan, and tunneled session, is 6 things
a cracker has to break, in the right order, in order to get in.  So
you have to balance how much security you need versus how many
hoops you want to make, as setting up 20+ boxes, in series, to
use a SELECT statement, may be a bit absurd for your application.
:-) I've done it for giggles, performance was not the best, but
it worked well enough that it was pretty much impenetrable
from over the internet. Only took two or three minutes to pass
a select staement through, and half an hour or so to return
a few rows... <g>

HTH,
-Ronabop