> One extra note: Connecting the Web server directly to your database
> would be a breach of security, you would in effect be providing any
> hacker a direct line into your internal network, bypassing any
> firewall/router security.
That's what I was thinking about (mostly).
When you allow access to internal data from external sources, you
*should* assume that any access can be with hostile intent.
In Jenjen's case (users access an external web server, which queries
the internal database and returns query results in HTMLized form),
this would mean that she/he has to assume that web server security
has been breached and the web server is under full control of the
attackers.
Two things may happen:
- the attackers gain access to data in the database
- the attackers send wrong responses to users querying the service
Only mutual authentication between user and database will solve the
second problem, so let's stick to the first for now.
Encrypting the data stream between web server and database will not
help in this case, as some sort of keys will have to reside on the
web server (which was taken over by The Bad Guys).
Using challange/response between server and database won't help
either ... again, The Bad Guys are already on the web server and can
fake those, too.
A private network connection (using any type of protocol) between
server and database won't help, unless the server has no way to speak
that protocol (but then, how would it send legitimate queries to the
database? :-)
What will help (at least somewhat) is
- do not allow the web server to run any SQL statement against the
database (The Bad Guys might plug in their own select statements)
but use a restricted, well defined proxy protocol to a separate
internal service with tight security, which will then access the
database.
--> Anyone will be able to access the data, but only in a (more or
less) controlled fashion.
- challenge/response between the end user and the database on every
transaction (`authenticated' state should not be kept)
--> The Bad Guys can wait for such an access and sniff the data or
can replace the web server and send their own queries using the
intercepted user's authentication.
- authenticated+encrypted links (eg. IPSEC AH/ESP) between end user
and database *not* going through the web server (remember, it has
been taken over! If it decrypts somehow, The Bad Guys are in)
--> The Bad Guys will need to either break the encryption or the
key exchage mechanism (which is supposed to be hard)
Unless you use a non subvertible channel between enduser and database,
you're prone to snooping, if not worse!
Again: Encryption between web server and database may not be enough.
\Bernhard.
|
|
