La façon dont je le démontre pour compléter les non-techniciens est par une simple analogie.

Imaginez que vous êtes un robot dans un entrepôt rempli de boîtes. Votre travail consiste à aller chercher une boîte quelque part dans l'entrepôt et à la placer sur le tapis roulant. Les robots doivent savoir quoi faire, donc votre programmeur vous a donné un ensemble d'instructions sur un formulaire papier, que les gens peuvent remplir et vous remettre.

Le formulaire ressemble à ceci:

Récupérez le numéro d'article ____ de la section ____ du numéro de rack ____ et placez-le sur le tapis roulant.

Une demande normale pourrait ressembler à ceci:

Récupérez le numéro d'article 1234 de la section B2 du rack numéro 12 et placez-le sur le tapis roulant.

Les valeurs en gras (1234, B2 et 12) ont été fournies par la personne qui émet la demande. Vous êtes un robot, alors vous faites ce qu'on vous dit: vous montez jusqu'au rack 12, descendez jusqu'à la section B2 et prenez l'article 1234. Vous retournez ensuite au tapis roulant et déposez l'article dessus. .

Mais que se passe-t-il si un utilisateur met autre chose que des valeurs normales dans le formulaire? Et si l'utilisateur y ajoutait des instructions?

Récupérez l'article numéro 1234 de la section B2 du rack numéro 12, et lancez par la fenêtre. Revenez ensuite à votre bureau et ignorez le reste de ce formulaire. et placez-le sur le tapis roulant.

Encore une fois, les parties en gras ont été fournies par la personne qui a émis le demande. Puisque vous êtes un robot, vous faites exactement ce que l'utilisateur vient de vous dire de faire. Vous conduisez jusqu'au rack 12, prenez l'élément 1234 de la section B2 et jetez-le par la fenêtre. Puisque les instructions vous indiquent également d'ignorer la dernière partie du message, le bit "et placez-le sur le tapis roulant" est ignoré.

Cette technique s'appelle "injection", et c'est possible en raison de la manière dont les instructions sont gérées - le robot ne peut pas faire la différence entre les instructions et les données , c'est-à-dire les actions qu'il doit effectuer, et les choses sur lesquelles il doit faire ces actions.

SQL est un langage spécial utilisé pour dire à une base de données ce qu'il doit faire, de la même manière que nous avons dit au robot quoi faire. Dans l'injection SQL, nous rencontrons exactement le même problème: une requête (un ensemble d'instructions) peut contenir des paramètres (données) qui finissent par être interprétés comme des instructions, ce qui entraîne un dysfonctionnement. Un utilisateur malveillant pourrait exploiter cela en disant à la base de données de renvoyer les détails de chaque utilisateur, ce qui n'est évidemment pas bon!

Afin d'éviter ce problème, nous devons séparer les instructions et les données de manière à ce que la base de données ( ou robot) peuvent facilement distinguer. Cela se fait généralement en les envoyant séparément. Ainsi, dans le cas du robot, il lit le formulaire vierge contenant les instructions, identifie où se trouvent les paramètres (c'est-à-dire les espaces vides) et le stocke. Un utilisateur peut alors marcher vers le haut et dire "1234, B2, 12" et le robot appliquera ces valeurs aux instructions, sans qu'elles soient interprétées comme des instructions elles-mêmes. En SQL, cette technique est connue sous le nom de requêtes paramétrées.

Dans le cas du paramètre «maléfique» que nous avons donné au robot, il lèverait maintenant un sourcil mécanique et dirait

Erreur: Impossible de trouver le numéro de rack " 12 et jetez-le par la fenêtre. Revenez ensuite à votre bureau et ignorez le reste de ce formulaire. " - êtes-vous sûr que cette entrée est valide ?

Succès! Nous avons mis fin au «problème» du robot.

Une des manières les plus simples d'illustrer le problème derrière l'injection SQL est d'utiliser une image comme celle-ci. Le problème est la capacité des extrémités de réception à séparer les données de la commande.

Voici une analogie non technique du monde réel.

