Question:
Y a-t-il une longueur de champ trop courte pour permettre une injection SQL nuisible?
James Jenkins
2017-02-28 22:18:55 UTC
view on stackexchange narkive permalink

J'étais en train de lire sur l'injection SQL et j'ai vu ceci, ce qui m'a fait réfléchir:

champs de saisie aussi petits que possible pour réduire la probabilité qu'un pirate puisse insérer du code SQL dans le champ sans qu'il soit tronqué (ce qui conduit généralement à une erreur de syntaxe T-SQL).

Source: Microsoft SQL Server 2008 R2 Unleashed

Quelle est la taille de champ la plus courte où l'injection SQL peut causer des dommages?

Les dommages étant la modification de la base de données ou le renvoi de résultats non prévus par la conception. Inclure un marqueur de commentaire de fin ( - ) dans un champ à deux caractères ne causerait pas de dommage, cela provoquerait simplement un échec de la requête. Le pirate informatique potentiel peut apprendre que le champ est susceptible d'être injecté, mais il ne peut pas en tirer parti.

Si l'erreur donnée est verbeuse, cela peut être suffisant pour obtenir des informations utiles, en particulier lorsqu'un développeur a traité les noms de table comme "secrets" ...
L'injection SQL n'est pas toujours effectuée sur un champ d'entrée - vous pouvez cibler des clauses orderby dans des URL, par exemple où vous pourriez exécuter un SQL malveillant.La taille limitée d'un champ ne va pas arrêter cela.
@iain: Bon point.De plus, limiter la longueur des champs pour (je suppose) les données de formulaire HTML reçues ne me semble pas un bon moyen d'éviter l'injection SQL.L'évitement des injections SQL est fondamentalement un problème résolu;laissez simplement la bibliothèque de connexion à la base de données le gérer en utilisant des instructions préparées avec des espaces réservés, au lieu de coller des requêtes en utilisant les fonctions de chaîne de votre langage de programmation et de vous tromper parce que vous avez oublié de vous protéger contre la faille numéro 59654.
@Pascal "* L'évitement des injections SQL est fondamentalement un problème résolu; *" ne s'applique qu'au nouveau code où des considérations appropriées ont été appliquées.Il existe beaucoup de code où le problème n'a pas été résolu.Vraisemblablement, il y a une longueur de caractère en dessous de laquelle la résolution des problèmes existants est moins urgente que celle de plus longues longueurs.
Suis-je le seul à penser que ce livre devrait être brûlé publiquement?Les requêtes paramétrées existent depuis si longtemps que l'auteur me laisse croire qu'ils n'ont même pas la moitié de ce dont ils parlent.On dirait qu'ils ont copié et collé des déchets d'une collection de blogs et ont publié un livre.Ils pourraient aussi bien vous dire que vous devriez vous entraîner à vous faire tirer dessus avec des balles plus petites afin de vous immuniser contre les balles plus grosses.
@MonkeyZeus C'est plus la règle que l'exception pour les livres techniques.Lorsque des professionnels non spécialisés dans la sécurité offrent des conseils de sécurité, ceux-ci sont souvent de mauvaise qualité.
Que diriez-vous de 0 caractères?Et seulement si validé sur le serveur.
@Xander Cette déclaration me cause beaucoup de détresse.Je ne suis certainement pas non plus un expert en sécurité, mais mon seul paragraphe décime probablement tout ce que ce livre a à offrir.Je suppose que [Argument de l'ignorance] (https://en.wikipedia.org/wiki/Argument_from_ignorance) a toujours une popularité insondable.La seule petite grâce possible pour ce livre serait si le paramétrage n'était pas pris en charge dans cette version de SQL Server.De plus, si c'est la règle plus que l'exception, nous allons avoir un feu puissant et fin.
@MonkeyZeus Je conviens que c'est pénible, mais je me suis un peu fait un passe-temps de passer en revue les conseils de sécurité dans les livres techniques et les livres de programmation en particulier.La couverture est généralement soit épouvantable, soit complètement absente.Par exemple, j'ai un livre sur la création de systèmes de commerce électronique à partir de zéro qui discute brièvement de l'utilisation du HTTPS, puis déclare que les discussions ultérieures sur la sécurité étaient «hors du cadre» du livre.
@Xander Je dirais que «regarder ailleurs» est plus noble que de prétendre effrontément quelque chose comme «obscurcissez vos données de formulaire en utilisant JavaScript et une clé aléatoire générée par le serveur avant d'envoyer des données à votre serveur».Au moins, ce livre sur le commerce électronique dit: "Hé, nous ne voulons pas que votre serveur soit esquivé par un phallus en papier de verre, alors si vous vous souciez de la sécurité, procurez-vous un bon livre à ce sujet.- site de commerce, pas comment en sécuriser un. "
Je suis contre la gravure de livres par principe - mais je voterais pour ramener les stocks pour les auteurs - "ce qui conduit généralement à une erreur de syntaxe T-SQL" - tout l'intérêt de l'injection SQL est de faire interagir vos données soumises avec lelimites de la destination prévue.
Comme pour les autres réponses, de courtes longueurs de champ n'empêcheront pas les problèmes.J'ai récemment travaillé sur une application héritée avec un champ de nom d'utilisateur de 8 caractères (et 8 caractères ont été vérifiés dans le code), mais elle était toujours ouverte à l'injection SQL.Les choses ont empiré lorsque le champ du mot de passe a également été utilisé dans l'injection.
Bien que je sois d'accord à 100% sur la façon dont ces problèmes de sécurité sont généralement abordés et à quel point les conseils de ce livre sont mauvais, je pense que ce conseil est mauvais principalement parce qu'il est très susceptible de permettre aux gens de se tromper en pensant qu'en prenant cette "précaution«ils se sont protégés contre l'injection SQL, et c'est également mauvais car cela encourage la poursuite de la réduction des risques dans un cas où l'élimination des risques serait possible (et facile).Il n'y a aucun moyen de nier que cette citation ne prétend pas empêcher l'injection SQL;il prétend simplement "réduire la probabilité" (ce qui est ridicule et trompeur).
@MonkeyZeus De nombreuses API de base de données * ne parviennent toujours * pas à prendre en charge les paramètres de tableau, tels que ceux du côté droit de l'opérateur «IN».Pour contourner ce problème, vous devez inclure un nombre variable de paramètres dans une requête, à quel point vous finissez par "coller ensemble" une liste d'espaces réservés et en conservant l'ordre des espaces réservés positionnels (`?`) Synchronisé entre l'instructionet le tableau de valeurs est aussi difficile que de s'échapper.
Huit réponses:
Xander
2017-02-28 23:18:13 UTC
view on stackexchange narkive permalink

Sans contexte, je vais supposer que l'auteur fait référence aux champs de saisie dans une application cliente. L'exemple le plus simple à utiliser serait un formulaire dans une page HTML dans une application Web, bien que ce que je suis sur le point de décrire est efficace pour pratiquement n'importe quel type d'application cliente.

Dans ce contexte, la réponse est non, il n'y a pas de longueur maximale de champ d'entrée suffisamment courte pour vous protéger de l'injection SQL, car vous ne contrôlez pas la longueur maximale du champ d'entrée . L'attaquant le fait. Lorsque le formulaire contenant le champ de saisie vit sur le client (comme dans une fenêtre de navigateur sur la machine de l'attaquant), il est en dehors de la limite de confiance et hors de votre contrôle. Il peut être manipulé de n'importe quelle manière que l'attaquant veut ou a besoin, ou évité complètement. N'oubliez pas que pour une application Web, tout ce que vous obtenez est une requête HTTP. Vous n'avez aucune idée de la façon dont il a été créé, et aucune raison de croire que tout ce que vous avez demandé au navigateur de faire s'est réellement produit, que des contrôles de sécurité côté client ont été réellement exécutés, que tout dans la requête est comme que vous vouliez ou en aucune façon sûr.

