Piratage par salves d'injections SQL

Bonjour,

J'ai, posé la question chez developpez.com, mais elle reste sans réponse

J'ai un site d'importance moyenne chez OVH.

Un jour, très mauvais temps de réponse, impossible d'exécuter des traitements d'administation sur la base, genre mise à jour des stocks.

J'appelle OVH et il apparaît que le trafic est 10 fois plus important que d'habitude.

Il est clair qu'un pirage multiplie les logs.

OVH me dit que c'est mon problème et qu'ils ne peuvent pas m'aider.

Je ne connais rien aux techniques serveur, je ne vois pas comment me défendre.

Interdire une IP dans le htaccess ne sert à rien car il semble que le pirate utilise plusieurs IP.

Je pense néanmoins qu'il existe des parades assez standards.

Le pirate s'est calmé, le site fonctionne à nouveau normalement, mais j'aimerais me protéger contre ces attaques.

Merci d'avance.
Modifié par boteha_2 (30 Nov 2015 - 21:43)

Difficile.

Ce sont pour la plupart des attaques automatisées de robots qui cherchent des failles ou des comptes WordPress avec mot de passe bidon. Cela survient par vagues, certains jours, puis s'arrête une fois que le robot renonce.

L'idéal ce serait d'avoir un firewall qui filtre tout ça avant que cela n'arrive jusqu'au serveur http (Apache, PHP, MySQL et donc WordPress qui lance des requêtes pour rien).

Sur un mutualisé on ne peut pas faire grand chose. OVH n'y prête guère d'attention et c'est bien dommage.

Sur un hébergement dédié il y a des solutions mais cela nécessite de bien connaître l'administration système. Par exemple utiliser une combinaison de fail2ban et l'extension WP fail2ban, ou encore mieux une vraie détection en amont de la machine.

a écrit :
Ce robot ,connaît les noms de champs de ma base client, le nom de cette base, je ne vois pas comment il a pu faire.

Plusieurs pistes :
1 - Tu utilises un CMS et/ou plugin de CMS connu et le bot a découvert ce que tu utilisais
2 - LE bot a provoqué une erreur SQL et le message d'erreur donne des noms de table et de champs souvent très explicites

Pour te protéger du point 1, garde tes outils à jour, et si tu peux, évite de donner des informations gratuites genre mentions "powered by XYZ v1.2.3". Mais même sans ce genre d'info, quand tu utilises un système connu, c'est très facile de le savoir. La règle absolue à laquelle il ne faut pas transiger quand on ne développe pas soi-même c'est de toujours rester à jour.

Pour te protéger du point 2, n'affiche jamais les messages d'erreur en clair. Envoie-les dans un log, par mail, ignore-les carrément ou ce que tu veux, mais fais en sorte qu'ils ne s'affichent en aucune circonstance dans le navigateur; même si le pirate a déclenché la bombe atomique; au pire une page blanche sera mieux que de livrer n'importe quelle petite parcelle d'information.

a écrit :
Cependant, je ne vois pas comment un SELECT exécuté depuis une URL peut aboutir...

Renseigne-toi sur les injections SQL, par exemple avec cet article d'introduction http://zestedesavoir.com/articles/193/les-injections-sql/

Sur le web, l'injection SQL est dans le top 3 des plus grosses failles si ce n'est pas même la n°1, c'est-à-dire que c'est une des plus fréquentes, une des plus simples à élaborer, une des plus destructrices, mais aussi heureusement une des plus faciles à parer.

Dans le cas qui nous occupe ici, le contenu résultat n'étant pas loggé par apache, le seul moyen de savoir ce que le pirate a pu récupérer est d'essayer toi-même.
Modifié par QuentinC (16 Nov 2015 - 23:07)

La majorité des hébergeurs considèrent que chacun doit se débrouiller. Cela représente des moyens importants (donc coûteux) de filtrer le trafic efficacement. OVH étant grand public et low cost je pense qu'ils partent du principe que ce n'est pas leur rôle de parer les injections SQL.

Bonjour,

Merrci de vos réponses, je vais étudier cela ce soir.

Je n'utilise pas de CMS.

Je ne connais presque rien à Appache.

Par contre avec PHP je peux bloquer toutes requêtes fournies par un GET comprenant les mots SELECT ou DELETE.

+1, ce n'est pas à l'hébergeur de se soucier des failles genre injection SQL. C'est tes données, c'est ton problème si elles sont exposées.

