On Date: Thu, 29 Aug 1996 14:46:20 +0200
From: Bernhard Schneck <Bernhard_Schneck @
GeNUA .
DE>
Subject: Re: Firewalls-Digest V5 #484
¦
¦ > 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 challenge/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.
I was thinking as you, not allowing SQL to be executed on the Webserver. Unless
your applications are very simple, that your are writing an API or a protocol
for each application. This is job security, but may not be scaleable. The other
thing I hate about this is that it starts looking like "security through
obscurity" again. Is there a pointer to a more information on this subject?
Something else I ran across the other day:
Vendor A has developed a search/retrieval/server product. If I have content
that I think users will pay for, I install the server product behind a FW to
protect that investment in the content. Now we haven't talked about how to
interface to the payment switch yet....
I install Vendor A's CGI on my W3 server outside the FW and install a plug-gw on
a high numbered port to only accept incoming connects from my W3 server bound
for Vendor A's server. I find out that Vendor A's CGI is only a IP gateway from
the client to the Vendor A's server (there is nothing to the CGI, open socket,
connect, print STDIN to STDOUT). This tells me that the API/protocol must be in
the HTML form, this application is probably very simple.
How secure is a CGI like this? (Vulnerablity: W3 server security)
What I like about this is that there is no information (other than the
connecting address and the embedded API/values in the HTML form) on the W3
server about the back-end service. It appears to be vulnerable to denial of
service attacks (anyone can POST to this CGI and the W3 server will contact
Vendor A's server thru the FW, consuming resources on the W3, FW and Vendor A's
box). Your thoughts?
If I use a Secure/Commerce W3 server, will SSL or SHTTP be foiled by Vendor A's
CGI approach, but doesn't this mean that Vendor A's server would have to support
SSL and SHTTP also? If it does support one or both, there application starts to
look a lot like a modified secure W3 server doesn't it?
Now continuing on with this discussion: If the W3 server is taken over, it can
talk to only one port on the FW bound for Vendor A's server. We are left with
placing trust in Vendor A's application team for our network security. If this
application is secure, why is it behind the FW? They seem to be following the
guide lines set forth by the NCSA Web Site Certification criteria.
¦
¦- - 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.
¦
|
|
