Evita il codice dannoso durante il caricamento dinamico delle classi con ClassLoader

2

Sfondo

Uno dei vantaggi dei componenti disaccoppiati nei sistemi è la possibilità di estendere il sistema senza dover toccare il codice esistente.

A volte non hai nemmeno bisogno di ricompilare il vecchio codice perché puoi caricare dinamicamente le classi dal disco in questo modo:

clazz = Demo.class.getClassLoader().loadClass("full.package.name.to.SomeClass");

Ciò consente una sorta di architettura plug-in di sorta (dare o prendere).

Domanda

Come si impedisce l'esecuzione di codice dannoso durante il caricamento dinamico di una classe dal disco utilizzando ClassLoader ?

    
posta Tulains Córdova 12.07.2013 - 14:00
fonte

3 risposte

4

Questa domanda è una duplicazione di questo su Stack Overflow.

Detto questo, "architettura dei plugin" non sembra qualcosa in cui puoi difendere in modo significativo dal codice dannoso, poiché dovrà interagire strettamente con il resto del sistema. È un gioco che non puoi vincere, quindi non giocare. Accetta semplicemente che i plug-in possono fare tutto ciò che vogliono nel tuo sistema, quindi devono essere installati solo plugin attendibili.

    
risposta data 12.07.2013 - 14:25
fonte
3

Quando si desidera evitare il codice dannoso, la domanda è "come si definisce il comportamento dannoso"? Ci sono un'infinità di cose che un plugin può fare e che non è nel miglior interesse dell'utente, e proibire a tutti sarebbe un esercizio inutile.

Invece di mettere in blacklist le funzionalità vietate, dovresti preferire la funzionalità di whitelist consentita.

Quando vuoi limitare i plugin a funzionalità limitate, non dovresti implementarli in Java. Dovresti piuttosto usare un linguaggio di scripting. Interfacce Java abbastanza bene con i linguaggi di scripting . Per impostazione predefinita, un linguaggio di scripting non può fare nulla, ma è possibile esporre selettivamente pacchetti, classi e oggetti al motore. Questo ti dà un controllo preciso su ciò che il motore di scripting può e non può fare.

    
risposta data 12.07.2013 - 16:13
fonte
0

Richiedere che i file da firmare possano aiutare un po '.

Ecco un articolo di Wikipedia sulla firma JAR.

Ecco la sezione dell'articolo wikipedia che è significativa ...

Developers can digitally sign JAR files. In that case, the signature information becomes part of the embedded manifest file. The JAR itself is not signed, but instead every file inside the archive is listed along with its checksum; it is these checksums that are signed. Multiple entities may sign the JAR file, changing the JAR file itself with each signing, although the signed files themselves remain valid. When the Java runtime loads signed JAR files, it can validate the signatures and refuse to load classes that do not match the signature. It can also support 'sealed' packages, in which the Classloader will only permit Java classes to be loaded into the same package if they are all signed by the same entities. This prevents malicious code from being inserted into an existing package, and so gaining access to package-scoped classes and data.

Developers can obfuscate JAR files so that a user of the JAR file doesn't get much information regarding the code it contains, or to reduce its size, which is useful in mobile phone application development.

Normalmente non collegherei solo citando Wikipedia. Nessuno aveva ancora menzionato questa soluzione, ma non è nella mia area di competenza. Se qualcuno con un po 'di esperienza in più su Java darebbe una risposta dettagliata, mandami un commento e rimuoverò questa risposta.

    
risposta data 12.07.2013 - 14:45
fonte

Leggi altre domande sui tag