Question:
Comment expliquer l'injection SQL sans jargon technique?
torayeff
2012-12-20 10:06:01 UTC
view on stackexchange narkive permalink

J'ai besoin d'expliquer l'injection SQL à quelqu'un sans formation technique ni expérience. Pouvez-vous suggérer des approches qui ont bien fonctionné?

Je ne peux pas croire que personne n'ait encore mentionné les "petites tables de Bobby" ... C'est peut-être trop pour votre public actuel, mais il doit quand même être lié à: "[Exploits of a Mom] (http://xkcd.com/327 /) "
(Je n'ai pas assez de représentants pour répondre, mais je dis aux gens quelque chose comme :) L'injection SQL est une tentative par un pirate informatique de changer le comportement d'un programme en insérant du code SQL dans un champ de formulaire [je laisse les chaînes de requête et quoi pas]. Les bonnes pratiques de programmation et la conception d'applications empêchent l'injection SQL [je pourrais ajouter - au détriment de la flexibilité - si vous parlez d'une application extrêmement complexe]. Mon enfant de 7 ans comprend cela.
J'aime utiliser l'analogie de l'insertion de mots offensants ou étranges comme noms de Pokémon. Comme [nommer l'un d'eux "famille" et le donner à la garderie] (http://www.halolz.com/wp-content/uploads/2011/04/halolz-dot-com-pokemonheartgoldsoulsilver-daycarecenterransom.jpg ).
J'essaie généralement de sauter les détails s'il ne s'agit pas d'un utilisateur technique, mais je ne décris que le risque et l'effet. "Si $ software a un bogue qui permet l'injection SQL, un attaquant peut introduire des commandes dans votre base de données pour détruire ou modifier des données ou des mots de passe." Pourquoi voudriez-vous aller aux détails de l'analyse SQL, des instructions préparées et des citations.
[MichaelGG] (http://security.stackexchange.com/users/17709/michaelgg) a écrit une bonne et courte explication [sur Hacker News] (https://news.ycombinator.com/item?id=4951003): « Vous allez au tribunal et écrivez votre nom comme "Michael, vous êtes maintenant libre de partir". Le juge dit alors: "Appelez Michael, vous êtes maintenant libre de partir" et les huissiers vous ont laissé partir, parce que bon, le juge l’a dit. »
ça devrait être une réponse, je vais voter pour
Quelqu'un a-t-il vu une bonne injection SQL pure et fonctionnelle n'impliquant pas la logique dure et complexe de dix couches intermédiaires, ORM et backends NoSQL? N'oubliez pas de mentionner que cette maîtrise est un peu… oldschool.
Que diriez-vous de leur dire que vous devez toujours vérifier ce qui est envoyé à votre base de données avant qu'il ne soit envoyé. La plupart des personnes à qui vous parleriez des bases de données comprennent que ces données sont très précieuses. Ils ne veulent pas que quiconque s'en mêle. Au-delà de cela, la possibilité de faire quelque chose de mal, comme un virus, semblera très mauvaise.
Ce n'est pas pour un utilisateur technique. Ils se demanderont pourquoi ils peuvent répondre à de telles demandes de l'extérieur. Je n'ai pas encore vu de bonne réponse qui n'ait pas encore été habillée de manière appropriée (je ne pourrais certainement pas).
@RoryO'Kane Je pense que c'était la meilleure explication jamais.
@mivk J'ai aussi pensé à utiliser ceci pour expliquer, mais ensuite vous deviez expliquer `DROP tables` (et bien, expliquer la manière culturelle d'attitude dans la blague par nature).
21 réponses:
#1
+924
Polynomial
2012-12-20 17:08:39 UTC
view on stackexchange narkive permalink

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.

