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
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
