Ne passez pas beaucoup de temps sur des solutions de contournement ou des demi-correctifs. Chaque minute que vous passez à essayer de mettre en œuvre tout ce qui est suggéré ici est une minute que vous auriez pu passer à mettre en œuvre des déclarations préparées. C'est la seule vraie solution.

Si vous avez une vulnérabilité SQLi, l'attaquant finira probablement par gagner quoi que vous fassiez pour essayer de la ralentir. Sachez donc que même si vous pouvez apporter des améliorations, vous jouez à un jeu perdant à moins que vous ne résolviez la cause du problème.

Quant à ce que vous avez essayé jusqu'à présent: masquer les messages bon départ. Je vous recommande d'appliquer des autorisations encore plus strictes (voir ci-dessous). Il est discutable de savoir si changer les noms de table aide, mais cela ne fera probablement pas de mal.

Ok, alors qu'en est-il de ces autorisations? Limitez autant que possible ce que l'utilisateur de la base de données peut faire, jusqu'au niveau de la table ou même de la colonne. Vous pouvez même créer plusieurs utilisateurs de base de données pour verrouiller encore plus les choses. Par exemple, utilisez uniquement un utilisateur de base de données autorisé à écrire lorsque vous écrivez réellement. Connectez-vous uniquement avec un utilisateur qui a le droit de lire la colonne de mot de passe lorsque vous avez réellement besoin de lire la colonne de mot de passe. De cette façon, si vous avez une vulnérabilité d'injection dans une autre requête, elle ne peut pas être exploitée pour fuir les mots de passe.

Une autre option consiste à utiliser un pare-feu d'application Web (WAF), tel que mod_security pour Apache. Vous pouvez le configurer pour bloquer les demandes qui semblent suspectes. Cependant, aucun WAF n'est parfait. Et il faut du temps et de l'énergie pour le configurer. Vous feriez probablement mieux d'utiliser ce temps pour implémenter des déclarations préparées.

Encore une fois, ne laissez rien de tout cela vous attirer dans un faux sentiment de sécurité. Il n'y a pas de substitution pour corriger la cause première du problème.

La seule manière correcte est d'utiliser des instructions préparées.

1. Si vous masquez les messages d'erreur, c'est un peu plus difficile, mais cela n'arrêtera pas les attaquants.
2. Vous pouvez restreindre les droits, mais tous les droits accordés à l'utilisateur pourraient être acquis par l'attaquant. Il est également possible d'exécuter des commandes shell à partir d'une injection SQL dans certains cas.
3. Renommer les tables ne vous aidera pas. L'outil sqlmap forcera brutalement les noms de table pour vous char par char. Cela n'a pas besoin de beaucoup de temps.

Vous pouvez également limiter le nombre d'appels, pour rendre la tâche plus difficile pour les attaquants ou faire des alertes sur les appels suspects et arrêter ce manuel, mais la seule façon correcte de résoudre ce problème est d'utiliser des instructions préparées. Il suffit de parcourir votre code source et de jeter un œil aux instructions SQL avec un contenu dynamique et de les remplacer.

Nous le savons, mais nous n'avons pas assez de développeurs / testeurs pour le rendre 100% sûr.

C'est le vrai problème . Jusqu'à ce que vous embauchiez plus de personnes ou que vous ne réaffectiez pas vos priorités, vous n'êtes pas en sécurité. Arrêter 99,9% des attaquants signifie que vos données ont été compromises. Les solutions de pansement sont une mauvaise chose, et elles ne fonctionnent pas . Ne perdez pas de temps à refactoriser votre modèle d'accès SQL pendant que vous pourriez résoudre des problèmes réels.

En ce qui concerne la solution de code, l'utilisation d'instructions préparées, comme beaucoup de gens ici le suggèrent, est le moyen le plus simple d'utiliser SQL en toute sécurité.

C'est beaucoup plus facile que d'essayer d'utiliser php pour nettoyer les arguments vous-même, et cela coûte beaucoup moins de temps. Il suffit de grep toute votre base de code pour tout ce qui concerne SQL et de le corriger.

Purgez définitivement tout SQL de votre code

La meilleure solution à ce problème est de supprimer tout le code SQL en tant que chaînes littérales de votre code et de ne plus jamais le réintroduire. À la place, utilisez un logiciel ORM comme Hibernate ou Entity Framework. De toute façon, ce logiciel est beaucoup plus agréable à utiliser que le SQL brut, et paramètre automatiquement votre SQL lorsqu'il va finalement dans la base de données. Si c'est possible pour vous, ayez cette politique.

