If a Java-based webpage takes a user-supplied parameter and instantiates an object using

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:

  • Enumerate classes on classpath

Edit : The attacker also can specify any number of strings passed to the constructor.

  • 3
    Ok, some more possibilities: parameter: java.io.FileInputStream This 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.
    – mhswende
    Jun 6, 2012 at 19:58

2 Answers 2


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.

  • In this case, I'm the auditor/attacker, and totally agree about stacktraces being a bad idea. I am interested in concrete examples and didn't know that 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.
    – mhswende
    Jun 8, 2012 at 10:35

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.