applet security issues

[Matthijs Blaas]

Hi All!

I found that it's possible to replace a cached applet by another one and run
that new applet instead of the original one

I decompiled my cached applet, changed some things, recompiled it and
renamed it to the cached name again (Test.jar-3eaeec54-5a78075f.zip). What I
though & hoped was that the JVM would detect that the cached file had
changed compared to the original one at the webserver (by checking the hash
3eaeec54-5a78075f). Obviously thats not the case. I was thinking signing the
jar file might just do the trick? Or would that simply throw the user an
warning message that the content doesnt match the signed hash?

Anyway I have a couple more questions concerning (signed) applets:

1.) If I sign my applet will this always popup a warning to the user asking
if they trust it (even if I use a real certificate)?

2.) Is there any way of making an unsigned applet instanciate a class file
from another jar? (I have a loader class that needs to load a library jar
and a game jar which uses that library). The loader needs to excecute the
game from the gamejar, this game needs methods from the library so it needs
to be in its classpath... I thought I needed to have a classloader to do
this. Currently Im doing this without the loader: I put all the jars in the
archive param (so the AppletClassLoader will tell the game where to find
them?). This works ok, but if I want to download the game jar & library jar
from the loader, is there a way I can start the game in an unsigned applet?

3.) Is it possible to cache files I download in my applet?

I'd greatly appreciate if anyone could help me with any of these questions!

 

[Andrew Thompson]

..I have a couple more questions concerning (signed) applets:

1.) If I sign my applet will this always popup a warning to the user asking
if they trust it (even if I use a real certificate)?

If the user chooses to accept 'all further content' from the
certificate signer, no. Otherwise, yes. If they refuse it,
your applet will still appear*, but it will constrained by
the default applet security sandbox. * Unless you were silly
enough to invoke security exceptions during the GUI construction.

2.) Is there any way of making an unsigned applet instanciate a class file
from another jar?

Add the Jar of the other class to the archive param and it's classes
can be found using getResource(name)

..I thought I needed to have a classloader to do
this.
No.

...This works ok, but if I want to download the game jar & library jar
from the loader, is there a way I can start the game in an unsigned applet?

Yes. So long as you load the classes via URL, and never try
to access or use any File object, that will be fine.

3.) Is it possible to cache files I download in my applet?

The browser will do it automatically in an haphazzard fashion according
to the its current settings. But once you have a Jar'd applet you can
install it via JWS and the components (class Jar's or toher resources)
will only be updated if they have changed.

I'd greatly appreciate if anyone could help me with any of these questions!

No worries.

 

[Tim Tyler]

I found that it's possible to replace a cached applet by another one and run
that new applet instead of the original one

You mean if the attacker has direct access to the machine?

 

[Matthijs Blaas]

2.) Is there any way of making an unsigned applet instanciate a class

Add the Jar of the other class to the archive param and it's classes
can be found using getResource(name)

That's the way Im doing it now. Problem with this method is, that the JVM
will wait for all jar's in the archive param to be loaded. What I'd like is
a compact loader class that display's a loading screen and loads &
instanciates the game jars. Unfortunaly Java webstart is not an option for
me, I have to stick to crappy JVM 1.1 compatibility...

Yes. So long as you load the classes via URL, and never try
to access or use any File object, that will be fine.

You mean plain class files?
But what if the class I want to instanciate resides in a jar (game jar) and
depends on another jar for certain method calls (library jar)? I could
download these two jars over an urlconnection, no problem. I also believe
the java api offers functionality to look in jar/zip files, but will I be
able to instanciate the game mainclass from the gamejar through the loader
class? What I thought is that I need an classloader to tell where the game
can look for class files it needs (ie: a class it extends from the library
jar which I also downloaded). Will it know where to find it when I simply
download the two jars? I thought I had to add them to the classpath or
something (like what happens if I add them in the archive tag). Thats why I
thought I needed to do something with a classloader.

