[2045] in WWW Security List Archive
Re: NON-DELIVERY of: RE: Java Hole: Web Graffiti & Covert Channels
daemon@ATHENA.MIT.EDU (Jacob Rose)
Fri May 10 10:26:45 1996
Date: Fri, 10 May 1996 08:07:49 -0400 (EDT)
From: Jacob Rose <jacob@hummingbird.whiteshell.com>
To: "ALPHA::IN%\"www-security@ns2.rutgers.edu@NTGATE@UNISG\""@ntgate.unisg.ch
Cc: www-security@ns2.rutgers.edu
In-Reply-To: <01I4IQQ4E51E00I0R9@sgcl1.unisg.ch>
Errors-To: owner-www-security@ns2.rutgers.edu
> I investigated your site, and was amazed to see the extent of this
> problem. For example, the idea that a user hitting any site on the
> web after activating the trojan horse applet, will see whatever it
> is the trojan horse wants them to see by REDIRECTING the URL
> locations to the hacker server? This is very serious if true. (The
> firewall doesn't allow in applets, so I couldn't test your examples.)
Goodness, everyone. This is not a bug in Java! You can do this with a CGI
script! For an example, see the United Artists Zippy the Pinhead active
filter. It's a very simple concept; someone visits your site, and follows
what looks like an ordinary link. Really, though, the link goes to a CGI
script which retrieves the page, then modifies it before displaying it,
also modifying each HREF inside the page to route other links through the
same CGI script. Ouila! Now anything anybody clicks on looks genuine,
but it's really going through your script.
You can even use it without altering the output, to make it look genuine
while collecting information through your script, which continues to feed
the web site new URLs and form data as though it were the user's browser.
So, really, this problem has nothing to do with Java, it's simply a
consequence of hypertext.
w h e r e
w i l l
W E
b e
,-.i n
` / ----
,' ()()1 ?
~~~ ----