Si vous n'avez pas le temps d'apprendre et de mettre en œuvre ces packages, ou si vous ne pouvez pas les utiliser pour une autre raison, la réponse de trietend est la meilleure chose à faire, en utilisant des déclarations préparées. Cela vous permettra d'être à l'abri de l'injection SQL. Autrement dit, jusqu'à ce que vous mettiez la pression sur vos développeurs pour qu'ils fournissent des solutions rapides, auquel moment ils peuvent à nouveau oublier de paramétrer une seule variable, vous laissant là où vous avez commencé.

Nous savons, mais nous n'avons pas assez de développeurs / testeurs pour le rendre 100% sûr.

Ce que vous entendez par cette déclaration n'est pas tout à fait clair, tel que préparé Les instructions sont triviales dans tous les langages Web populaires (PHP, Python, Java, node.js, etc.) et sont plus ou moins une mesure efficace à 100% contre l'injection SQL.

Voulez-vous dire que vous sous-traitez développement et ne peut pas se permettre de QA le code qu'ils écrivent pour vous sur contrat? Vous ne pouvez pas vous permettre de ne pas le faire: vous êtes toujours la partie responsable ici.

Voulez-vous dire que vos développeurs sont trop occupés à mettre en œuvre des fonctionnalités pour prendre quelques heures pour mettre à jour la base de code? Tout autre que les instructions préparées prendra plus de temps et coûtera plus cher (par exemple ORM, obsfucation, autorisations précises, etc.).

Voulez-vous dire que vos développeurs ne sont pas assez compétents pour effectuer cette tâche simple? C'est un plus gros problème (ou pour être plus précis, l'injection SQL ne devrait pas être votre plus grande préoccupation à ce stade).

Voulez-vous dire que votre base de code est un tel désordre de logique spaghetti au format fusil de include s que même les développeurs compétents mettront une éternité à effectuer ce qui serait autrement une simple tâche de quelques heures? De même, un problème plus grave.

Quelle que soit celle-ci, la solution est d'utiliser des déclarations préparées, vers hier.

Une fois que le conseil initial "instruction préparée" a été implémenté, je recommanderais quelques lectures sur l'injection SQL. Se demander "comment éviter l'injection SQL" est une question assez large! La sécurité est un sujet avec lequel vous (plutôt que toute votre équipe de développement) devez être très familier afin de réduire le risque de compromis. Un trou sape tous vos autres efforts.

Visitez le projet Open Web Application Security (OWASP) ici: https://www.owasp.org/index.php/SQL_Injection

En particulier le matériel supplémentaire:

• Aide-mémoire sur la prévention des injections SQL
• Aide-mémoire sur le paramétrage des requêtes
• Article de guide sur la façon d'éviter les vulnérabilités d'injection SQL

Et aussi

• Comment vérifier le code pour les vulnérabilités d'injection SQL .

Une mesure provisoire serait de se pencher sur un pare-feu d'application Web (WAF) - il existe quelques entreprises qui fournissent cela en tant que service et quelques fournisseurs de cloud qui proposent également des offres. CloudFlare semble en offrir un, j'ai eu un client qui utilise Incapsula, et je sais que l'offre AWS WAF a des ensembles de règles gérés pour l'injection SQL.

La façon dont cela fonctionne est que tout le trafic est envoyé vers / via le WAF (soit en l'incluant sur les serveurs, soit en définissant DNS pour qu'il pointe vers le WAF comme vous le feriez pour un CDN), et il recherche des choses qui ressemblent à des tentatives d'injection SQL dans les paramètres. Il ne détecte pas toutes les attaques et peut bloquer le trafic légitime, mais il s'agit d'un correctif de pansement disponible.

Par "je n'ai pas assez de développeurs", je suppose que vous voulez dire que certaines personnes influentes de votre organisation pensent qu'il y a des priorités plus élevées, donc quelles que soient les ressources dont vous disposez sont consacrées à ces choses. Donc, résoudre votre problème de sécurité, c'est perdre d'autres choses dans une analyse coûts-avantages.

Votre tâche ici est de changer d'avis, autant que d'implémenter le correctif. Quantifier ce qui est en jeu - quels seraient les dommages, en termes d'argent et de réputation, d'une autre violation? Il se peut que certaines lois de votre juridiction vous obligent à signaler les compromissions des données de vos utilisateurs. Cela serait-il embarrassant? Peut-il y avoir des reportages médiatiques sur les mauvaises pratiques de votre organisation?

Pensez à l'investissement pour fixer la sécurité comme une assurance. Rétrospectivement, une fois que vous savez que votre bâtiment n'a pas brûlé pendant une période de dix ans, vous pourriez soutenir que vos primes étaient un gaspillage. Mais vous et votre organisation payez une assurance, car votre avenir est incertain. C'est la gestion du risque.