The browser will do it automatically in an haphazzard fashion according
to the its current settings. But once you have a Jar'd applet you can
install it via JWS and the components (class Jar's or toher resources)
will only be updated if they have changed.

Bummer, JWS sounds like a nice thing, but thats no option for me. Maybe I
can do something with the cache option in the URLConnection class...

No worries.

Thanks again!

 

[Matthijs Blaas]

I found that it's possible to replace a cached applet by another one and

You mean if the attacker has direct access to the machine?

Well, local on the client:
If someone downloads my game applet, replaces the cached game applet with
his own modified version in his Java cache, browses back to my website and
plays the game again his modified version will be excecuted by his jvm. The
jvm doesn't seem to check if the currently cached version matches the
version on the server.

 

[Andrew Thompson]

That's the way Im doing it now. Problem with this method is, that the JVM
will wait for all jar's in the archive param to be loaded.

If you use webstart, you can specify the download of resource
jars as 'lazy' - downloaded when first requested.

..What I'd like is
a compact loader class that display's a loading screen and loads &
instanciates the game jars. Unfortunaly Java webstart is not an option for
me, I have to stick to crappy JVM 1.1 compatibility...

You can offer the same applet to a 1.1 VM and simply add
the resources to the 'archive' parameter. While the user
is waiting for the jars to be downloaded, throw up a Dialog
suggesting they might consider upgrading to the genuine, this
millenium, Sun Java Plug-In.

You mean plain class files?

Yes! My 'Launcher' applet does just that..

But what if the class I want to instanciate resides in a jar (game jar) and
depends on another jar for certain method calls (library jar)? I could
download these two jars over an urlconnection, no problem. I also believe
the java api offers functionality to look in jar/zip files, but will I be
able to instanciate the game mainclass from the gamejar through the loader
class? What I thought is that I need an classloader to tell where the game
can look for class files it needs (ie: a class it extends from the library
jar which I also downloaded). Will it know where to find it when I simply
download the two jars?

...stop, Stop, STOP!
Maybe this will answer some questions for you.
<http://www.physci.org/launcher.jsp>
That is the launcher applet, each link leads to the
Launcher applet, ready to open the frame, and the
source code used for the frame. Try it.

It is an unsigned applet. Java 1.1 compatible (though
any of the launched applications may not be).

How is it done? Let the code do the talking.

Bummer, JWS sounds like a nice thing, but thats no option for me.

Stop saying that. It very much is.

..Maybe I
can do something with the cache option in the URLConnection class...

That will not work between JVM instances, let alone shut-down,
start-up.

Thanks again!

ditto.

Reconsider the entire JWS option, you can offer the applet
for 1.1 users, and JWS for the rest.

 

[Matt Humphrey]

Well, local on the client:
If someone downloads my game applet, replaces the cached game applet with
his own modified version in his Java cache, browses back to my website and
plays the game again his modified version will be excecuted by his jvm. The
jvm doesn't seem to check if the currently cached version matches the
version on the server.

Naturally you wouldn't care if the user ran any kind of game different from
yours but that did not affect your internet activity so the real problem is
that your game applet keeps some kind of score or other data on your server
and you would like to ensure that only your applet access and modify that
data. There is no solution to this problem for publically available games
(e.g. those that do not require authentication.) A client can run whatever
code the user likes and there's nothing you can do about it. Regardless of
whether they hack your applet directly via the browser cache or if they
simply copy it and run it directly, you have no way to authenticate the
communication from that applet to your website and they are free to spoof
that communication in any way they can try. Bottom line: you cannot rely on
the client to perform security checks for you.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Matthijs Blaas]

You can offer the same applet to a 1.1 VM and simply add

the resources to the 'archive' parameter. While the user
is waiting for the jars to be downloaded, throw up a Dialog
suggesting they might consider upgrading to the genuine, this
millenium, Sun Java Plug-In.

