Dans un article précédent, j'ai suggéré au lecteur de savoir comment le langage de requête SQL est structuré en détail, ainsi que le fonctionnement du protocole HTTP. Mais ce n'est généralement pas le cas. Et je me suis immédiatement souvenu de l'histoire décrite dans l'un de mes livres préférés, «Untrustworthy Minds», par Rob Brotherton. Il décrit l'expérience suivante. La psychologue Rebecca Lawson a demandé à un groupe de sujets s'ils avaient déjà fait du vélo dans leur vie. La plupart ont répondu oui. Elle a en outre demandé s'ils savent comment fonctionne le vélo. Il y avait déjà moins de réponses affirmatives, mais toujours la grande majorité. Et puis elle a suggéré l'image suivante et a demandé de la compléter pour que ce vélo puisse rouler.
Et puis la chose la plus intéressante s'est produite - plus de la moitié des gens n'ont pas pu le faire. Cette tâche d'une simplicité trompeuse montre que la plupart des gens ne peuvent tout simplement pas imaginer comment fonctionne un vélo. Mais la chose la plus intéressante est qu'ils ne comprennent pas qu'ils ne savent pas cela, mais commencent à comprendre cela seulement au moment où ils doivent démontrer cette connaissance.
Avec HTTP et SQL, la même chose se produit. 90% des experts informatiques ont écrit des requêtes SQL, au moins dans les laboratoires de laboratoire de leurs établissements d'enseignement, les gens travaillent avec HTTP tous les jours en tant qu'utilisateurs et les mêmes experts informatiques configurent de temps en temps des serveurs Web qui fonctionnent réellement avec HTTP. Mais lorsque vous devez répondre à une question spécifique, une stupeur se produit régulièrement.
Un analyste de la sécurité de l'information doit connaître la technologie en détail, connaître les nuances et les subtilités. Si nous ne savons pas comment telle ou telle technologie devrait fonctionner, comment pouvons-nous déterminer ce qui ne va pas?
Aussi une "injection"
J'ai mentionné que la vérification de l'entrée devrait avoir lieu sur le serveur, mais pas sur le client. De temps en temps, on peut rencontrer des formulaires de saisie où les éléments individuels sont inactifs. Et on suppose qu'ils deviendront actifs une fois que certaines conditions seront remplies. Ou, par exemple, le champ de saisie du nom d'utilisateur comporte 7 caractères, limitant ainsi la longueur maximale du nom d'utilisateur. Tout cela est une très mauvaise pratique et c'est pourquoi: les éléments de la page qui ont déjà été reçus peuvent être édités arbitrairement avant l'envoi, sans aucun moyen technique particulier. Dans OWASP Mutillidae II, cela peut être vu dans l'exemple «Autres»> «Contrôles de sécurité côté client».
Voici un formulaire dans les champs dont vous devez saisir un nombre aléatoire, cette fois c'est 2056694312. La «difficulté» ici est que les champs ont des limites. Il y a un champ «Lecture seule» où le nombre 42 ne peut pas être remplacé, il y a un champ «Zone de texte courte» trop court où notre numéro ne peut tout simplement pas tenir, il y a un champ «Zone de texte désactivée» désactivé qui est inactif, et ainsi de suite.
En fait, la tâche est résolue très simplement. Dans le navigateur (dans mon cas, c'est Mozilla Firefox), accédez à la console développeur (F12) et commencez à inspecter les éléments du formulaire.
Par exemple, un champ en lecture seule ressemble à ceci:
<input HTMLandXSSInjectionPoint="1" type="text" name="readonly_textbox" id="id_readonly_textbox" size="15" maxlength="15" required="required" autofocus="autofocus" readonly="readonly" value="42" />
Supprimer readonly = ”readonly” et le tour est joué: le formulaire est accessible en écriture, nous pouvons saisir notre numéro.
Notre valeur ne rentre tout simplement pas dans le champ suivant, regardons cet élément:
<input HTMLandXSSInjectionPoint="1" type="text" name="short_textbox" id="id_short_textbox" size="3" maxlength="3" required="required" />
Ici, nous remarquons maxlength = ”3 ″. Remplacez 3 par 333, maintenant nous pouvons entrer notre numéro sans craindre qu'il ne rentre pas.
Et en passant, il ne s'agit pas seulement de champs de saisie. De même, vous pouvez modifier tous les éléments, tels que les cases à cocher. Le code de la page ressemble à ceci:
<input type="checkbox" name="checkbox" id="id_checkbox" value="2056694312" required="required" disabled="disabled" />
C'est assez simple ici, nous allons remplacer la valeur par notre numéro, et maintenant elle sera envoyée lorsque l'utilisateur cliquera sur le bouton.
Au total, si vous savez comment le HTML est structuré, il ne vous sera pas difficile de corriger ce formulaire pour y saisir toutes les données nécessaires. Relisez simplement la section sur le syndrome du vélo =)
Pas seulement SQL
L'injection ne concerne pas toujours les bases de données. Dans l'ensemble, à partir de n'importe quel formulaire qui ne filtre pas les données entrantes, vous pouvez obtenir des informations supplémentaires. Dans l'exemple "Injection du journal des applications"> "Recherche DNS", il existe un formulaire pratique pour les requêtes DNS:
En effet, si vous y entrez l'adresse, par exemple google.com, nous obtenons toutes les informations nécessaires:
Cependant, la vulnérabilité est qu'en plus de la première commande valide, nous pouvons entrer autre chose. Par exemple, spécifiez:
google.com && dir
et maintenant la sortie de la commande est beaucoup plus intéressante:
Nous avons fait une demande au serveur DNS, mais en plus, nous avons exécuté la commande dir et regardé ce qui était dans le dossier avec notre site. Il n'est pas difficile, en combinant différentes commandes, de se promener sur le disque dur du serveur Web et de rechercher ce qui est mauvais.
La prochaine fois, nous analyserons plus d'exemples et verrons également comment automatiser votre travail.
Lisez le blog de l'auteur sur
ce lien .