Injection SQL via MySQL_Query

Je suis à peu près sûr qu'un pirate informatique serait en mesure de modifier facilement la requête. Même si mysql_query () ne prend pas en charge plusieurs requêtes, il existe des moyens. Vous pouvez simplement utiliser une instruction MySQL si une instruction ajoutée à la fin et bien sûr, qui exécutera une toute nouvelle requête.

Selon la version de MySQL que vous utilisez, et la configuration de la connexion, MySQL_Query peut autoriser plus d'une déclaration .

Vous devriez examiner comment la connexion est créée et pour toute utilisation de mysql_set_server_option .

intéressant que votre question n'a pas encore reçu de réponses (correctes)!

Comme vous l'avez découvert, des API PHP habituelles MySQL comme mysql_query , mysqli :: requête etc. n'exécute que la première instruction SQL au cas où l'on leur passe plusieurs (séparés par des points-virgules), comme un attaquant utilisant La classe la plus courante d'injections SQL .


Conseil de défenseur: bannir mysqli :: multi_query et amis de votre code; Les améliorations des performances des minutes ne valent pas le risque.

Est-ce que ce mouvement intelligent de PHP-Folk ferme complètement tous les canaux d'attaque sur un code qui va comme "Sélectionnez Yadda Yadda". $ _GET ["non approuvé"] ? Pas assez. Comme Remarques Knittl , même une pure- DQL Sélectionnez peut être utilisé pour escalader ses privilèges par Union Tout sélectionnez 'Ing de n'importe quelle table intéressante à proximité, y compris mais non limité à la table des mots de passe. Il y a tricher les feuilles de triche offrant suffisamment de conseils et d'astuces extraire essentiellement la base de données entière de cette façon.


de défenseur Conseil: Appliquer la défense- en profondeur avec des techniques connues:

• Validation d'entrée
• Indirection Whitelist dans un tableau associatif
• Les déclarations préparées ( si vous pouvez vous assurer qu'elles sont efficaces et non seulement à la chaîne s'échapper dans le déguisement !)
• un ORM
• codage de protection (par exemple base64) lorsque l'entrée non approuvée ne peut pas être désinfectée de manière satisfaisante (par exemple, un poste de blog pouvant légitimement contenir de la ponctuation sensible au SQL)
• ou en dernier recours uniquement , chaîne s'échappant

  Ensuite, on peut observer que tous les DQL ne sont pas libres de côté, en particulier lorsqu'il se termine par dans SUPPFILE quelque chose .


  Conseil de défenseur: toujours configurer secury_file_priv dans votre serveur MySQL / MARIADB.

  Dernier point mais non le moindre, même un attaquant qui est en mesure d'injecter SQL arbitraire est limité par l'autorité accordée à l'application Web dans son ensemble.

  Defender Conseil: Sécurisez votre application en appliquant Pola .

  • Seulement Grant L'utilisateur MySQL de l'application Web autant d'autorité qu'il en a besoin. Ce n'est pas une mauvaise idée de concevoir votre application afin qu'elle ne nécessite aucun DDL du tout. Si vous devez fournir une fonctionnalité "sauvegarde / restaurer dB" ou une partie de l'interface utilisateur Web, utilisez un séparé MySQL utilisateur pour cela.
  • automatisez des sauvegardes, même s'ils sont inutiles - restaure est ce qui compte < / a>.