Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
If a Java-based webpage takes a user-supplied parameter and instantiates an object using
Class.forName(parameter)What's the worst possible consequence?
The attacker does obtain stack traces. After the object is instantiated, it is cast to a proprietary class, so it will throw exception at that point.
Example consequence:
Edit : The attacker also can specify any number of strings passed to the constructor.
This leaves a lot of room for abuse. Basically any static initializer and any constructor which has string parameters can be executed: This is a common vulnerability of <something> (e. g. JSON) to Java parsers, that allow the untrusted data block to specify the classnames.
JDBC drivers are supposed to register themselves in the static initializer. Classes that use native methods are supposed to load the native library in the static init block. Furthermore there is a singleton anti-pattern of creating the instance in the static block. So it is possible to use up memory, that cannot be GCed. And of course someone might have written code that does other strange things in the static init block.
There are many classes which have side effects in their constructor. For example instantiating a FileOutputStream with a filename as parameter will empty that file, assuming that java process has write permission.
Those examples came to my mind while reading the posting. I am sure there are a lot more.
Furthere more you should consider whether showing the Stacktraces to the attacker is really necessary. It is often a good idea to hand out as little information as possible in unexpected situations. In your situation for example, it does makes a differences if a FileInputStream throws an IOException or a ClassCastException. This information might make it easier to exploit another vulnerability.
At the very minimum you must check TrustedInterface.class.isAssinableFrom(loadedClass) before invoking the constructor or use loadedClass.asSubclass(TrustedInterface.class). But I strongly recommend to use a whitelist of classnames.
FileOutputStream actually created/emptied files just by being constructed, so +1 for that! Any more examples? Being able to overwrite files is pretty nasty, depending on configuration. Overwriting configuration files could e.g. enable server-side scripts to be served as plain text, and overwriting .htaccess files could also bypass restrictions.
Class.forName() by its self is not really a sink. This can be a vulnerability, but that depends on how the class object returned by this method call is used.
The use of Class.forName() can lead to Unsafe Reflection in that an attacker may be able to instantiate a class of his choice and then invoke a method call on the resulting object.
parameter: java.io.FileInputStreamThis will throw an exception if the init-string does not exist on the filesystem, which will make it possible to determine the location of arbitrary files.