Hi,
On Friday, March 7, 2003, at 02:19 PM, Daniel Germain wrote:
Hi,
I'm currently performing some tests with an applet
referenced in an enhydra page.po and I found
accidently that all the classes from my backend
enhydra application can be downloaded over the internet
if you know what to look for.
As an example, if you take the enhydra demo at the following
url:
http://enhydra.enhydra.org/server/demos/welcome/Welcome.po
and that you are able to guess the presentation prefix
Server.PresentationPrefix = "com/lutris/appserver/welcome/presentation"
you can download the Welcome.class from the following url
http://enhydra.enhydra.org/server/demos/welcome/com/lutris/appserver/
welcome/presentation/Welcome.class
This is not limited to presentation classes. Business classes and data
classes can be downloaded as well, so you do not really need to know
the presentation prefix if you can guess the package name.
E.g. with chat.business.Message
http://enhydra.enhydra.org/server/demos/chat/chat/business/
Message.class
Using a decompiler I was able to recover an equivalent source for
Message.java.
From what I'm understanding these files can be downloaded as easily
as any gifs that are put in the application jar (e.g. welcome.jar).
So the workaround would be to put these files outside the jar
but within the system classpath, or script classpath? Any other
options or patches?
By the way using comma separated classpath jar files does not
seem to work in the conf file.
#
# Comma separated CLASSPATH directories and files used by this
application.
#
Server.ClassPath[] = "C:/Enhydra5.0/examples/demos/lib/welcome.jar"
Daniel
The way enhydra happily serves up the class files is disturbing. Glad
you mentioned it, as I hadn't noticed it before. One fairly easy
workaround is to implement a Filter that sends a redirect or error page
when a class file is requested. Hopefully a better fix will be added to
enhydra.
I've never had problems specifying a comma separated list for
Server.ClassPath in the conf file.
Scott
| 