Comme vu ci-dessus, le code donne une erreur « Exception dans le thread « main” java.lang.ClassCastException: testserialization.ExploitDeser ne peut pas être converti en testserialization.Employé » ce qui signifie que le type-casting n’est pas approprié, mais le code est toujours exécuté. La fonction readObject de la classe DeserializeDemo est capable d’exécuter l’implémentation personnalisée de la readObject de la classe ExploitDeser.,
c’est ce qui est la désérialisation non sécurisée ici, que même s’il y a encore une erreur de type-casting si les données sérialisées d’une classe personnalisée avec une implémentation personnalisée de readObject sont fournies en entrée, elles sont exécutées comme indiqué ci-dessus.
c’est ce qui est fait par les chaînes de gadgets utilisées par ysoserial et d’autres outils d’exploitation de désérialisation java où ils recherchent le chaînage des classes pour finalement atterrir dans une implémentation personnalisée de readObject qui peut exécuter le code de niveau système fourni dans le cadre de l’entrée utilisateur.,
remédiation
maintenant, que nous avons examiné ce qu’est la désérialisation et comment elle est exploitée, regardons la remédiation à cela.
la remédiation dont nous allons discuter ici s’appelle « validation de classe prospective” où nous pouvons mettre en liste blanche la liste des classes que nous voulons désérialiser. Exemple. dans notre scénario, nous nous attendons à ce que seules les données D’objet de classe employé soient désérialisées et pour rester, elles ne devraient pas permettre la désérialisation.,
donc, fondamentalement, cette méthode remplace la fonction « resolveClass” qui fait partie de la classe « ObjectInputStream”(utilisée lors de la désérialisation) et effectue une liste blanche de la liste des classes qui doivent être désérialisées.
maintenant que nous en avons fini avec la théorie, passons à l’implémentation.,
permet de créer une nouvelle classe « LookAheadObjectInputStream” l’étendre à la classe ObjectInputSteam afin que nous puissions remplacer la fonction membre resolveClass:
dans le code ci-dessus, la ligne:
if (!desc.getName().equals(Employee.class.getName())) {
cherche essentiellement si le contenu sérialisé contient un objet de la classe Employee sinon il fournit une erreur « tentative de désérialisation non autorisée” et empêche son exécution.,
maintenant, le code modifié final pour « DeserializedDemo” est comme indiqué ci-dessous:
dans le code ci-dessus, observez le code en surbrillance dans lequel au lieu d’appeler la classe objectinputstream, la classe lookaheadobjectinputstream est appelée ce qui remplacera la méthode resolveclass pendant l’exécution et s’exécutera en conséquence.
maintenant, laisse passer le malveillant.,ser fichier créé précédemment comme entrée pour la désérialisation et observez le résultat:
Comme on peut le voir ci-dessus, cette fois, la coutume de la mise en œuvre de méthodes readObject de la classe personnalisée « ExploitDeser” ne soit pas exécutée lors de la désérialisation., Au lieu de cela, nous recevons le message d’erreur personnalisé « tentative de désérialisation non autorisée” qui a été défini dans la fonction resolveclass surchargée sous la classe LookAheadObjectInputStream.
ceci est un exemple très simple d’utilisation de la méthode de validation de classe look-ahead pour empêcher la désérialisation non sécurisée. Une implémentation étendue autour de cette idée est la bibliothèque « serialKiller”. Le lien peut être trouvé ci-dessous:
Par conséquent, cela peut être considéré comme l’une des solutions pour atténuer la désérialisation non sécurisée en java.,
je suis toujours à la recherche d’autres méthodes d’atténuation dont je parlerai plus tard.
veuillez fournir vos précieux commentaires. Jusque-là, continuez à pirater et à apprendre….
