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'IDE Eclipse pour voir quelles méthodes font les vérifications SecurityManager.

chargeurs de classes de définir des classes (=arbitraire de code java à l'exécution) :

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

= exécution de code

Java Beans Introspection peut détourner les chargeurs de classe dans le chargement de classes à partir d'une source non fiable ( exemple vuln-cve-2010-1622 )

java.beans.Instrospector.getBeanInfo

= exécution de code

l'accès au Fichier

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

= suppression/ renommage de fichiers, répertoire

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 de fichier

Java System Propriétés

System.setProperty
System.getProperties
System.getProperty

=certaines propriétés du système peuvent contenir des informations presque sensibles, et certaines propriétés du système peuvent altérer l'exécution des choses critiques, je n'ai pas d'exemples, bien que

chargement de bibliothèques natives

System.load
System.loadLibrary

= exécution de code arbitraire

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

Runtime.exec
ProcessBuilder (constructor)

Génération de système natif des événements d'entrée

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

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

réflexion Java d'accès à l'arbitraire (même privé) des champs et des méthodes

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 de code, en fonction de la circonstances

Java le moteur de script

javax.script.ScriptEngine.eval

=exécution de code arbitraire

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

1. réflexion privée, mais il est rare que des données contaminées s'y rendent de manière dangereuse
2. code Interop natif qui ne valide pas assez ses paramètres
3. De-sérialiseurs . Probablement le plus dangereux car vous pourriez vouloir désisérialiser à partir de données non fiables. Certains sérialisateurs sont relativement sûrs et ne sont utilisés que les constructeurs publics/setter, mais d'autres l'accès des champs privés. Et s'il n'y a pas de type white-list, il peut instancier des types arbitraires et appeler des setters sur eux.
4. toute forme D'IO, en particulier les fichiers""
5. chargement Dynamique des bibliothèques. En particulier en utilisant le chemin relatif. En particulier relatif au répertoire de travail au lieu du répertoire exécutable

(c'est à propos 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 peuvent typiquement être empêchées en ne fonctionnant pas sur des chaînes, mais en utilisant des fonctions de bibliothèque spécialisées. Ceux-ci ne conduisent généralement pas à l'injection de code arbitraire.

1. HTML injectiong / XSS différents types))
2. SQL injection (empêché par des requêtes préparées)
3. Fichier-Chemin injection

je suis sûr que cette liste va s'allonger au fur et à mesure que je cherche de véritables exploits:

1. classe de ressorts

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

3. String[] commands = {args[0]};

Runtime.getRuntime().exec(commands);
   
   Je me rends compte que c'est un article assez banal, mais le code courant similaire à ce qui précède peut vous permettre de passer quelque chose comme ceci: && del / si sur Windows ou ;rm -rf / sur * nix

le plus grand moyen de faire du 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.