Hi all,
I actually combine both of these suggestions. I have my passwords stored
seperately. In fact, I tend to put ALL database functions in one perl module
or PHP include file outsite the docroot. It adds an extra level of
abstraction when I'm writing my CGI/PHP code. It also means that if I
change anything in the database - move machines, change the schema, move to
mysql (god forbid) - I only have two files to edit.
I then use the firewall approach too. Most firewalls have three zones; green
trusted, amber DMZ, and red public. I have my firewall configured so that I
only allow port 80 from red to amber, and 5432 from amber to green.
Gary
On Wednesday 05 September 2001 3:13 am, Gunther Birznieks wrote:
> At 10:34 AM 9/4/2001 +0000, Mel Matsuoka wrote:
> >At 07:20 PM 09/04/2001 +0100, yahoo wrote:
> > >Hi all,
> > >I'd like to find out peoples opinion on the following.
> > >
> > >If you have a perl cgi script which accesses a database, are there any
> > >security issues with having the DBI connection details in the perl
> > > script (rather than, say, an external file not in the document root -
> > > is this better?)?
> >
> >My general policy regarding things like this is, the more paranoid you are
> >, the better :)
> >
> >Having password information embedded in a publicly accessible document
> > such as a CGI script is playing with fire, as far as I'm concerned. There
> > may be a time when you least expect it when someone (or you) screws up
> > the webserver config, and accidentally allows cgi-scripts to be sent out
> > as plaintext documents. Ouch.
> >
> >That's why for all of my Perl and PHP scripts, I "include" the database
> >server connection details using an include file which is saved outside of
> >the webserver root. Of course, this isn't 100% secure, since anyone who
> > has local filesystem access to the server can still get at the
> > information, but then again, if someone has achieved that level of
> > access, you have bigger problems than worrying about your DBI include
> > files and CGI scripts ;)
>
> You can even go one step further, in banking practices, you typically never
> access the database directly anyway from a CGI. Instead you have a
> multi-DMZ (well DMZ isn't the exact right term) but multi-partitioned
> architecture so that if someone does break into the web server they still
> do not have direct access to the database.
>
> Something like
>
> Internet -> Firewall -> WebServer -> Firewall -> App Server -> FW -> DB
> Server
>
> Each major server essentially being controlled by dual homed hosts on
> separate subnets with the network interface on the firewall only
> controlling a single direction of traffic to the server in question.
>
> Of course, most normal people can't afford this and make do with chrooting
> and running on a dedicated host with a linux IP Tables firewall on one
> single machine even if they go dedicated.
>
> As an aside, eXtropia has an open source toolkit which allows this higher
> level of indirection without any application logic programming. The
> abstraction is called Extropia::DataSource (written in Perl) and for this
> abstraction we have DataSource::File (For flat file) and DataSource::DBI
> (for DBI).
>
> But if you require stronger security (like the above approach), you can use
> our DataSource::SOAP which talks to a Java Servlet container (as the app
> server eg Jakarta-Tomcat) running code from the Apache SOAP Project as the
> infrastructure and then on top of it, our
> com.eXtropia.datasource.soap.SoapDataSource package wrapped around our
> com.eXtropia.datasource.SecureDataSource API.
>
> The SecureDataSource API allows you to restrict permissions in a way very
> similar to how permissions are restricted using grant statements on SQL and
> in addition the password to the database is stored in the middleware server
> (breaking into the webserver does not grant access). The other cool thing
> about this is that most servlet containers also handle JDBC connection
> pooling for you (an additional performance boost which makes the
> performance lag introducing a middleware server more reasonable).
>
> Of course, you can go even farther than this. Obviously the best middleware
> server will contain the equivalent of stored procedures which tightly
> restrict in a typed concept, what sort of data may pass into it and out of
> it (as opposed to essentially arbitrary queries).
>
> Later,
> Gunther
--
Gary Stainburn
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