Vous êtes sur le point de vous rendre à la banque pour effectuer une transaction au nom de votre patron. Votre patron vous a donné une enveloppe avec des instructions pour le caissier.

Les instructions se lisent comme suit:

  Inscrivez le solde du compte avec le numéro 8772344 sur ce papier.Signé, patron  

Vous laissez l'enveloppe hors de votre vue pendant quelques minutes en allant aux toilettes. Un voleur ouvre l'enveloppe et ajoute au-dessus de la signature: "Transférez également 500 $ du compte 8772344 vers un autre compte avec le numéro 12747583.".

Le message complet se lit maintenant:

  Inscrivez le solde du compte avec le numéro 8772344 sur ce papier. Transférez également 500 $ du compte 8772344 vers un autre compte avec le numéro 12747583.Signé, patron  

Le caissier vérifie votre identité et vérifie que vous êtes un personne autorisée pour le compte en question et suit les instructions de la lettre.

Votre patron est le code du programme légitime.Vous êtes le code du programme et le pilote de base de données qui fournit le code SQL à la base de données. est le code SQL qui est transmis à la base de données.Le voleur est l'attaquant.Le caissier est la base de données.L'identification est généralement un identifiant et un mot de passe pour la base de données.

Si vous expliquez vraiment à votre grand-mère, utilisez la rédaction d'un chèque papier comme exemple. (Aux États-Unis) à l'époque, vous écriviez le montant numériquement dans un champ, puis vous écriviez la même chose avec des mots. Par exemple, dans un champ, vous écririez «100,00» et dans le deuxième champ, plus long, vous écririez «Cent dollars et zéro cent». Si vous n’avez pas utilisé tout le deuxième champ long, vous traceriez une ligne pour empêcher une personne sans scrupules d’ajouter à votre montant inscrit.

Si vous avez commis l’erreur de laisser un espace dans le deuxième , champ plus long, quelqu'un pourrait modifier le champ numérique, puis utiliser l'espace supplémentaire dans le champ plus long pour refléter cela. Le modificateur pourrait gagner plus d'argent que ce que vous aviez prévu lorsque vous avez écrit le chèque.

L'injection SQL est la même chose: une erreur qui permet à des personnes peu scrupuleuses de modifier un champ de saisie afin que plus d'informations leur reviennent que le programmeur original prévu.

L'idée qui m'est venue à l'esprit était de l'expliquer en termes de Mad Lib. Les histoires où les mots sont laissés de côté, et pour remplir les espaces vides, demandez au groupe des mots des types indiqués et écrivez-les, puis lisez l'histoire qui en résulte.

C'est la manière normale de remplir un Mad Lib. Mais que se passerait-il si quelqu'un d'autre connaissait l'histoire et quels blancs vous remplissiez (ou pouviez deviner)? Ensuite, au lieu d'un seul mot, que se passerait-il si cette personne vous donnait quelques mots? Et si les mots qu'ils vous ont donnés comprenaient un point mettant fin à la phrase? Si vous l'avez rempli, vous constaterez peut-être que ce qui a été fourni «correspond», mais cela change radicalement l'histoire plus que n'importe quel mot que vous remplissez normalement ne pourrait jamais faire. Vous pourriez, si vous aviez de l'espace, ajouter des paragraphes entiers à la Mad Lib et en faire quelque chose de très différent.

C'est, en termes non techniques, une injection SQL en un mot. Vous fournissez des "espaces vides" pour les données qui seront insérées dans une commande SQL, un peu comme des mots dans une Mad Lib. Un attaquant entre alors une valeur qui n'est pas celle que vous attendez; au lieu d'une simple valeur à rechercher, il entre un morceau d'instruction SQL qui termine celle que vous avez écrite, puis ajoute sa propre commande SQL après cela en tant que nouvelle «phrase». L'instruction supplémentaire peut être très dommageable, comme une commande pour supprimer la base de données ou pour créer un nouvel utilisateur avec beaucoup d'autorisations dans le système. L'ordinateur, ne connaissant pas la différence, effectuera simplement toutes les tâches qui lui sont demandées.

