Fonctions Java exploitables [fermé]

Voici une liste basée sur mes recherches personnelles sur la sécurité Java côté client en général, et en utilisant l'EDI Eclipse pour voir quelles méthodes effectuent les vérifications SecurityManager.

Les ClassLoaders définissent des classes (=exécution arbitraire de code java):

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

= exécution du code

Java Beans Introspection peut détourner les chargeurs de classes en chargeant des classes à partir d'une source non fiable (exemple de vulnérabilité-2010-1622)

java.beans.Instrospector.getBeanInfo

= code exécution

Accès aux fichiers

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

= suppression / renommage de fichiers, liste de répertoires

Flux de Fichiers/classes de lecteur

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

= Accès en lecture/écriture au fichier

Propriétés du système Java

System.setProperty
System.getProperties
System.getProperty

= Certaines propriétés système peuvent contenir des informations presque sensibles, et certaines propriétés système peuvent modifier l'exécution de choses critiques, je n'ai pas d'exemples, cependant

Chargement natif les bibliothèques

System.load
System.loadLibrary

= Exécution arbitraire de code

Exécution des exécutables du système d'exploitation

Runtime.exec
ProcessBuilder (constructor)

Générer des événements d'entrée système natifs

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

(Peut-être tiré par les cheveux car un serveur peut même ne pas avoir d'environnement graphique)

Java reflection-accès à des champs et méthodes arbitraires (même privés)

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

= De la divulgation d'informations sensibles à l'exécution éventuelle du code, en fonction circonstances

Moteur de script Java

javax.script.ScriptEngine.eval

=exécution arbitraire de code

Vulnérabilités d'exécution de Code:

1. Réflexion privée, mais il est rare que des données contaminées y parviennent de manière dangereuse
2. Code d'interopérabilité natif qui ne valide pas assez ses paramètres
3. désérialiseurs . Probablement le plus dangereux car vous voudrez peut-être désérialiser à partir de données non fiables. Certains sérialiseurs sont relativement sûrs et n'utilisent que des constructeurs/setter publics, mais d'autres accèdent à des champs privés. Et s'il n'y a pas de type liste blanche il peut instancier des types arbitraires et appeler des setters sur eux.
4. Toute forme d'IO, fichiers en particulier
5. chargement Dynamique des bibliothèques. En particulier en utilisant le chemin relatif. En particulier par rapport au répertoire de travail au lieu du répertoire exécutable

(Il s'agit de. net, mais je m'attends à ce que Java soit très similaire)

Injection de Données

Ensuite, il y a la famille de fonctions d'injection qui peut généralement être empêchée en ne fonctionnant pas sur chaînes mais en utilisant des fonctions de bibliothèque spécialisées. Ceux-ci ne conduisent généralement pas à une injection de code arbitraire.

1. injection html g / XSS (Largement empêchée par un moteur de vue qui échappe automatiquement la sortie et sépare proprement les chaînes échappées et non échappées (peut-être en utilisant différents types))
2. Injection SQL (empêchée par des instructions préparées)
3. Injection de chemin de fichier

Je suis sûr que cette liste augmentera à mesure que je creuserai pour trouver de vrais exploits:

1. Le Printemps du chargeur de classe

2. Exceptions avalées-Comme cela a été noté, les exceptions avalées peuvent ne pas causer directement une exploitation, mais elles peuvent conduire à la non-découverte de l'exploitation.

3. String[] commands = {args[0]};
Runtime.getRuntime().exec(commands);
   Je me rends compte que c'est un élément assez trivial, mais l'exécution d'un code similaire à ce qui précède peut vous permettre de passer quelque chose comme ceci: && del / si sous Windows ou ;rm -rf / sur *nix

La plus grande façon dont les gens rendent le code Java dangereux est d'être paresseux. Comme vous l'avez mentionné, ne pas nettoyer l'entrée de l'utilisateur avant de l'exécuter.