Donc non, la longueur du champ d'entrée n'est pas un mécanisme de prévention d'injection SQL valide, et ne faites jamais confiance à une entrée qui traverse une limite de sécurité sans la valider.

c'est une bonne réponse, peut-être que l'auteur veut dire qu'un champ trop court réduit la probabilité d'obtenir des informations à partir de bases de données, mais il ne peut pas éviter un dommage d'une injection SQL, par exemple, `ou 1 = 1` peut causer de gros dommages.
@hmrojas.p Ce n'est pas le cas, car une longueur maximale de fichier d'entrée n'empêche pas réellement un utilisateur malveillant d'envoyer autant de données qu'il le souhaite dans ce domaine.Je peux définir une longueur maximale d'entrée à 3, et un attaquant pourrait toujours envoyer ou 1 = 1; supprimer les utilisateurs de la table; - Si vous ne cochez pas côté serveur, rien ne l'empêche.
Oui, je suis d'accord, je supposais qu'il y avait une validation de longueur côté serveur, je veux dire que ce type d'injection SQL (`ou 1 = 1`) pourrait affecter une requête SQL comme UPDATE ou DELETE, cela pourrait briser l'intégrité des donnéesmême si vous avez une validation de longueur côté serveur, cette mesure est complémentaire.
Alors, qu'en est-il si le serveur effectue cette validation alors.Les utilisateurs malveillants ne peuvent pas y toucher.Si mon script PHP n'utilise que les x premiers caractères (ce qui est extrêmement simple à faire et pourrait être fait au milieu de la requête), alors quoi?
@Ryan C'est en fait la clé.* Ce * serait le contrôle de sécurité.La définition de la longueur maximale du champ de saisie est une bonne chose pour l'UX, mais n'a aucune valeur de sécurité.C'est la validation d'entrée côté serveur qui assure la sécurité.C'est une distinction fondamentale et importante.C'est une distinction théorique puisque la bonne réponse est d'utiliser des requêtes paramétrées, mais en regardant strictement la gestion des entrées, c'est toujours une distinction importante.
J'ai voté contre parce que cela suppose que la longueur du champ n'est pas validée côté serveur.Bien que j'accepte que toute réponse doive mentionner que la longueur doit être validée côté serveur et en dehors du contrôle de l'utilisateur pour être utile, je crois que la validation côté serveur de la longueur invaliderait complètement votre réponse.(La réponse est peut-être toujours non, mais pas pour cette raison.)
@jpmc26 Le fait qu'il soit validé côté serveur n'a pas d'importance.Le contexte du devis est une mesure de «sécurité» côté client et la validation côté serveur n'est pas abordée.
@Xander La seule personne qui a assumé la validation uniquement côté client est vous.Je ne vois rien dans la question ou dans les commentaires qui suggère que c'est la situation décrite par le PO.
@jpmc26 De la question: * "champs de saisie aussi petits que possible" *.Le serveur sait-il ce qu'est un champ d'entrée lorsqu'il reçoit une réponse?Je veux dire que si vous soumettez un formulaire HTML, le serveur n'a pas de concept de "champ de saisie".Il obtient juste les données.Je pense que sans contexte du livre, la citation est un peu ambiguë.
@JacobAlvarez Le serveur sait évidemment quelles sont les entrées et peut discerner les valeurs s'il peut les insérer dans une requête SQL où l'injection peut se produire.S'il peut discerner les valeurs, il peut déterminer la longueur.Ne vous méprenez pas;la citation est absurde.Mais il en va de même pour des raisons indépendantes de savoir pourquoi c'est absurde, alors voyons les bonnes raisons.
@jpmc26, la citation dit "champ de saisie".C'est là que se produit l'interaction de l'utilisateur.Il est donc clair pour moi qu'il s'agit du côté client, pas du côté serveur.Il en va de même pour les formulaires qui effectuent la validation d'entrée JS.Sauf s'il est * explicitement indiqué * que la validation est * répétée * côté serveur, il est prudent de supposer que la validation côté serveur est inexistante.
@aross Pour autant que nous sachions, nous pourrions parler d'une interface REST qui ne fournit même pas d'interface graphique."Champ de saisie" ne signifie rien de plus pour moi que la valeur est générée par l'utilisateur.Mentionner que la validation de longueur doit être effectuée dans un environnement que l'utilisateur ne contrôle pas est tout à fait approprié.En supposant que cela n'arrive pas et en faisant de cela la base d'une réponse * entière *, c'est en fait simplement éviter de répondre à la question.
@jpmc26 Vous semblez confondre les paramètres avec les champs d'entrée.
@aross Il me semble que je pense au fait que les valeurs de ces "champs d'entrée" aboutissent * dans une requête SQL *.Il n'y a pas de différence pratique et le "champ de saisie" n'est pas strictement défini.L'idée qu'il s'agit d'une validation uniquement côté client est une * hypothèse totalement injustifiée * qui ne mérite rien de plus qu'une note d'accompagnement.Il ne répond * rien * à la question de savoir si la longueur compte dans le contexte de l'injection SQL.
Eh bien, si nous commençons une discussion sur la sémantique, voici quelques sources: [input] (https://en.wikipedia.org/wiki/Input_ (computer_science)), [parameter] (https: //en.wikipedia.org / wiki / Parameter_ (programmation_ordinateur))
Laissez-nous [continuer cette discussion dans le chat] (http://chat.stackexchange.com/rooms/54700/discussion-between-jpmc26-and-aross).
tim
2017-03-01 00:10:54 UTC
view on stackexchange narkive permalink

Non, il n'y a pas de longueur trop courte pour être exploitable (du moins dans certaines situations).

Un filtre de longueur n'est pas une protection valide contre l'injection SQL, et les instructions préparées sont vraiment les seulement une défense correcte.

Un filtre de longueur est cependant une bonne mesure comme défense en profondeur (tout comme les filtres entiers, les filtres alphanum, etc.). Il existe de nombreuses situations où, par ex. une entrée valide ne peut jamais dépasser, disons, 30 caractères, mais là où une exploitation significative nécessite plus. Cela devrait (mais probablement pas) aller sans dire que tout filtrage en tant que défense en profondeur doit avoir lieu côté serveur, car tout ce qui est côté client peut simplement être contourné.

Contournement de restriction

Les clauses de restriction (par exemple AND / OR ) peuvent être contournées par deux caractères, ce qui peut causer un préjudice réel, pas seulement une requête échouée. L'exemple le plus simple est un login (d'autres exemples seraient la suppression non autorisée de données supplémentaires):

  SELECT * FROM utilisateurs WHERE userid = [id] AND password = [password]  

Injection:

  id = 1 # password = mot de passe incorrect  

Charge utile: 2 caractères

DoS

Les attaques DoS nécessitent très peu de caractères. Dans un exemple MySQL, il faut 7 pour l'appel réel + x pour les secondes données + tout ce qui est nécessaire pour pouvoir appeler la fonction et corriger la requête.

Exemple:

  SELECT * FROM utilisateurs WHERE userid = [id]  

Injection (il s'agit d'une injection valide, une forme plus longue serait 1 AND sleep (99) ):

  sleep (99)  

Charge utile: 9 caractères

Lecture des données

Si les données s'affiche, la longueur dépend principalement du nom de la table et de la colonne. Je suppose que le nombre de colonnes est égal pour toutes les tables (cela peut arriver et cela enregistre les caractères).

Exemple:

  SELECT * FROM commentaires WHERE commentid = [id]  

Injection:

  1 union select * parmi les utilisateurs  

Charge utile: 27 caractères.

Modification des données

Des modifications non autorisées de la base de données peuvent également être effectuées avec quelques caractères.

Exemple:

  UPDATE users SET password = '[password]' WHERE id = [id]  

Injection (dans le mot de passe):

  ', isadmin =' 1  

Charge utile: 12 caractères

Un contournement de restriction fonctionnerait également (le résultat est que tous les mots de passe sont maintenant vides *):

  '#  

Charge utile: 2 caractères

* L'exemple de mot de passe est utilisé par souci de simplicité; les mots de passe doivent être hachés, ce qui rend l'exemple impossible. L'exemple s'applique toujours dans toutes les situations similaires (mise à jour d'un nom d'utilisateur, mise à jour des autorisations, etc.)

`Un filtre de longueur n'est pas une protection valide contre l'injection SQL, et les instructions préparées sont vraiment la seule défense appropriée. 'C'est la seule réponse valable.SQL sans instructions préparées me rappelle ["Stratégies pour monter un cheval mort"] (http://www.deadhorses.org/)
Bonne chance pour préparer une instruction avec un nombre variable d'espaces réservés, comme le côté droit de l'opérateur `IN`.
@DamianYerrick Je pense que c'est une hypothétique erronée.Pourquoi auriez-vous besoin de fournir à un utilisateur final des combinaisons infinies d'espaces réservés pour une clause `IN`?Il est assez facile d'avoir une poignée de modèles qui autorisent 1..n (pour un petit n).
Dans "SELECT * FROM utilisateurs WHERE userid = [id]", vous pouvez injecter a si a est le nom d'une colonne, vous avez donc une injection d'un seul caractère.
@ShawnC Le cas d'utilisation est qu'un utilisateur entre une liste d'éléments à interroger.D'une part, quelle est la taille d'un "petit n"?Cela semble enfreindre la règle zéro-un-infini.D'autre part, s'il existe deux champs d'entrée de valeur de liste différents, vous devez maintenant stocker et tester des modèles O (n ^ 2).
@Alexander: Veuillez noter que vous ne pouvez pas toujours utiliser des instructions préparées car elles ne peuvent pas paramétrer sur les noms de champs.Et lorsque vous devez créer vos jointures à partir des entrées de l'utilisateur, votre travail est devenu beaucoup plus difficile ...
@Joshua Ce sont des cas particuliers,> 99% des requêtes non paramétrées peuvent être paramétrées sans trop de tracas.Et pour les cas spéciaux, imposer que les noms de champ doivent adhérer à «[a-zA-Z] +» est beaucoup plus facile que d'autoriser certains caractères spéciaux dans les valeurs et d'en interdire d'autres.Faits amusants: lorsque je suis passé aux requêtes paramétrées en PHP, le principal problème était de trouver un fournisseur sur lequel mysqli était activé.[Mon principal problème dans DotNet était la clause `IN`.] (Http://stackoverflow.com/questions/20143012/sqlparameter-and-in-statement)
@Alexander: Y a-t-il un problème de sécurité avec l'exécution générant une requête de la forme `SELECT [peu importe] à partir de MyTable où id = @ @p0 OU id = @ @p1 OU id = @ @p2` pour le nombre de paramètres que l'utilisateur entre, si aucundu texte des paramètres est inclus dans la déclaration?
Serge Ballesta
2017-03-01 04:13:06 UTC
view on stackexchange narkive permalink

champs de saisie aussi petits que possible pour réduire la probabilité qu'un pirate puisse insérer du code SQL dans le champ sans qu'il ne soit tronqué (ce qui conduit généralement à une erreur de syntaxe T-SQL).

À mon humble avis, ce n'est que de la merde. Utiliser la longueur des champs d'entrée pour se protéger de l'injection SQL est un conseil terrible:

  • La seule façon correcte de se protéger de l'injection SQL est l'utilisation d'une instruction préparée. Les données d'entrée sont un paramètre de la requête et ne seront jamais utilisées comme texte SQL.
  • La taille d'un champ doit être contrôlée côté serveur car vous ne pouvez jamais faire confiance à ce qui vient dans une demande - il peut s'agir d'une fausse - et devrait être utilisé pour nettoyer les données avant de les utiliser dans la couche de gestion ou le stockage de la base de données.
  • Conseils pour utiliser autre chose que les meilleures pratiques est déroutant pour les développeurs novices.
benrifkah
2017-03-01 03:10:19 UTC
view on stackexchange narkive permalink

No.↑

Considérez la requête:

  select * from tweetsWHERE RowNum > = [offset] AND RowNum < [offset] + [limit]  

Si vous pouviez injecter un seul non-entier (par exemple, la lettre «a») pour offset , la requête aboutirait à une syntaxe une erreur et aucun message n'apparaîtrait, ce qui donnerait votre exigence "résultats non prévus par la conception" pour causer des dommages. Si vous pouvez injecter une chaîne vide, vous obtenez le même effet avec une charge utile de longueur nulle. Injecter un commentaire de fin serait un gaspillage de deux caractères;)

Un attaquant peut en tirer parti dans une attaque par déni de service (différemment d'un inondation de réseau généralement associée à DoS, mais toujours un DoS). Selon le service refusé, cela pourrait être catastrophique.

Comme d'autres réponses le suggèrent, la longueur du champ n'a aucune incidence sur l'impact de l'injection SQL. Les instructions préparées et paramétrées sont la voie à suivre, comme indiqué dans la Aide-mémoire OWASP SQL Injection Prevention.

Le déni de service et l'injection SQL sont deux choses très différentes.Cette réponse n'offre rien d'utile qui ne soit déjà abordé dans les réponses existantes.
Correct, l'injection SQL est une forme de la catégorie «attaque par injection», qui peut aboutir à de nombreuses fins différentes, y compris le déni de service.Le déni de service est une technique qui peut être obtenue par différents vecteurs.Un courant commun est via une inondation distribuée.Mais toute technique qui produit un service qui ne répond pas est correctement classée comme une attaque par déni de service.Cela peut inclure l'injection SQL.Ma réponse explique comment cela peut être fait avec zéro caractère.Il fournit également un lien vers la feuille de triche de prévention des injections SQL OWASP.Merci d'avoir souligné que je devrais les souligner.
MikeSchem
2017-03-02 02:14:18 UTC
view on stackexchange narkive permalink

No.

Exemple simple d'injection SQL à un caractère:

  ` 

Cela générerait une erreur qui serait un exemple de «retour de résultats non prévus par la conception». Plusieurs fois, les erreurs peuvent être utilisées pour obtenir des informations qui aideront plus tard dans un exploit.

Peut-être pourriez-vous ajouter une explication sur la façon dont cette injection pourrait être nocive?
Ce serait une erreur qui serait un exemple de "retour de résultats non prévus par la conception" Plusieurs fois, des erreurs peuvent être utilisées pour obtenir des informations qui aideront plus tard dans un exploit.
Merci!J'ai pris la liberté d'inclure votre explication dans la réponse.
Dan
2017-03-03 00:27:35 UTC
view on stackexchange narkive permalink

Oui.

La longueur maximale est de zéro. La seule façon de sécuriser les entrées non fiables via une longueur maximale, sans aucune autre validation ou vérification, est de ne pas tenir compte complètement de l'entrée commençant à l'index 0.

Il y a beaucoup d'autres (meilleures) réponses ici, mais celle-ci sert à répondre à la question théorique de savoir comment rester en sécurité lorsque la longueur du champ est le seul outil à votre disposition.

Je ne suis honnêtement pas convaincu qu'un attaquant assez intelligent ne puisse pas gérer une attaque avec zéro personnage.
À l'instar d'autres commentaires ci-dessus - où tout résultat non prévu par la conception est une forme d'injection SQL;serait-il également valable de dire que tout comportement non prévu par la conception est une forme d'injection SQL (faisant référence à l'exemple de sleep (60) ci-dessus .. qui était plutôt cool :)? Une injection SQL de longueur 0 alors, ne devrait pas nécessairement impliquer de SQL .... tant que vous pouvez attacher la connexion ??
@Dan jeez bien si je savais que j'irais de l'avant et ferais une contre-mesure.C'est le problème de la sécurité en général ... Nous pensons que c'est sécurisé jusqu'à ce qu'un attaquant prouve que ce n'est pas le cas.
Spencer Williams
2017-03-03 05:47:59 UTC
view on stackexchange narkive permalink

La longueur d'un champ n'aura rien à voir avec l'injection SQL, car une telle attaque fonctionne en commentant simplement le code précédent et en démarrant le code d'attaque, donc la longueur de tout champ n'affectera pas cette stratégie.

Je pense que le point d'OP est que l'application ne permettra pas à une quantité arbitraire de texte d'atteindre la base de données - elle tronque toujours à une longueur particulière.
Almenon
2018-08-02 20:38:10 UTC
view on stackexchange narkive permalink

Il y a beaucoup de théorie ici mais pas d'exemples concrets. Lorsque j'ai trouvé une vulnérabilité d'injection SQL dans le monde réel (maintenant corrigée), j'ai essayé d'utiliser des champs de saisie d'environ 30 caractères. C'était très frustrant car il m'a fallu un certain temps pour comprendre que tout après 30 personnages avait été abandonné, et 30 personnages ne me laissaient pas beaucoup de place.

(beaucoup d'exemples d'injection SQL ont un sql simple "comme select * from table où id = @id", le SQL réel sera généralement beaucoup plus compliqué)

Vous pouvez obtenir fantaisie avec votre entrée, et un expert sql pourrait probablement utiliser quelques astuces pour réduire le nombre de charges utiles. Mais peu importe à quel point vous êtes difficile si vous souhaitez sélectionner un nom de table long, vous aurez besoin de beaucoup de caractères pour cela.

Quoi qu'il en soit, lorsque je suis passé à l'utilisation d'un champ de saisie avec plus de 1000 caractères J'en ai trouvé beaucoup pour l'injection SQL.

Cela étant dit, comme l'ont dit de nombreux commentateurs au-dessus de moi, La meilleure défense contre l'injection SQL est les instructions préparées



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