comment désactiver la fonction de référence mysql, donc ne pas faire l'objet d'attaques par injection SQL aveugle comme "select if (user() like 'root @%', benchmark (100000, sha1 ('test')), 'faux');"MYSQL désactiver SELECT BENCHMARK
select * from func n'affiche pas de benchmark de fonction.
Cordialement Charles
Le conseil des meilleures pratiques est de escape data before passing to the query ou de créer des déclarations préparées. Malheureusement, non seulement la fonction de benchmark est dangereuse, donc vous devrez en désactiver d'autres ...
Salut les gens, je sais qu'il peut y avoir d'autres façons, mais je veux explicitement savoir comment désactiver le benchmark. Merci, Charles – Charles
@Charles: Mais pourquoi? Si vous utilisez correctement les requêtes paramétrées, ajouter cette protection supplémentaire est comme mettre une clôture autour de votre bunker en béton (juste au cas où il y aurait des gens qui n'ont aucun problème à traverser un bunker en béton mais qui ont peur des clôtures) –
@Matti parce que je dois faire un atelier où les requêtes paramétrées pourraient être la réponse :) Et aussi je me soucie de cela. Bien sûr, l'option de sauvegarde est toujours de regarder la source, mais j'espérais une option DISABLE BENCHMARK simple. – Charles
J'ai trouvé cette réponse!
....
echo preg_match("/^([\'\)\"a-zA-Z0-9])+([0-255[:ascii:]])+select+([0-255[:ascii:]])+([\-])+([0-255[:ascii:]])+$/","8' union select 1 from --");
echo preg_match("/^([\'\)\"\(a-zA-Z0-9])+([0-255[:ascii:]])+benchmark+([0-255[:ascii:]])+([\-])+([0-255[:ascii:]])+$/","select if(user() like '[email protected]%', benchmark(100000,sha1('test')), 'false')--");
....
@Charles Je suis d'accord que l'élimination de la fonction BENCHMARK sans avoir d'abord à traiter les causes profondes (validation d'entrée, etc.) met le cheval avant la charrette. Mais je ne suis pas d'accord que c'est une clôture ou inutile entièrement. En supposant que (a) il est relativement facile de désactiver, et (b) de le désactiver ne crée pas de nouvelles vulnérabilités, pourquoi ne pas le faire? Pour moi, ce n'est pas une seconde mesure de défense, mais une première étape dans la sécurisation du système: la désactivation de tous les services & fonctions non utilisées. Sinon, vous ne faites qu'armer la boîte à outils d'un attaquant avec un autre outil potentiel - sans parler d'un outil bien documenté et intégré dans chaque BlackBox à bouton-poussoir!
Je pense que le plus gros problème que j'ai avec votre argument ne vient pas du débat sur l'activation ou la désactivation de BENCHMARK, mais votre hypothèse selon laquelle les requêtes paramétriques sont infaillibles. Mettre trop de foi dans un système et avoir un faux sentiment de sécurité est beaucoup plus dangereux que de ne pas désactiver une fonctionnalité comme BENCHMARK. Qui peut dire que Oracle/Microsoft/etc ne présentez pas de bogue dans les prochaines versions? Qui peut dire qu'il n'y a pas de bug en ce moment en attente d'être découvert? Et qui peut dire que vous pouvez faire confiance à chaque personne travaillant sur le code?
Je préfère ne pas permettre aux gens d'exécuter des SQL sur mon serveur que de désactiver certains bits en espérant que les gens ne trouvent pas les moyens de contourner ces problèmes. Vous avez déjà entendu parler de requêtes paramétrées? –
Si votre application échappe correctement les données, vous n'avez pas à vous en préoccuper. Si vous trouvez un moyen de désactiver 'benchmark', il y aura assez d'autres façons de savoir si une requête réussit ou échoue. – Lekensteyn
Alors que d'autres ont jugé votre question non pertinente ou inutile, je la trouve utile. Il semble que benchmark peut être utilisé pour recueillir des informations sur le serveur, ce qui aiderait un attaquant à l'abattre (http://pastebin.com/88Lzs1XR) – Purefan