On Fri, 27 Sep 1996 14:58:59 -0400, Gene Lee <genel @
inforamp .
net> wrote
#On Friday, September 27, 1996 1:10 PM, Jenjen Song[SMTP:jsong @
amer .
net]
#wrote:
#>By using Java applets, can a database query be handled on a client machine
#>directly with a database, i.e., without passing through the Web server?
#>if YES, then can Java applets replace the function of CGI?
#>what kind of security should use for the database access to authenticate
#>which Java applet can go in and which should not?
#I'm not positive, but I believe the above (making Java connections to a
#machine other than the Web Server delivering the Java applet) was actually
#a security vulnerability which was the basis of the Netscape 2.01 --> 2.02
#patch, although that specific vulenerability dealt with DNS-based attacks
#on host-names. AFAIK, you cannot make a Java connection with any other
#machine other than the one which served you the applet. Again, I may be
#mistaken, others will surely confirm/clarify...
CERT issued advisory CA-96.05 regarding the matter. The vulnerability was
in (at least) V1.0 of Sun's JDK and V2.0 of Netscape Navigator, and probably
any ports derived from them (notably the OSF's.) As far as I know, it's been
fixed everywhere.
The problem was that Java applets are supposed to be able to support the
security model of "don't allow downloaded applets to connect to any system other
than the one that they were downloaded from. This policy is probably a
reasonable comprimise for those that want to use Java's strengths to enhance
their web-browsing experience, but don't want to open themselves up to worm-like
attacks from trojan java applets.
I've documented a good chunk of what happened, and when, at
http://www.aztech.net/~steve/java/ My original warnings predated the CERT
advisory by about a month and a half, and the Princeton teams' by several
weeks.
FWIW, Some browsers, allow the end-user to select other policies, including
"I don't care, let the applet do whatever it wants."
To respond to the origial query: What you probably need to do is set up a
database proxy server on the WWW machine(s) that relays requests from the
Java applet to your DB server.
Once the applet has left your WWW server, there aren't any good measures that
you can take to ensure that it hasn't been modified, so your proxy server and/or
DB server need to have the capability of filtering out dangerous operations such
as database updates and access to restricted information.
My vote would be to authenticate each transaction (the authentication
information can be cached by the applet, but passed along for each transaction)
and to encrypt all communications between client applets and (at least) the
DB proxy.
Apologies to those of you who might feel that this wasn't related to firewalls,
I did try to stay on-topic.
--
Steve
|
|
