prototype pollution static analysis
1.0.0
Cette étude se concentre sur la vulnérabilité de la pollution prototype, un "nouveau" type de vulnérabilité de sécurité, découvert pour la première fois en 2018, qui n'a pas été étudié en profondeur. La vulnérabilité exploite la conception orientée prototype de JavaScript. En modifiant le prototype d'objets natifs tels que l'objet, à partir de laquelle la plupart des autres objets héritent des propriétés et des méthodes, il est possible, en fonction de la logique de l'application spécifique, de dégénérer à presque toute autre vulnérabilité Web.
Nous avons collecté un code JavaScript contenant des exemples de vulnérabilité de la pollution du prototype de mot réel qui recherchent des bases de données de vulnérabilité telles que GitHub Advisory et d'autres sources. Pour être sûr que les exemples collectés sont en fait vulnérables, nous avons écrit un simple exploit de preuve de concept pour chaque fonction vulnérable. Nous avons effectué les outils d'analyse statique considérés par rapport aux applications vulnérables. Parmi l'ensemble de données de vulnérabilité, nous avons choisi certaines études de cas que nous avons analysées en détail pour expliquer différents modèles de code qui conduisent à la vulnérabilité. Ces études de cas ont été choisies pour montrer des résultats intéressants qui nous ont permis de mettre en évidence les forces et les limites de chaque outil.
ODGEN / Objlupansys Une nouvelle approche, basée sur le graphique de dépendance des objets qui modélise avec succès les recherches d'objets basées sur la chaîne prototype, peut détecter presque tous les cas de vulnérabilité. L'implémentation expérimentale actuelle, cependant, est affectée par les bogues lorsqu'il rencontre certains modèles de code. Il souffre également de problèmes de performances graves lors de l'analyse de grands packages ou de certains modèles. En outre, il est très enclin à signaler les faux positifs lorsqu'il est exécuté contre la version patchée des fonctions vulnérables précédemment.
Les règles SEMGREP ne couvrent pas tous les cas tels que les affectations directes, en raison de la difficulté de l'inclusion de ce cas sans avoir un taux de faux positif très élevé. Le moteur Semgrep n'offre qu'une analyse intraprocédurale limitée de la flux de données et, comme prévu, ne peut pas toujours détecter la vulnérabilité qui sont distribuées sur différentes fonctions (par exemple, les appels récursifs indirects). Les règles signalent de nombreux faux positifs lorsqu'ils sont exécutés contre la version patchée des fonctions précédemment vulnérables, car la plupart des techniques d'atténuation ne sont même pas prises en compte.
CodeQL peut identifier presque tous les exemples de vulnérabilité collectés. Les requêtes considérées semblent bien écrites, les problèmes rencontrés sont très probablement la limitation du moteur source fermé. Pour ce qui concerne les fausses postives, la plupart des techniques d'atténuation sont prises en compte, donc les requêtes CodeQL fonctionnent beaucoup mieux que les autres outils.
Plus de détails dans la thèse PDF
