Certaines ressources vulnérabilités Web qui utilisent SQL


Dans cet article examine la vulnérabilité de SQL, associée à la pénétration dans le corps de la demande.

L'essence de la vulnérabilité

Considérez le travail d'un système simple avec interface web qui permet aux utilisateurs de protéger et de modifier les informations vous concernant. Ces systèmes sont l'un des très commun sur le web. Il peut également être un livre d'or, et le chat, et une galerie de photos, et le service postal.

La requête de base de données générée danyh forcée à avoir un nom d'utilisateur et mot de passe entré par l'utilisateur. Dans ces domaines, la base de données pour trouver l'entrée correspondante dans la table. Après avoir terminé la demande, la base de données fournit les informations trouvées sur l'utilisateur, qui établit un script PHP en HTML donne également à l'utilisateur.

Rascmotrim fragment de script PHP assez typique qui utilise une requête SQL pour accéder à la base de données:

<? Php
$ Result = mysql_db_query ( "base de données" , "select * from usertable où login = '$ Userlogin' et mot de passe = '$ userPassword'");
while ($ row = mysql_fetch_array ($ result)) {
echo $ row [ "fullname"] ;
echo $ row [ "email"] ;
echo $ row [ "mot de passe"] ;
}
mysql_free_result ($ result);
?>

En tant que témoin, le login et le mot de passe entré par l'utilisateur sont contenus dans le $ UserLogin variable $ userPassword. Le contenu de ces variables vstyavlyaetsya la requête pour filtrer l'information est à propos de cet utilisateur. Le filtre est spécifié par commande SQL select où des options. Dans ce cas, la demande est la suivante: select * from usertable où login = '$ Userlogin' et mot de passe = '$ userPassword' où usertable - nom de la table contenant les informations nécessaires. Si les variables nom d' utilisateur et mot de passe contiennent des valeurs Vanya également Vassia en conséquence, la demande, envoie la base de données ressemblera à ceci: select * from usertable où login = 'vanya' et mot de passe = 'vasya'. Il est clair que si la base de données est en l'absence d'un enregistrement, qui est le mot de passe de connexion , mais vanya - vasya, jusqu'à ce que l'enquête n'a pas envoyé une seule ligne à partir de la base de données, et le script ne donne rien. Ainsi, le système actuel permet d'accéder à l'information que l'utilisateur avec un mot de passe unique et connexion.

Il semblerait qu'un tel système ne contient pas de défauts. En classe, il ne le fait pas. Logic programmictov qui a créé l'exemple ci - dessus, signifie que le nom d' utilisateur et mot de passe entré par l' utilisateur, seront contenus dans des guillemets simples, qui sont étroitement emballés avec dans le corps de la demande. Cependant, nous allons voir ce qui se passe, si personnellement mot de passe entré polzovaetelm contient des guillemets. Qu'il détient la valeur vas'ya, au moment où une demande prend la forme: select * from usertable où login = 'vanya' et mot de passe = 'vas'ya'. Dans l'exercice d'une telle demande, certainement une erreur, parce que la citation du mot de passe, fermer la citation d'ouverture d'une requête, et la fin du mot de passe ya 'gauche' accroché 'est conditionnelle.

Et si vous insérez le mot de passe la ligne suivante: 'ou 1 = 1', la demande sera telle :: select * from usertable où connexion = 'vanya' et mot de passe = '' ou 1 = 1 '' ne peut pas également auront des erreurs de syntaxe . Mais l'expression logique serait identique vrai objection à cette demande, le SQL donnera toute la base de données de l'utilisateur 8).

Ainsi, en utilisant l'apostrophe, nous pouvons prniknut corps dans une requête SQL pour le faire, cela aurait été la condition est vraie. Si nous sommes intéressés à un utilisateur vanya particulier, afin d'obtenir des informations à ce sujet, est autorisé à utiliser une chaîne de mot de passe: 'ou ouvrir une session =' vanya. Cette commande sera donc: select * from usertable où login = 'vanya' et mot de passe = '' ou connectez = 'vanya'. Comme vous pouvez l' imaginer, en conséquence, nous obtenons des informations à ce sujet Vanya.

La vulnérabilité des services sur la base du SQL, ne se limite pas à l'accès non autorisé à notre base de données. Étant donné que ces systèmes généralement utilisés, MySQL, il est possible non seulement de modifier l'expression conditionnelle dans l'équipe de sélectionner, mais aussi d'aller au-delà de la commande également exécuter une autre base de données de commande. Parce que MySQL est autorisé plusieurs commandes en une seule requête, séparés; Nous pouvons exécuter une de ces commandes en tapant dans le champ Mot de passe le code suivant: '; <KomandaSQL> dans quel lieu comme <komandaSQL> autorisés à spécifier toute commande valide. Par exemple , le code suivant: '; drop table 'usertable tout simplement détruire la table usertable de la base de données.

Utilisation pratique de la vulnérabilité

Malgré sa simplicité, l'utilisation pratique des requêtes SQL erreurs sont très difficiles.

