Esto deja mucho espacio para el abuso. Básicamente, se puede ejecutar cualquier inicializador estático y cualquier constructor que tenga parámetros de cadena:
Esta es una vulnerabilidad común de < algo > (por ejemplo, JSON) a los analizadores de Java, que permiten que el bloque de datos no confiable especifique los nombres de clase.
Los controladores JDBC deben registrarse en el inicializador estático . Se supone que las clases que usan métodos nativos cargan la biblioteca nativa en el bloque de inicio estático. Además, existe un patrón único de creación de la instancia en el bloque estático. Por lo tanto, es posible utilizar memoria, que no puede ser GCed. Y, por supuesto, alguien podría haber escrito código que hace otras cosas extrañas en el bloque de inicio estático.
Hay muchas clases que tienen efectos secundarios en su constructor . Por ejemplo, la creación de una instancia de FileOutputStream con un nombre de archivo como parámetro vaciará ese archivo, asumiendo que el proceso Java tiene permiso de escritura.
Esos ejemplos me vinieron a la mente al leer la publicación. Estoy seguro de que hay mucho más.
Además, debe considerar si es realmente necesario mostrar los Stacktraces al atacante. A menudo es una buena idea entregar la menor cantidad de información posible en situaciones inesperadas . En su situación, por ejemplo, hace una diferencia si FileInputStream lanza una excepción IOException o una excepción ClassCastException. Esta información podría facilitar la explotación de otra vulnerabilidad.
Como mínimo, debe verificar TrustedInterface.class.isAssinableFrom(loadedClass) antes de invocar el constructor o usar loadedClass.asSubclass(TrustedInterface.class) . Pero recomiendo encarecidamente utilizar una lista blanca de nombres de clase.