Questo lascia un sacco di spazio per abusi. In pratica, qualsiasi inizializzatore statico e qualsiasi costruttore con parametri stringa possono essere eseguiti:
Questa è una vulnerabilità comune di < qualcosa > (ad esempio JSON) a parser Java, che consentono al blocco di dati non attendibili di specificare i nomi di classe.
I driver JDBC devono registrarsi nell'inizializzatore statico . Le classi che usano metodi nativi dovrebbero caricare la libreria nativa nel blocco di init statico. Inoltre esiste un anti-pattern singleton per creare l'istanza nel blocco statico. Quindi è possibile utilizzare la memoria, che non può essere GCed. E ovviamente qualcuno potrebbe aver scritto del codice che fa altre strane cose nel blocco statico di init.
Ci sono molte classi che hanno effetti collaterali nel loro costruttore . Ad esempio, l'istanziazione di un FileOutputStream con un nome file come parametro svuoterà quel file, assumendo che il processo java abbia il permesso di scrittura.
Questi esempi mi sono venuti in mente durante la lettura del post. Sono sicuro che ce ne sono molte altre.
Di più dovresti considerare se mostrare gli Stacktraces all'attaccante sia davvero necessario. È spesso una buona idea distribuire il minor numero possibile di informazioni in situazioni impreviste . Ad esempio, nella tua situazione, fa una differenza se un FileInputStream genera una IOException o una ClassCastException. Queste informazioni potrebbero rendere più semplice lo sfruttamento di un'altra vulnerabilità.
Al minimo è necessario selezionare TrustedInterface.class.isAssinableFrom(loadedClass) prima di richiamare il costruttore o utilizzare loadedClass.asSubclass(TrustedInterface.class) . Ma consiglio vivamente di utilizzare una whitelist di nomi di classe.