Funzioni Java sfruttabili [chiuso]

Ecco un elenco basato sulla mia ricerca personale sulla sicurezza Java lato client in generale e sull'utilizzo dell'IDE Eclipse per vedere quali metodi eseguono i controlli SecurityManager.

I classloader definiscono le classi (=esecuzione arbitraria di codice java):

java.lang.ClassLoader.defineClass
java.net.URLClassLoader

= esecuzione di codice

L'introspezione Java Beans può deviare i classloader in classi di caricamento da un'origine non attendibile (esempio vuln-cve-2010-1622)

java.beans.Instrospector.getBeanInfo

= codice esecuzione

Accesso ai file

java.io.File (constructor)
java.io.File.delete
java.io.File.renameTo
java.io.File.listFiles
java.io.File.list

= eliminazione / ridenominazione di file, elenco directory

Classi di file stream / reader

java.io.FileInputStream
java.io.FileOutputStream
java.io.FileReader
java.io.FileWriter
java.io.RandomAccessFile

=Accesso lettura/scrittura file

Proprietà del sistema Java

System.setProperty
System.getProperties
System.getProperty

= Alcune proprietà di sistema potrebbero contenere alcune informazioni che sono quasi sensibili, e alcune proprietà di sistema potrebbero alterare l'esecuzione di cose critiche, non ho esempi, però

Caricamento nativo librerie

System.load
System.loadLibrary

= Esecuzione arbitraria di codice

Esecuzione di eseguibili del sistema operativo

Runtime.exec
ProcessBuilder (constructor)

Generazione di eventi di input del sistema nativo

java.awt.Robot.keyPress/keyRelease
java.awt.Robot.mouseMove/mousePress/mouseRelease

(Forse inverosimile dal momento che un server potrebbe non avere nemmeno un ambiente grafico)

Java reflection-accesso a campi e metodi arbitrari (anche privati)

java.lang.Class.getDeclaredMethod
java.lang.Class.getDeclaredField
java.lang.reflection.Method.invoke
java.lang.reflection.Field.set
java.lang.reflection.Field.get

= Dalla divulgazione di informazioni sensibili all'eventuale esecuzione di codice, a seconda circostanze

Motore di scripting Java

javax.script.ScriptEngine.eval

= esecuzione arbitraria di codice

Vulnerabilità di esecuzione del codice:

1. Riflessione privata, ma è raro che i dati contaminati arrivino in modo pericoloso
2. Codice di interoperabilità nativo che non convalida abbastanza i suoi parametri
3. De-serializzatori . Probabilmente il più pericoloso dal momento che potresti voler de-serializzare da dati non attendibili. Alcuni serializzatori sono relativamente sicuri e utilizzano solo costruttori/setter pubblici, ma altri accedono a campi privati. E se non esiste un tipo white-list potrebbe istanziare tipi arbitrari e chiamare i setter su di essi.
4. Qualsiasi forma di IO, file in particolare
5. Caricamento dinamico delle librerie. In particolare utilizzando il percorso relativo. In particolare rispetto alla directory di lavoro invece della directory eseguibile

(Si tratta di. net, ma mi aspetto che Java sia molto simile)

Iniezione di dati

Quindi c'è la famiglia di funzioni di iniezione che in genere può essere prevenuta non operando su stringhe ma utilizzando funzioni di libreria specializzate. Quelli in genere non portano all'iniezione di codice arbitrario.

1. html injectiong / XSS (in gran parte impedito da un motore di visualizzazione che sfugge automaticamente all'output e separa in modo pulito le stringhe di escape e non escape (forse usando tipi diversi))
2. SQL injection (impedito da istruzioni preparate)
3. Iniezione del percorso del file

Sono sicuro che questa lista crescerà man mano che scaverò nella ricerca di exploit reali:

1. Classloader primavera

2. Eccezioni ingerite - Come è stato notato, le eccezioni ingerite non possono causare direttamente uno sfruttamento, ma possono portare alla non scoperta dello sfruttamento.

3. String[] commands = {args[0]};
Runtime.getRuntime().exec(commands);
   Mi rendo conto che è un elemento abbastanza banale, ma l'esecuzione di codice simile al precedente può consentire di passare qualcosa del genere: && del / se su Windows o ;rm -rf / su * nix

Il modo più grande in cui le persone fanno codice Java pericoloso è essere pigri. Come hai detto, non pulire l'input dell'utente prima di eseguirlo.