Un autre excellent moyen d'expliquer à quelqu'un sur quoi que ce soit (y compris l'injection SQL) est à l'aide de personnages de dessins animés et à encadrer une histoire autour d'eux.

Selon moi, c'est la meilleure image disponible sur Internet, l'expliquant de manière assez sympa.

Source: http://xkcd.com/327/

Je l'expliquerais comme étant un peu comme dire à un caissier que le client a toujours raison et qu'il doit faire tout ce qu'il peut pour répondre à ses besoins. Ensuite, comme il n'y a pas de vérification du caractère raisonnable de la demande, lorsqu'un client arrive et dit qu'il veut que tout le magasin soit gratuit, le caissier charge tout l'inventaire dans son camion pour lui.

Ce n'est pas Ce n’est pas une explication parfaite, mais cela donne l’idée que le code est invité à faire tout ce que l’utilisateur met, puis le méchant utilise cette instruction pour s'en tirer avec les marchandises.

Je suppose que c'est vraiment dépend du type de point que vous essayez de faire passer.

Tout dépend du degré de non-technicité dont vous parlez ici, mais je décrirais généralement l’injection SQL aux gens d’affaires quelque chose du genre -

"une faiblesse dans la façon dont certains sites Web gérer les entrées des utilisateurs (par exemple lorsque vous mettez votre nom dans un formulaire d'inscription) qui peuvent permettre à un attaquant d'accéder à la base de données stockant toutes les informations utilisateur pour le site "

s'ils veulent un peu plus de détails que cela.

"Certaines applications Web ne séparent pas correctement les entrées utilisateur des instructions pour la base de données, ce qui peut permettre aux attaquants d'instruire directement la base de données, via les informations qu'ils remplissent dans le formulaire du site Web. Cela peut permettre l'attaquant de lire les informations d'autres utilisateurs hors de la base de données, ou de modifier certaines des informations qu'elle contient. "

Je pense que vous pouvez obtenir le meilleur effet en démontrant simplement l'attaque. Rédigez un formulaire Web d'aspect inoffensif et affichez le résultat de la requête en utilisant l'entrée utilisateur. Ensuite, après avoir entré votre propre entrée préparée, votre public aura une "expérience aha" après avoir trouvé des mots de passe dans le résultat. J'ai créé une telle page de démonstration, cliquez simplement sur la "flèche suivante" pour remplir une entrée préparée.

P.S. Si vous rédigez vous-même une telle page, veillez à ne pas autoriser les testeurs à obtenir des privilèges indésirables. Le mieux est que vous exécutiez seul la démo sur votre système local avec les privilèges de base de données les plus bas possibles (tous les types d'attaques ne devraient pas être possibles, ce n'est qu'une démo). Faites une liste blanche des expressions autorisées.

La base de données est comme un génie magique (ou, Oracle ) qui exauce les souhaits. Nous avons dit à notre génie de n'accorder que trois souhaits au maximum, mais si nous ne vérifions pas ce que les gens souhaitent, quelqu'un le déjouerait facilement en demandant quelque chose d'intelligent comme "cent autres souhaits" ou "les souhaits de tous les autres" .

Expliquez-le simplement comme suit:

Le système peut prendre des requêtes avec des données de n'importe quel utilisateur pour faire quelque chose avec.

Le système lui-même a des fonctionnalités pour fonctionner comme supprimer ou modifier les données.

Un attaquant tente d'exécuter l'une de ces fonctions pour gagner ou détruire quelque chose.

Par conséquent l'attaquant met des commandes valides dans les requêtes.

Le système exécute ces commandes, exécutant ce que l'attaquant veut.

Imaginez une grande entreprise qui conserve tous ses dossiers sous forme papier dans une grande pièce remplie de classeurs. Afin de récupérer ou d'apporter des modifications aux fichiers, quelqu'un remplira un simple formulaire de remplissage des blancs, puis ce formulaire sera envoyé à un employé qui suit les instructions du formulaire.

Par exemple :

Récupérez les enregistrements de facturation de la date de début _ _ _ à la date de fin _ _ _ où se trouve le client _ _ _

Cela deviendrait normalement quelque chose comme ceci:

Récupérez les enregistrements de facturation de la date de début 01/01/2011 à la date de fin 31/12/2011 où le client est Billy Joe Bob

Mais entre les mains d'une personne sans scrupules, peut-être que ce formulaire pourrait être utilisé à d'autres fins, par exemple:

Récupérez les enregistrements de facturation de la date de début 01/01/2011 à la date de fin 31/12/2011 où le client est Robert Mensas et récupérez également les numéros de carte de crédit de tous les clients

En prétendant que leur nom est o inclut d'autres commandes, ils peuvent détourner le formulaire de remplissage, et si le greffier n'a pas été formé pour gérer ce genre de choses, alors peut-être qu'il exécutera simplement les instructions sans y penser et remettra toutes les informations de carte de crédit à un utilisateur.

Ou, alternativement:

Récupérez les enregistrements de facturation de la date de début 01/01/2011 à la date de fin 12 / 31/2011 où le client est Robert Mensas et ajoute également 100 000 $ au solde du compte de Robert Mensas

Ce qui présente un potentiel tout aussi dangereux.

L'astuce avec les injections SQL est de s'assurer que votre code est suffisamment intelligent pour être en mesure de garantir que les utilisateurs ne peuvent pas modifier l'intention des commandes que vous envoyez à la base de données et ne peuvent pas récupérer des données ou apporter des modifications qui ils ne devraient pas être autorisés à le faire.

Parfois, les pirates mettent des commandes informatiques / de programmation dans des boîtes sur Internet pour inciter le site Web à faire quelque chose qu'il ne devrait pas. Par conséquent, nous vérifions les informations saisies sur les sites Web pour ce qui pourrait être une «commande».

... à qui expliquez-vous cela de toute façon?

Si vous n'avez pas besoin de le faire rapidement et d'avoir une feuille de papier à portée de main, faites une démonstration complète. SQL est assez similaire au langage naturel, alors prenez une simple requête et démontrez l'attaque:

  SELECT * FROM data WHERE key = $ id  

" $ id est remplacé par ce qui est visible ici pointe vers le paramètre d'URL . Normalement, il s'agit d'un nombre comme 1 . Cela nous donne: "

  SELECT * FROM data WHERE id = 1  

"Maintenant, si quelqu'un met plus qu'un simple nombre là-bas, il est également inclus. Par exemple, si quelqu'un y met 1 OU 1 = 1 , nous obtenons ceci "

  SELECT * FROM data WHERE id = 1 OR 1 = 1  

" Pouvez-vous Maintenant, sur ce système, il est également possible d'émettre plusieurs commandes, appelées requêtes, si vous les séparez simplement par un point-virgule. Pouvez-vous deviner ce qui se passe si quelqu'un met 1; DELETE TOUT; ?"

  SELECT * FROM data WHERE id = 1; SUPPRIMER TOUT;  

"La commande actuelle est DROP DATABASE ou DROP TABLE , mais vous voyez l'idée."

Je pense que l'exemple le plus simple, le plus clair et le plus amusant est tiré de "The Simpsons": les farces de Bart:

https://en.wikiquote.org/wiki/List_of_Simpsons_Prank_Calls

Example:

Moe: [répondant au téléphone] Moe's Tavern.

Bart: Bonjour, est-ce qu'Al est là ?

Moe: Al?

Bart: Oui, Al. Nom: Coholic.

Moe: Laissez-moi vérifier ... [appels] Appel téléphonique pour Al. Al Coholic. Y a-t-il un Al Coholic ici? [rires des clients du bar]

Moe: Attends une minute. [au téléphone] Écoute, petit crétin de rat à ventre jaune. Si jamais je découvre qui tu es, je te tuerai! [raccroche]

Bart et Lisa: [rires]

Homer: J'espère que tu trouveras ce punk un jour, Moe.

En quoi est-ce une bonne analogie? Un "nom" qui est répété négligemment sans vérification entraîne un comportement involontaire.

Lien YouTube vers une compilation de ces farces téléphoniques pour vous aider à choisir l'exemple le plus approprié.

L'injection SQL est lorsqu'un utilisateur malveillant tente d'obtenir des informations d'un site Web auquel il n'est pas autorisé à accéder.

C'est un peu comme interroger une autre personne, où l'interrogateur est l'utilisateur malveillant et la personne interrogée est le site Web.

Les choses que l'interrogateur pourrait faire sont:

• Faites des recherches sur les antécédents de la personne pour trouver une faiblesse
• Utilisez diverses techniques connues qui ont fonctionné dans le passé sur d'autres personnes
• Trouvez de nouvelles techniques à utiliser

Certaines faiblesses de la personne interrogée peuvent être:

• La formation de la personne
• L'intelligence de la personne
• La famille de la personne
• Le type de personne qu'elle est

Ce qu'il faut noter, c'est qu'il y a de meilleurs interrogateurs que d'autres et que certaines personnes parleront tout de suite tandis que d'autres ne le feront peut-être jamais.

Bien expliquer avec une analogie technique, c'est bien mais je semblerais un peu long et boiteux.

Je voudrais juste expliquer que c'est une question de paperasse stricte ou d'exigences pour limiter les abus dans les administrations et les finances.

Si c'est fait de manière assez stricte, vous avez moins de poissons maléfiques capables de passer à travers le filet.

J'utiliserais un dessin simple avec un pseudo-code très simple avec des cases et des flèches, et expliquer l'analogie des robots et des boîtes.

Mon approche pour un non-technicien:

Supposons que vous travaillez dans un grand immeuble de bureaux. Chaque employé a sa propre clé de son bureau (= requête SQL que le programmeur voulait exécuter). Maintenant, quelqu'un prend un fichier aiguille et modifie un peu sa clé, c'est-à-dire en supprimant une épingle (= SQL-Injection, en changeant la requête SQL). Cette clé modifiée peut ouvrir différentes (ou peut-être toutes les portes). Ainsi, le greffier a accès à plus ou à tous les bureaux de cette maison et peut lire / modifier les documents d'autres bureaux.

Tout le monde est probablement habitué à utiliser des clés et des serrures, donc cela devrait être facile à comprendre et de mon point de vue, c'est une bonne analogie avec une injection SQL.

La chaîne YouTube Live Overflow a une superbe vidéo intitulée "Injection Vulnerabilities - or: How I got a free Burger". Description de la vidéo:

Un soir, j'ai commandé de la nourriture et j'ai accidentellement injecté un Burger dans la commande. Le livreur a confondu un commentaire comme un autre article de la liste de commande et l'a fait. Même si aucun prix n'y était attaché.

Voici ma tentative:

Remplacez "site" par "maison" et "attaquant | hacker" par "cambrioleur".

L'injection SQL est le résultat de laisser les fenêtres ouvertes (* avec un énorme néon disant "OUVERT") d'une maison alors que vous avez des portes avant et arrière en acier inoxydable de 10 "d'épaisseur.

Le cambrioleur veut s'introduire par effraction et voler votre chaîne stéréo, mais d'abord, il doit trouver comment entrer par effraction, il voit que les portes sont pratiquement impossibles à casser, cependant, après une enquête plus approfondie, il voit que les fenêtres sont ouvertes. Il ne peut pas voler vos meubles (pas en un seul morceau au moins), mais il peut voler votre chaîne stéréo, ordinateur portable, PC, etc.

*) un peu dramatique, je sais (:

Cela dépend toujours de la personne qui vous écoute mais c'est ainsi que je lui expliquerais -

Imaginez quand vous envoyez un télégramme avec un message comme -

"Bonne année! Faites attention. - Fred "

et quelqu'un qui n'a pas de bonnes intentions qui pouvait accéder à votre télégramme intercepterait et remplacerait les mots surlignés par -

"Bonne année! Merci de nous envoyer de l'argent. - Fred "

J'espère que cela aide! :)