On Fri, 5 Feb 1999, Lincoln Stein wrote: > The main issue, I think, is information leakage between the Web site > that uses the applet and the applet's author. Consider this scenario: > a Bad Guy puts out a compiled applet in the public domain that seems > to do something innocent like chart business graphics. Some company > then picks up this applet and uses it to display its confidential > business plan to authorized hosts in branch offices. Unbenknownst to > the company or the branch office, the applet has actually opened a > listen socket, has accepted a connection from the applet's original > author, and is currently transmitting the confidential information to > an untrusted host! the missing information here that this scenario doesn't contain, is that the applet's original author must know the host that the applet is running on, in order to connect to the applet. This information can be easily sent by the applet to the bad guy by making a http request - hiding information in the URL. We implemented this type of communication, allowing a java applet to communicate with an arbitary server (needed access to files on a different machine than the HTTP server) however, all the confidential data can be sent in this manner. A more pertinent problem is that Java can dynamically load classes through a socket. The new code might exploit a security hole which was unknown at the time the applet was written - a company might assume that because an applet was written _before_ a security hole was found, it cannot exploit this hole, and therefore the company doesn't need to fix the hole. (i know, bad logic, but ...?) Tim http://stl.qucis.queensu.ca/~wright When in doubt, doubt. It's what set's us apart from the animals. (If you define animals as Politicians and Technocrats)
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:33:17 PDT