Verwundbare Java-Funktionen

Question

Diese Frage ähnelt verwundbaren PHP-Funktionen.

Verunreinigte Daten stammen vom Benutzer, oder genauer gesagt von einem Angreifer. Wenn eine verunreinigte Variable eine Senkfunktion erreicht, haben Sie eine Schwachstelle. Beispielsweise ist eine Funktion, die eine SQL-Abfrage ausführt, eine Senke, und GET/POST-Variablen sind Quellen der Verunreinigung.

Was sind alle Senkfunktionen in der Java-Klassibibliothek (für jede Art von Java)? Ich suche nach Funktionen, die eine Sicherheitslücke oder Software-Schwäche einführen. Ich bin insbesondere an Remote-Code-Ausführbarkeitslücken interessiert. Gibt es ganze Klassen/Bibliotheken, die böse Funktionalitäten enthalten, auf die ein Hacker Einfluss nehmen möchte? Wie machen Leute versehentlich gefährlichen Java-Code?

Answer 1

Hier ist eine Liste basierend auf meiner persönlichen Recherche zur Client-seitigen Java-Sicherheit im Allgemeinen und zur Verwendung der Eclipse-IDE, um zu sehen, welche Methoden SecurityManager-Überprüfungen durchführen.

ClassLoader definieren Klassen (= beliebige Java-Codeausführung):

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

\= Codeausführung

Java Beans Introspection kann ClassLoader dazu bringen, Klassen aus einer nicht vertrauenswürdigen Quelle zu laden (Beispiel Schwachstelle - cve-2010-1622)

java.beans.Instrospector.getBeanInfo

\= Codeausführung

Dateizugriff

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

\= Löschen/Umbenennen von Dateien, Verzeichnisliste

File-Stream/Reader-Klassen

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

\= Datei Lese-/Schreibzugriff

Java Systemeigenschaften

System.setProperty
System.getProperties
System.getProperty

\= Einige Systemeigenschaften können möglicherweise Informationen enthalten, die fast sensibel sind, und einige Systemeigenschaften können die Ausführung von kritischen Elementen verändern, ich habe jedoch keine Beispiele

Laden von nativen Bibliotheken

System.load
System.loadLibrary

\= Beliebige Codeausführung

Ausführen von Betriebssystem-Executable

Runtime.exec
ProcessBuilder (Konstruktor)

Generieren von nativen Systemeingabeereignissen

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

(Vielleicht weit hergeholt, da ein Server möglicherweise nicht einmal eine grafische Umgebung hat)

Java-Reflexion - Zugriff auf beliebige (auch private) Felder und Methoden

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

\= Vom Offenlegen sensibler Informationen bis zur eventualen Codeausführung, abhängig von den Umständen

Java-Skript-Engine

javax.script.ScriptEngine.eval

\= beliebige Codeausführung

Answer 2

Ausführungsschwachstellen:

1. Private Reflektion, aber es ist ungewöhnlich, dass kontaminierte Daten auf gefährliche Weise dort landen
2. Native Interop-Code, der seine Parameter nicht ausreichend validiert
3. De-Serialisierer. Wahrscheinlich am gefährlichsten, da Sie möglicherweise aus nicht vertrauenswürdigen Daten de-serialisieren möchten. Einige Serialisierer sind relativ sicher und verwenden nur öffentliche Konstruktoren/Setter, andere greifen jedoch auf private Felder zu. Und wenn es keine Typ-Whitelist gibt, könnte es beliebige Typen instanziieren und Setter darauf aufrufen.
4. Jede Form von Ein-/Ausgabe, insbesondere Dateien
5. Dynamisches Laden von Bibliotheken. Insbesondere unter Verwendung des relativen Pfads. Insbesondere relativ zum Arbeitsverzeichnis anstelle des ausführbaren Verzeichnisses

(Dies betrifft .NET, aber ich erwarte, dass Java sehr ähnlich ist)

Dateninjektion

Dann gibt es die Injektionsfamilie von Funktionen, die in der Regel verhindert werden kann, indem nicht mit Zeichenfolgen gearbeitet, sondern spezialisierte Bibliotheksfunktionen verwendet werden. Diese führen in der Regel nicht zu beliebigen Codeinjektionen.

1. HTML-Injektion / XSS (weitgehend verhindert durch einen Ansichts-Engine, der die Ausgabe automatisch escapet und sauber zwischen escapeten und nicht-escapeten Zeichenfolgen trennt (möglicherweise unter Verwendung unterschiedlicher Typen))
2. SQL-Injektion (verhindert durch vorbereitete Anweisungen)
3. Dateipfad-Injektion

Answer 3

Ich bin sicher, dass diese Liste wachsen wird, während ich echte Exploits suche:

1. Spring-Klassenladeprogramm

2. Verschluckte Ausnahmen - Wie bereits erwähnt, können verschluckte Ausnahmen möglicherweise nicht direkt zu einer Ausnutzung führen, aber sie können dazu führen, dass die Ausnutzung nicht entdeckt wird.

3. String[] Befehle = {args[0]}; Runtime.getRuntime().exec(commands);
   Mir ist bewusst, dass es sich um einen ziemlich banalen Punkt handelt, aber das Ausführen von Code ähnlich wie oben kann es Ihnen ermöglichen, etwas wie dies zu übergeben: && del / wenn auf Windows oder ;rm -rf / auf *nix

Der größte Fehler, den Leute bei gefährlichem Java-Code machen, ist die Faulheit. Wie Sie bereits erwähnt haben, Benutzereingaben nicht vor der Ausführung zu bereinigen.