La description des vulnérabilités est une chose, mais essayer de trouver une vulnérabilité et travailler avec elle est une tout autre affaire. C'est à ces fins que sont créées et développées des applications spéciales dans lesquelles les vulnérabilités sont délibérément laissées pour compte. Si vous saisissez dans le moteur de recherche la requête «Application vulnérable à dessein», vous ne trouverez pas une douzaine de liens.
Dans cette série, nous allons commencer à analyser les vulnérabilités du Top 10 OWASP, et j'utiliserai une telle application intentionnellement vulnérable comme terrain d'essai. Dans mon cas, ce sera OWASP Mutillidae II. Ce n'est pas la meilleure option, mais les vulnérabilités sont structurées exactement selon les besoins à des fins éducatives.
Donnez votre mainAinsi, la première vulnérabilité est les injections. OWASP Mutillidae II présente plusieurs options, et nous commencerons par les plus simples «Données d'extraction SQLi»> «Informations utilisateur (SQL)».
Devant nous se trouve la fenêtre d'authentification habituelle - avec laquelle vous interagissez quotidiennement:
Nous n'avons pas de nom d'utilisateur ni de mot de passe - rien. Eh bien, inscrivons-nous sur ce site. Je vais créer un utilisateur avec le nom en dessous de zéro273 et le mot de passe 123:
Super! Nous avons créé un compte, l'inscription solennelle «1 lignes insérées» indique qu'une ligne a été ajoutée, apparemment dans le tableau, car un grand nombre de comptes sont plus faciles à stocker dans le SGBD.
Connectez-vous maintenant avec notre nouveau compte dans le système. Réussi, super.
Lorsque nous travaillons avec une page Web, nous devons toujours nous rappeler que notre interaction n'est pas limitée au contenu de la page. Il y a aussi une barre d'adresse, par exemple. Dans lequel nous pouvons remarquer beaucoup de choses intéressantes:
http://127.0.0.1/mutillidae/index.php?page=user-info.php&username=belowzero273&password=123&user-info-php-submit-button=View+Account+Details
Par exemple, nous voyons que le mot de passe est transmis en texte clair. C'est mauvais, car le trafic peut être intercepté. Mais peut-être pas un tel désastre - le trafic sera enveloppé dans TLS.
Essayons de remplacer le mot de passe directement dans la ligne, par exemple, cette pièce:
username=belowzero273&password=123
sur
username=belowzero273&password=12345
Le mot de passe, bien sûr, est maintenant incorrect, et nous avons reçu l'erreur correspondante: et c'est mauvais. C'est mauvais, car avec l'aide de THC-Hydra, dont j'ai parlé
ici , nous pouvons récupérer ce mot de passe en le substituant à cette ligne sans aucune forme. Mais cela ne peut pas toujours conduire à un résultat positif dans un délai acceptable.
Nous n'avons pas beaucoup de temps, alors essayons autre chose. Ajoutez un signe d'apostrophe à notre mot de passe incorrect:
username=belowzero273&password=123
sur
username=belowzero273&password=12345'
Nous avons maintenant une erreur complète:
Il n'y a rien de mal aux erreurs. Sinon, comment diagnostiquer un dysfonctionnement si nous ne voyons pas les commentaires de l'application? Mais ces erreurs ne devraient pas être visibles pour les utilisateurs et les attaquants.
Maintenant, nous voyons qu'en fait, lorsque nous cliquons sur le bouton "Envoyer" en arrière-plan, la demande suivante est exécutée:
SELECT * FROM accounts WHERE username='belowzero273' AND password='12345'
Les apostrophes distinguent les variables de chaîne. Notre application Web ne filtre pas les données que l'utilisateur entre et, avec notre apostrophe supplémentaire, nous avons violé la demande. Maintenant que nous savons à quoi ressemble cette requête en arrière-plan, nous devons déterminer comment la modifier pour obtenir les informations dont nous avons besoin dans la base de données.
Veuillez noter que la demande contient la fonction et, c'est-à-dire que les deux variables doivent être correctes, car il s'agit d'une combinaison de login et de mot de passe. Est logique.
Jetons un coup d'œil à cette requête:
SELECT * FROM accounts WHERE (username='belowzero273' AND password='12345') OR 1='1
Nous avons ajouté une condition toujours satisfaite: 1 = 1. Et la demande sera exécutée dans deux cas: soit nous avons deviné la combinaison du nom d'utilisateur et du mot de passe, soit 1 = 1. Autrement dit, il sera toujours exécuté.
Il s'avère que les éléments suivants peuvent être spécifiés comme mot de passe:
' or 1='1
L'apostrophe en fin de ligne n'est plus nécessaire, la logique de l'application web la mettra pour nous. Boum! Et nous avons obtenu une sélection de la base de données avec tous les comptes:
Cool, nous avons maintenant les identifiants et les mots de passe de tous ceux qui sont enregistrés dans cette application. Et pire encore, les mots de passe sont ici en clair.
Quel est le problème avec ça? Et le fait que la plupart des gens utilisent les mêmes noms d'utilisateur et mots de passe pour tous les sites. Et après s'être enregistré de cette manière sur un site vulnérable, ils peuvent perdre l'accès à tous leurs sites.
Vous pouvez également expérimenter cette vulnérabilité, par exemple, rechercher un mot de passe administrateur. Pour ce faire, remplacez la connexion:
admin' or 1='1
Autrement dit, nous recherchons une entrée dans la base de données où le nom d'utilisateur est admin et le mot de passe est any.
!
Les mots de passe ne sont pas toujours stockés en texte clair, mais cela ne signifie pas que l'authentification est effectuée en toute sécurité. Regardons le deuxième exemple dans OWASP Mutillidae II «Authentification de contournement SQLi»> «Connexion».
L'authentification peut être contournée en générant une demande correspondante. Plus récemment, nous avons créé un compte en dessous de zéro273, et spécifions maintenant comme identifiant:
' or ('a' = 'a' and username='belowzero273')
Ici, nous vérifions la condition évidemment correcte - a = a, et la connexion - en dessous de zéro273, et coupons également la partie de la demande à l'aide de "-".
Appuyez sur Entrée et connectez-vous avec succès au système malgré le fait que nous n'avons spécifié votre mot de passe nulle part.
Si facileParfois, les clients demandent, est-il vraiment si facile de contourner l'authentification sur notre site? Habituellement, je réponds à la question par la question: "Êtes-vous sûr que cela ne s'est pas déjà produit?" Les injections ne sont pas accidentellement dans le haut de la cote OWASP, car ces vulnérabilités, en règle générale, ont des conséquences désastreuses si elles sont mises en œuvre.
Dans la pratique, bien sûr, tout est un peu plus compliqué que dans ces exemples. Mais c'est sur de tels exemples de base que la compréhension des problèmes plus profonds commence à prendre forme. Nous continuerons la prochaine fois.
Lire le blog de l'auteur, vous pouvez
suivre ce lien .