Dans cet esprit, examiner les questions suivantes découlant de l'utilisation de la vulnérabilité décrite:
  • Déterminer si l'utilisation du système de SQL.
  • Révéler l'existence de la vulnérabilité. Élucidation de la réaction à l'erreur de script.
  • Détermination des noms de champs dans la table.
  • Identifier les noms de tables existantes.

    Considéré comme la vulnérabilité inhérente à toutes les requêtes SQL, quel que soit le script ou un programme, où ils sont appelés. Tout de même, nous considérerons un système basé sur PHP. Ceci est dû au fait que l'écoulement de l'erreur de position PHP (par défaut) est envoyé à l'utilisateur final. A cette époque, comme Perl ou application EXE habituellement ne pas informer l'utilisateur de la nature de l'erreur.

    Déterminer si l'utilisation du système de SQL.

    En particulier, l'étude du système, que ce soit en utilisant SQL doit d'abord comprendre.
    Ce fait a permis d'identifier les moyens ou indirectement (par l'affichage des noms des fichiers, des liens vers les moyens utilisés et ainsi de suite), ou directement - forcer SQL à s'exprimer. Si nous raboatem avec PHP, alors il n'y a qu'un seul moyen d'utiliser SQL pour déterminer sans ambiguïté - il est une erreur d'appeler pour sa mise en œuvre. Si vous avez une erreur de requête se pose, mais aussi erreur de script PHP est clairement pas vyponeniya pas traitée, le message sur l'erreur de PHP émettra directement à la page de l'utilisateur.
    Comment appeler l'erreur de la requête SQL dépend de la résolution de l'appareil du système. Dans la plupart des cas, l'erreur est autorisé à appeler en entrant des données incorrectes dans le système.

    Révéler l'existence de la vulnérabilité. Élucidation de la réaction à l'erreur de script.

    Les moyens les plus rudimentaires de détecter la présence de la vulnérabilité, mais en même temps aussi utiliser SQL fait réussit: Dans tous les domaines, ce qui serait impliqué dans la formation d'une requête SQL (par exemple, champ Login ou mot de passe), entrez le apostrophe. Les champs restants sont remplis avec des données valides (ou laisser en blanc, si elle est autorisée par le système). Après avoir envoyé les données de formulaire, regardez la réponse du système. Si le script PHP nous donne une erreur SQL, nous pouvons nous féliciter: le système utilise également un script SQL ne filtre pas une seule citation. Ce système comprend une vulnérabilité à manger.
    Erreur requête SQL serait dans ce cas, regardez la page comme ceci:

    Formulaire de données d'entrée:


    En tant que résultat de la requête SQL d' erreur:


    Si le code d'erreur SQL sur la page n'est pas présent, cela pourrait signifier ce qui suit:
    1) Le système contient une vulnérabilité, mais un script PHP gère les erreurs. Dans ce cas, le système est autorisé à se fissurer, mais devra travailler "au feeling" que nous ne saurons pas la syntaxe SQL à quelle heure sera correcte, mais il est à quel moment.
    2) Le script filtre la citation aussi parce que l'erreur ne se produit pas. Dans ce cas, le système ne contient pas de vulnérabilités.
    3) le système général n'a pas utilisé par SQL.
    Dans les deux derniers cas, il est clair que la poursuite de la recherche est SQL ne possède pas de sens.

    Détermination des noms de champs dans la table.

    Afin de recevoir des informations à partir d'une base de données avec des données spécifiques, nous devons déterminer les valeurs de certains champs dans la requête (par exemple, spécifier une connexion de l'utilisateur). Pourtant, il a besoin de connaître le nom des champs correspondants. est directement pas possible de connaître ces noms. Donc, il y aura à trouver un procédé de tri de ces noms. Les noms de données sont les mêmes que les noms de champs dans le formulaire est envoyé au serveur, et peuvent également ne pas correspondre. Bonne leçon que les noms de champs, ainsi que la position des orthographes standards eux non pas tant. Par exemple, le nom du champ pour le nom d'utilisateur est susceptible d'être un nom d'utilisateur ou nick. Il est semblable à un mot de passe: mot de passe ou pwd ou passe.
    Pour déterminer l'existence d'un domaine particulier, il est proposé la méthode ingénu: Supposons que nous voulions vérifier s'il y a un champ pwd dans le tableau. Introduire un champ de ligne tels «pwd = 'de forme. Si le champ pwd existe dans la table, SQL traiter correctement la demande si blah blah ce domaine est pas présent, il y aura à nouveau effectuer erreur SQL. Ainsi en remplaçant différentes valeurs de noms de champ à la suite d'une enquête à la demande de finition, nous pouvons comprendre qui existent champs dans le tableau, mais ce qui ne fonctionne pas.

    Identifier les noms de tables existantes.

    De même, la méthode permettant de trouver les noms de champs dans les tableaux sont autorisés à rechercher les noms des tables existantes dans la base de données. Supposons que nous voulons savoir s'il existe une base dans le tableau AdminList. Pour ce faire, nous introduisons la possibilité de faire un champ de formulaire est une chaîne '; select * from AdminList. Si l'erreur SQL ne démarre pas, alors AdminList table existe. Pour l'exactitude de ce test, vous devez entrer cette chaîne dans la boîte qui apparaît couronnement dans une requête SQL. Ceci afin d' assurer que ce serait pas une erreur de syntaxe a été causé en raison de la «queue» restante de la demande initiale, qui sera présent plus tard select * from AdminList. Notez que si le formulaire de demande Connexion possède une paire de champ comme mot de passe, il est probable que ce soit le champ de mot de passe apparaîtra dans la dernière demande.

    PS

    En utilisant cette vulnérabilité, le site a été piraté http://www.bigmir.net (plus précisément sa galerie de photos et chat). Nous sobschili la vulnérabilité des propriétaires du site. Le trou était pofiksina. Mais maintenant, nous avons une vérifié formulaire d'inscription dans le chat. De plus, je trouve tout le bla bla vulnérabilité 8-).