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

* Ron Chmara <ron@Opus1.COM> [000116 16:18] wrote:
> 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....

All these options don't take into account that perhaps you don't
want people _on the same box_ to be able to even read arbitrary
things from your database.  Sure you can protect the tables from
modification via postgresql's internal ACL system, however what
if you wish to deny read access as well?

For this you need a file with an ACL prevents other _local users_
from reading it.

This is _not_ security through obscurity, this is basic ACL control.
Again, figure a way to 'protect' your shadow password database
without relying on an external auth server.

> 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>

I'd say these are good examples of security through absurdity,
interesting to research, but as implied from the responce times
of this system: not usable.

sorry, :)
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]