Le risque a deux facteurs: la probabilité et l'impact. La probabilité d'une autre violation est élevée - vous savez que cela peut et a été fait au moins une fois. Si les conséquences potentielles sont également mauvaises, vous devez augmenter la priorité de la correction de vos failles de sécurité.

Comme tout le monde l'a mentionné, corrigez le code sur le site.

Vous pouvez apporter les correctifs de votre choix à un mur, mais tant que le mur ne sera pas construit correctement, tous les correctifs seront un problème de saignement.

Toute autre suggestion pour nettoyer le code est ce que Linus Torvalds appellerait masterbation.

• Corrigez votre code (à partir des points d'injection les plus évidents au dernier IE Get params) et utilisez des instructions préparées. comment puis-je empêcher l'injection SQL dans PHP

  • Vous pouvez essayer un WAF (IE ModSecurity ) temporairement jusqu'à ce que vous soyez en mesure de réparer les choses.

  • Essayez Peut-être une sorte d'interdiction de la propriété intellectuelle sur les «personnes testant le site» ou le blocage des requêtes non sécurisées.

  • Si vous avez la possibilité de créer un écran de connexion temporaire (sécurisé) devant jusqu'à ce que cela soit résolu.

  • Essayez un service tiers jusqu'à ce que cela soit résolu, quelque chose comme cloudflare ou tout autre élément

Les PDO sont disponibles depuis la sortie de PHP 5.1 le 24 novembre 2005 ... Les développeurs doivent comprendre que ce sont des conséquences pour leurs mauvaises habitudes de codage et je pense personnellement qu'il devrait y avoir une responsabilité quant à la qualité du travail fourni.

En tout cas, les PDO sont une chose facile à mettre en œuvre. Si vos développeurs ne sont pas en mesure de fournir une meilleure qualité, alors je suggérerais une purge ...

La règle la plus importante est:

Utilisez des bibliothèques, des outils et des API qui font de l'option sûre l'option la plus simple.

Nacht dit "il suffit d'utiliser un ORM "qui est un sous-ensemble de cette règle.

Les instructions préparées enfreignent cette règle, car elles sont lourdes à utiliser, entraînent un gonflement du code, elles peuvent également être souvent plus lentes que les instructions non préparées en fonction de votre base de données. C'est une solution valable, je ne critiquerai personne qui les utilise, mais ce n'est pas nécessairement la solution la meilleure et la plus pratique.

Et .. nous voulons que l'option sûre soit simple et pratique, donc le programmeur l'utilise par intérêt personnel et par paresse. Nous voulons que le programmeur doive réellement faire tout son possible et investir quelques efforts pour utiliser l'option unsafe! ...

Une bien meilleure solution est une API comme Python dbapi. J'ai écrit un équivalent php il y a des années, qui était comme:

  db_query ("SELECT * FROM mytable WHERE id =% s", $ id)  

C'est plus pratique que les déclarations préparées. Juste une ligne à taper. Il renvoie également le résultat sous une forme que foreach () peut utiliser, donc il est beaucoup plus facile à utiliser que fetch () et tout. Plus important encore, le code caché derrière cette API gérera correctement l'échappement. Cela rend les injections SQL inutiles. Cela gère environ 99% des requêtes si vous n'utilisez pas d'ORM. Les requêtes dynamiques (généralement la recherche) nécessiteront cependant un traitement spécial, mais c'est toujours facile.

Si vous gardez cette règle à l'esprit, alors à un moment donné, vous devrez vous demander pourquoi vous devez utiliser htmlspecialchars (), et pourquoi le langage n'a pas de fonctionnalité qui rendrait le paramètre sûr (c'est-à-dire pas de vulns XSS) le plus facile à utiliser? Pourquoi oh pourquoi? Et c'est là que vous abandonnez PHP.

En plus de toutes les excellentes réponses à ce jour, si vous souhaitez résoudre le problème spécifique de l'extraction des informations d'identification des utilisateurs, vous pouvez refactoriser votre base de données pour avoir les mots de passe dans une table séparée avec des droits d'accès stricts , similaire à la façon dont les systèmes Unix les placent dans /etc/shadow.

Pour vérifier les informations d'identification, vous avez besoin d'une procédure stockée qui prend le mot de passe saisi (ou hachage) comme paramètre et renvoie un booléen. En d'autres termes, vous déchargez la tâche de vérification des informations d'identification dans la base de données et le hachage réel ne quitte jamais la base de données.

Cela nécessite une refactorisation minimale et résout votre problème immédiat à la racine, au lieu d'une injection SQL spécifique pendant vous laissant vulnérable au prochain.