OVH se doit par contre de sécuriser les attaques de niveau réseau. C'est pour cela qu'ils disposent par exemple d'un important dispositif anti-DOS.

a écrit :
Par contre avec PHP je peux bloquer toutes requêtes fournies par un GET comprenant les mots SELECT ou DELETE.

Malheureusement, ce n'est pas si simple. IL existe de nombreux moyens pour attaquer la base de données sans écrire SELECT, INSERT, DELETE ou DROP en clair; de même qu'il existe plusieurs moyens de faire de l'injection sans utiliser ' ou ".
La solution est d'utiliser les fonctions de protection qui ont été prévues spécifiquement contre ça: requêtes préparées, PDO::quote, mysql_real_escape_string...

Bonjour,

Encore merci pour vos réponses.

1)

Zelalsan a écrit :
Alors ça m'a un peu intrigué tout ça et en cherchant j'ai trouvé ce lien concernant la sécurité d'OVH.

Très intéressant, j'appelle demain OVH pour savoir si c'est disponible en Mutu.

2)

QuentinC a écrit :

La solution est d'utiliser les fonctions de protection qui ont été prévues spécifiquement contre ça: requêtes préparées, PDO::quote, mysql_real_escape_string...

Je découvre... Je vais me documenter.
Le seule "sécurité" sur mon site est de ne pas exécuter les requêtes dont la clause WHERE est vide ou absurbe.

Ce qui m'effraie c'est que cette saleté de robot connaît mes noms de tables et de champs.
Par contre il n'a pas touché aux table ni aux scripts qui semblent intacts.
Au niveau du FTP tout semble normal.

a écrit :
Par contre il n'a pas touché aux table ni aux scripts qui semblent intacts.

On est à l'ère du big data maintenant. La plupart du temps, en présence de ce genre de faille, c'est beaucoup plus intéressant de se servir que de venir tout casser. C'est beaucoup plus incidieux et moins facilement repéré.

a écrit :
Pas de guillemet pas de danger, c'est ce que j'ai retenu.

Malheureusement, ce n'est pas aussi simple. IL y a moyen de faire des dégâts sans utiliser d'apostrophes ni de guillemets.

Lorsque tu fais entrée une variable de type chaine de caractère, il faut utiliser mysqli_real_escape_string qui doit "protéger" ta chaine de caractère.

La où il signale que ce n'est pas suffisant c'est lorsque tu fais entrée une variable d'un autre type (entier par exemple), il faut que tu vérifies que la variable contient bien un élément du type attendu : si tu attends un entier et que finalement cela contient une chaine de caractère, il y a un risque, la requête ne doit pas être exécuter. Pour cela tu peux utiliser des fonctions php (is_int() pour l'exemple)

C'est assez clairement expliqué dans le lien fourni plus haut : http://zestedesavoir.com/articles/193/les-injections-sql/

Bonjour,

Merci de ta réponse.

mysqli_real_escape_string()

Les caractères encodés sont NUL (ASCII 0), \n, \r, \, ', ", and Control-Z.

Pour une injection SQL, il me semble que les seuls caractères dangereux sont ', ".

Et d'accord pour vérifier les entiers avec is_int ().
Modifié par boteha_2 (30 Nov 2015 - 21:57)

Non il n'y a pas que ' et " de dangereux. \ permet par exemple d'échapper un ' ou " qui suit, donc si \ n'est pas échappé, le fait d'échapper ' et " ne protège absolument rien du tout. Le caractère Ctrl+Z également appelé \e ou \27, \1F ou Escape permet aussi parfois (plus rarement) de faires des échappements. Le caractère nul \0 est plus méconnu et permet quant à lui de stopper prématurément une chaîne lorsque des API en C sont utilisées. Pour rappel PHP est compilé en C et l'écrasante majorité de ses bibliothèques aussi, donc c'est un piège classique qui n'est pas seulement valable dans les bases de données.

Juste pour info, la fonction PDO::quote est encore mieux que mysql_real_escape_string, parce qu'en plus d'échapper correctement la chaîne, elle l'entoure automatiquement d'apostrophes. Du coup on peut l'utiliser indifféremment pour quasiment tout, chaînes, nombres, dates ou autres.

Attention aussi à échapper % et _ en plus si on utilise LIKE, ou les métacaractères dans le cas des regex; on l'oublie facilement et ceux-là ne sont pas couverts par les fonctions habituelles.