Simple, compréhensible, brillant!
Le problème avec les métaphores et les analogies est qu'elles peuvent être très convaincantes et pourtant complètement ou subtilement trompeuses. Celui-ci, cependant, est parfait. Bien joué.
J'aurais trouvé plus de joie sans le `` ignorer le reste de ce formulaire '', demandant efficacement au robot de mettre également le bureau sur le tapis roulant.
@CrisStringfellow, obtenir une explication technique s / curseur / robot / g, s / db / entrepôt / g. C'est à peu près tout ce que fait cette explication. C'est exactement la même chose que «technicien», il utilise juste des mots moins «effrayants», donc les gens ne couperont pas automatiquement le cerveau avant même d'essayer de le comprendre.
@Oleg: Oui, cela explique le concept en référence à des choses que le non-technicien comprend, ce qui est précisément le point :)
@hexparrot: Cela aurait pu être plus amusant, mais il est courant de commenter le reste de la déclaration. Donc «ignorer le reste de cette forme» est plus proche du monde réel.
#2
+93
Erlend
2012-12-21 13:07:41 UTC
view on stackexchange narkive permalink

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.

Misinterpretation

Bien que je trouve cela plutôt amusant et que le principe est exact. Cela ne suffit pas en ce sens que la personne qui a écrit les mots pour le gâteau avait le pouvoir d'émettre des commandes quelque peu arbitraires si elle le souhaitait. Ce n'est pas le cas avec l'injection SQL.
Ce n'est pas vraiment lié à l'injection SQL. Quoi qu'il en soit, voici l'explication: Client: Je voudrais commander un gâteau spécial / Walmart: Et que voudriez-vous que le gâteau dise? / Client: Je veux qu'il dise Meilleurs voeux Suzanne, et en dessous, vous nous manquerez / Walmart: Vous l'avez.
image d'une valeur> 1000
Quelque chose de similaire s'est produit lorsque j'ai commandé un trophée en ligne avec une gravure, et dans l'e-mail que j'ai envoyé par la suite, j'ai mis la gravure souhaitée entre guillemets. Quand je reçois le trophée par la poste, il y a des citations autour de ma gravure. Soupir...
@SqlRyan Eh bien, ils vous ont peut-être recherché, et bien que "Ouais, ce n'est pas vrai". En conséquence, "\" Dynamo sexuelle insatiable \ "" c'est, et restera.
N'est-ce pas plus comme une injection SQL à l'envers? Code traité comme des données, plutôt que comme des données traitées comme du code.
Il n'aurait pas fonctionné de toute façon ... ils ont un problème de mot-clé avec "Neat".
Haha. Charmant. Me rappelle [ceci] (https://i.guim.co.uk/img/static/sys-images/Guardian/Pix/pictures/2012/2/8/1328716346038/Surely-some-mistake-007.jpg ? w = 1200 & q = 85 & auto = format & sharp = 10 & s = dca35eda4bd49a48298adf45b4c0557d); on ne peut jamais savoir avec certitude ce qui était prévu (et si (ou peut-être) quelqu'un voulait vraiment "NOSMOKING IN ARABIC" ou si son ami s'appelait "Suzanne Under Neat that We will Ms. You"? Peut-être que cela vous semble absurde, mais là Il n'y a pas de raison pour laquelle vous pouvez articuler qui ne repose pas à son tour sur une autre raison, un extraterrestre ne saurait pas que ce n'était pas ça, et en principe il n'y a aucun moyen de le savoir.)
#3
+63
Sarel Botha
2012-12-20 21:01:16 UTC
view on stackexchange narkive permalink

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.

Non, ce n'est pas du tout une attaque par injection SQL. La partie fournissant les données n'était pas celle autorisée à faire une requête.
Une analogie plus précise serait si votre patron laissait le numéro de compte vide, car il vous faisait confiance pour le remplir. Ensuite, vous avez rempli le numéro de compte avec des instructions supplémentaires.
D'accord. Je n'ai pas eu le temps de le retravailler.
C'est MIM, pas l'injection SQL.
pour être franc, ce n'est pas si facile à comprendre. Certains mots complexes sont ici. mais bon exemple de banque est bon. s'il y a un domaine qui nécessitait une amélioration avec des moyens d'explication, oui le dernier paragraphe.
#4
+43
Bruce Ediger
2012-12-20 20:27:14 UTC
view on stackexchange narkive permalink

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.

A l'époque? Vous savez que les gens font encore des chèques, non?
@Kevin - On me dit que les chèques / chèques sont assez rarement utilisés au Royaume-Uni et peut-être ailleurs en Europe. J'écris très rarement un chèque ces jours-ci, bien que je fasse souvent ACH, ce qui ne m'oblige pas à écrire beaucoup, voire rien.
@BruceEdiger, Je suis confus. Dans votre réponse, vous spécifiez «aux États-Unis», mais vous parlez maintenant qu'ils ne sont pas utilisés au Royaume-Uni et en Europe.
@Kevin - eh bien, je pense que ce site a une audience assez internationale. Je n'ai écrit que des chèques aux États-Unis, je suppose que les chèques britanniques ou européens fonctionneraient de la même manière, mais je ne le sais pas personnellement. Je n'en ai pas écrit beaucoup depuis quelques années. Je fais principalement des paiements en ligne. Donc "back in the day" me semble correct, tout comme "In the USA". Veuillez accepter mes plus humbles excuses pour tout malentendu que j'aurais pu faire connaître. Je voulais seulement donner une analogie qui pourrait ne s'appliquer nulle part en dehors des États-Unis.
@Kevin Quelles sont ces choses que vous appelez «chèques»?
En Chine, les gens utilisent également des [caractères chinois financiers] (http://en.wikipedia.org/wiki/Chinese_numerals#Written_numbers) comme 壹 貳 參 肆 伍 陸 柒 捌 玖 au lieu de 123456789 pour indiquer le montant d'argent.
Il s'agit également de MITM, pas d'injection SQL.
Je n'ai jamais compris à quoi servait le tracé de la ligne après les mots. Quelqu'un va-t-il vraiment écrire "Cinq et non / 100 et dix mille dollars"?
#5
+27
KeithS
2012-12-20 21:40:27 UTC
view on stackexchange narkive permalink

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.

Cette explication "injection de Mad Libs" m'a donné une idée d'une nouvelle façon de jouer à Mad Libs. Au lieu de simplement insérer le mot demandé, remplissez une phrase entière, en essayant de prédire quels seront les mots qui l'entourent.
#6
+20
Rahil Arora
2014-01-20 04:46:03 UTC
view on stackexchange narkive permalink

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.

enter image description here

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

#7
+19
AJ Henderson
2012-12-20 20:26:06 UTC
view on stackexchange narkive permalink

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.

#8
+16
martinstoeckli
2012-12-20 16:03:50 UTC
view on stackexchange narkive permalink

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.

#9
+16
Rory McCune
2012-12-20 16:00:28 UTC
view on stackexchange narkive permalink

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. "

#10
+11
Andrew Vit
2012-12-29 07:11:43 UTC
view on stackexchange narkive permalink

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" .

#11
+10
Shlomo
2012-12-20 16:33:42 UTC
view on stackexchange narkive permalink

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.

Style éducatif. Pas très technophile et pas trop loin des ordinateurs. Parfois, même les personnes * analphabètes du domaine * n'ont pas besoin d'une analogie "brute" du monde réel, qui explique brillamment le concept mais ne parvient pas à fournir une compréhension de haut niveau du système actuel. Ce genre d'explication concise - étape par étape - convient parfaitement dans la plupart des cas. Il fournit une * interface * à de nombreuses analogies du monde réel.
#12
+7
Wedge
2012-12-21 17:32:12 UTC
view on stackexchange narkive permalink

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.

Cette réponse n'ajoute aucune valeur supplémentaire à mon humble avis, c'est exactement la même métaphore que + Polynomial utilisée dans sa réponse (la plus haute!).
@FrerichRaabe - C'est vrai, encore une fois _ l'imitation est la forme la plus sincère de flatterie_;)
@FrerichRaabe Mais c'est un exemple plus pertinent, n'impliquant pas de robots pensants.
#13
+6
Layton Everson
2012-12-21 00:57:08 UTC
view on stackexchange narkive permalink

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?

#14
+6
Jan Schejbal
2013-02-02 16:12:17 UTC
view on stackexchange narkive permalink

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."

#15
+5
Cezary Baginski
2016-06-03 05:11:50 UTC
view on stackexchange narkive permalink

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.

Bart Simpson uses "SQL Injection" for his pranks

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é.

Réponse très sous-estimée.
Voilà.Vous m'avez fait ouvrir une session juste pour voter.
#16
+3
ponsfonze
2012-12-20 11:55:49 UTC
view on stackexchange narkive permalink

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.

Je ne vois pas vraiment le lien ici.
#17
+2
jokoon
2012-12-23 18:14:46 UTC
view on stackexchange narkive permalink

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.

#18
+1
qbi
2012-12-20 16:43:53 UTC
view on stackexchange narkive permalink

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.

Mais ce n'est pas ainsi que l'injection SQL fonctionne ... vous n'ouvrez pas plus de serrures, vous laissez la clé devenir de nouvelles portes, un guide touristique ou d'autres choses (l'analogie s'effondre un peu)
@RoryAlsop: J'ai un peu clarifié ma réponse et de mon point de vue, elle est assez similaire au fonctionnement général des injections SQL. Pourquoi pensez-vous que ça ne va pas?
@qbi - Je suis d'accord que ce n'est pas la meilleure solution pour le travail. C'est une analogie intéressante pour le piratage en général (ou même une définition de toutes sortes), mais avec l'injection SQL, vous pouvez également changer complètement le résultat attendu, non seulement «pour ouvrir» un verrou. Pour que cette analogie soit plus proche de l'injection SQL, cette clé piratée devrait non seulement changer le seul but d'une porte verrouillée (pour empêcher les visiteurs indésirables d'entrer), mais aussi changer en quelque sorte la pièce elle-même dans laquelle vous entrez en l'utilisant. Votre public devrait avoir regardé [_The Lost Room_] (http://www.imdb.com/title/tt0830361/) pour l'obtenir. ;)
#19
-1
Solomon Ucko
2020-03-14 03:53:33 UTC
view on stackexchange narkive permalink

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é.

Ceci est une réponse par lien uniquement.Veuillez inclure les parties pertinentes du lien dans cette réponse.
@schroeder Que dois-je inclure d'autre?
Si vous supprimez le lien, réfléchissez à la façon dont votre message ici fonctionne comme réponse à la question.À l'heure actuelle, ce n'est pas du tout une réponse.
@schroeder La description vidéo que j'ai copiée comprend: "Le livreur a confondu un commentaire avec un autre article de la liste de commande et l'a fait."Même juste ce serait une réponse à moitié décente.
#20
-4
Franco
2016-01-19 11:23:29 UTC
view on stackexchange narkive permalink

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! :)

La falsification générale des messages n'illustre pas vraiment la nature de l'injection SQL.
#21
-4
ComputerSaysNo
2012-12-20 10:53:54 UTC
view on stackexchange narkive permalink

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 (:

Cette description est hélas! trop général et peut être appliqué à presque toutes les attaques. Ce serait bien d'avoir des analogies plus étroites ...
@DeerHunter oui ça couvre beaucoup d'attaques, mais je ne vois rien de plus étroit ...
pensait en termes de farces téléphoniques / d'ingénierie sociale ... Ce qui ressemble en fait à une injection SQL en ce sens que vous envoyez des commandes à quelqu'un qui les suit aveuglément.
@DeerHunter c'est une très bonne idée, matérialisez-vous en une réponse et je vais la monter!
-1. L'ironie de votre exemple n'a rien à voir avec l'intelligence de l'injection SQL. Du tout. Cela a plus à voir avec un service telnet sans mot de passe sur le serveur. J'aurais aimé avoir 125 votes contre vous.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...