You mean a message in the HTML? Because the problem is the jvm
won't excecute any class I put in the archive tag till every class/jar is
loaded. Is it a jws option to offer the applet version if jws is not
detected?
*I only found some javascript to detect that.

Also, I believe jws doesn't allow its applications to be run embedded in
the html like an applet? That would cause problems with the current
webdesign...

..stop, Stop, STOP!
Maybe this will answer some questions for you.
<http://www.physci.org/launcher.jsp>
That is the launcher applet, each link leads to the
Launcher applet, ready to open the frame, and the
source code used for the frame. Try it.

It is an unsigned applet. Java 1.1 compatible (though
any of the launched applications may not be).

How is it done? Let the code do the talking.
<http://www.physci.org/codes/display.jsp?fl=/Launcher.java>

I know about instanciating plain class files.
*I even used your launcher example a while ago to try some things out
The problem I have is with jar files. In order to be able to search /
instanciate a class from a jar it has to be in the classloaders classpath.
When you put example.jar in the archive tag the applet classloader will add
to the classpath. Unfortunaly it's a protected method so I can't invoke it
again
to add my new jar's on the fly... I think I'd need to sign my applet and
create a
new classloader for these jars but that'd throw an nasty popup asking people
if
the trust it. So I better stop whinning and keep using the archive tag ;-)

 

[Matthijs Blaas]

There is no solution to this problem for publically available games

(e.g. those that do not require authentication.) A client can run whatever
code the user likes and there's nothing you can do about it. Regardless
of
whether they hack your applet directly via the browser cache or if they
simply copy it and run it directly,

It's impossible to run it directly and upload a score as it needs an server
sided game session in our case. For that there is somekind of
authentication,
for a user to upload a score he must have registered an account with us and
must be logged in. The server must have created an session which is valid
for
that game played.

you have no way to authenticate the communication from that applet to your
website and they are free to spoof that communication in any way they can
try.
Bottom line: you cannot rely on the client to perform security checks for
you.

True, but I thought there might be some common way of making it very
difficult
to tamper with the applet, as there must be more applications that want to
make
that as difficult as possible... I know obfuscating is one, but maybe there
is a logic
way of doing this too... for example force it to be never cached:
make a small loader class that each time gets downloaded from another url (a
variable url like:
/123ab/loader.class, or 123cd/loader.class). That way the jvm will never use
an
cached version. Problem is that such methods are a bit clumsy, take a lot of
unnecesary
bandwidth & cache on the client. It's not hackproof for sure, but will make
it harder.

 

[Matt Humphrey]

It's impossible to run it directly and upload a score as it needs an server
sided game session in our case. For that there is somekind of
authentication,
for a user to upload a score he must have registered an account with us and
must be logged in. The server must have created an session which is valid
for
that game played.

Having an authentication mechanism is a good start. Keep in mind that it's
not so much the applet that is being replicated but the communications
protocol. If they can observe the applet and get the session id, etc, they
can manufacture new statements against your server.

True, but I thought there might be some common way of making it very
difficult
to tamper with the applet, as there must be more applications that want to
make
that as difficult as possible... I know obfuscating is one, but maybe there
is a logic
way of doing this too... for example force it to be never cached:

If the applet runs on their machine they can always get it by a direct GET
request. It really is just a matter of deciding how difficult you want the
process to be.

make a small loader class that each time gets downloaded from another url (a
variable url like:
/123ab/loader.class, or 123cd/loader.class). That way the jvm will never use
an
cached version. Problem is that such methods are a bit clumsy, take a lot of
unnecesary
bandwidth & cache on the client. It's not hackproof for sure, but will make
it harder.

I've looked at encrypted custom loaders and it doesn't seem to make things
that much more difficult. The top level of the applet must be downloadable
and from there it can be disected and re-wrapped in order to provide access
to the embedded classloader. It seems like you're already doing as well as
you can.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/