[Rizz]

Merci pour ce fou rire quand j'ai vu l'url avec "l'injection" ..
Le dev c'est un métier, la vente de câble en est un autre...

[boteha]

Bonjour,

Je veux bien faire des requêtes préparées.

Cela n'a pas l'air trop compliqué à mettre en place.

Je n'ai pas compris s'il faut charger une classe dans son FTP mais je devrais trouver.

[janus57]

Bonjour,

le manuel PHP n'est pas d'accord avec vous : http://php.net/manual/fr/pdo.prepared-statements.php

Cordialement, janus57

[boteha]

Bonjour chmod777,

Merci de tes précisions.

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

Pour les variables numériques, je peux les tester avec is_numéric ou is_int () si entier.

Ce que je veux dire : les requêtes préparées ou mysqli_real_escape_string interviennent en fin de script, au niveau de la requête.

Il paraît plus logique et économique d'analyser le $_GET que tu reçois en débur de script et de stopper l'attaque à ce niveau.

[chmod777]

Bonjour.

Doc MySQL pour mysql(i)_real_escape_string :

Characters encoded are “\”, “'”, “"”, NUL (ASCII 0), “\n”, “\r”, and Control+Z.

La question ne se pose pas pour les requêtes préparées vu que la requête en elle-même et les données envoyées sont traitées séparément. Aujourd'hui on te conseillera cette option là, même si elle va demander plus de modifications sur les scripts existants. Après, il faut bien être honnête aussi, je n'ai jamais vu de problème sur les sites qui utilisent mysqli_real_escape_string :
- quand la fonction mysqli_set_charset('utf8, latin1, etc'); est utilisée en amont.
- et, comme le nom de la fonction l'indique, que mysqli_real_escape_string est utilisé uniquement pour les chaînes de caractères (comprendre que 'SELECT * FROM table WHERE id='.mysqli_real_escape_string($id).'' où tu attends un entier est faillible, utiliser intval à la place).

[boteha]

Bonjour,

La question que je pose est de savoir si les requêtes préparées ou mysqli_real_escape_string font plus que traiter les apostrophes et guillemets ?

Si non, je trouve préférable d'agir en amont, : de commencer le script par une fonction de test de $_GET.

Dans mon site je pense que les formulaires sont correctement sécurisés (test des variables, htmlentities) donc que l'attaque peut venir des failles des requêtes de navigation.

Je sais qu'il ne peux avoir ni apostrophes, ni guillemets, ni nom de tables dans ces reqêtes.

J'ai donc envie de juste tester ces trois items.

Si problème, Exit () direct après m'être envoyé un mail avec l'URL demandée et l'adresse IP de l'émetteur.

Que pourrais-je tester de plus ?

[boteha]

Bonjour,

1) J'ai activé le firewall d'OVH.
A première vue le site reste aussi rapide.

2) Je pense utiliser mysqli_real_escape_string plutôt que les requêtes préparées.
Il me semble que cela revient au même.

[Jikoo]

Autrement :
Je suis en POST pour les BD et en GET pour la navigation, comme tout le monde.
J'ai un certificat SSL.

Oui ça c'est bien.

Et pour les accès à la base de données, utilisez les requêtes préparées PDO ! ^^
http://php.net/manual/fr/pdo.prepared-statements.php
Avec ça, fini les injections SQL !

[boteha]

Bonjour,

Mod Security OVH

Puisque le team OVH participe à la discussion n'est-ce pas une priorité ?

Comment puis-je voir si c'est activé ou non sur mon site ?

Autrement :
Je suis en POST pour les BD et en GET pour la navigation, comme tout le monde.
J'ai un certificat SSL.

[undernews_fr]

Bonjour Boteha,

Ton log est très clair : il s'agit d'une attaque de type injection SQL, s'attaquant directement à ta base de données.
Visiblement, comme dit plus haut, l'attaquant à déjà trouvé le nom de la base ainsi que des tables/champs de colonnes.

Ce n'est donc pas une fausse alerte ou un simple scan ! C'est une intrusion (en cours ou déjà réussie).

Si tu as des données sensibles en BDD, met ton site hors ligne vite en attendant d'identifier la faille et de la corriger.

Le script /b.php existe t-il vraiment sur ton serveur ? Si oui, il est faillible, supprime le au plus vite.

Ensuite, change tous les accès et nettoie bien le serveur au cas ou...

Bon courage.

[boteha]

Bonjour,

Merci de vos réponses.

Je vais étudier cela ce soir.

J'ai un certificat SSL mais le site est accessible en http ausi bien qu'en https.

[Ludo.H]

Bonjour,

Après vérification, votre site à quelques lacunes en sécurité.
Par exemple, accès à un fichier de comptabilité via une url directe (il vaudrait mieux le placé dans un répertoire autre que "www" à la racine).

L'attaquant, IP venant de Hong-Kong, envoie des requêtes SQL dans l'URL.
URL que vous parser et dont vous executez des sous ensembles.
Je n'ai pas tout regarder en détail mais du code comme ceci :

$corps = Corps_Fiche ($corps, $_GET['h']);

Va executer le code présent dans la variable "h" de l'URL, ici l'injection SQL.

Quelques conseils, surtout pour un site commercial :

- Utiliser du POST et non du GET, cela va masquer en partie les arguments de vos requêtes et rendre plus difficile l'analyse par l'attaquant de ce qu'il doit envoyer.
- Utiliser du SSL, ce n'ai pas un argument commercial que j'avance, mais personnellement je n'acheterais rien sur un site qui n'a pas un certificat SSL valide.
- Attention à l'execution de code venant d'une URL.

[janus57]

Bonjour,

A quoi correspond le code 200 ?

que la requête est un succès.

Donc visiblement votre site à bien été "troué" et une personne a réussit à exploiter une faille si les champs était correcte.

Je ne sais pas si vous aviez prévu ce genre d'injection SQL mais visiblement le robot à fait mouche.

Et là j'espère que les MDP était sous forme de hash (autre que MD5 et SHA1) et avec un peu se "sel", sinon vos clients vont très vite avoir des surprise si le robot à réussit à exploiter une faille concrète de votre site.

Cordialement, janus57

[boteha]

Bonjour,

Merci de vos réponses.

Je suis très inquiet car les noms des champs SQL (que j'ai modifiés dans ce Post) sont exacts.

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.

Cependant, je ne vois pas comment un SELECT exécuté depuis une URL peut aboutir...
A quoi correspond le code 200 ?

Le robot a cherché à me piquer les mails et mots de passe de mes clients.

[janus57]

Bonjour,

sans vouloir être alarmiste, je trouve que celui qui essaye des requêtes sur votre site semble connaitre pas mal de choses (si tout est correcte) :

utiut_id
maiuyil
pagdfstss
botegtredfta_sqlprive

Au passage on peu noter que visiblement la requête à retoruné un code HTTP de 200 pour une longueur de 3625 (bytes de mémoire)

HTTP/1.1" 200 3625 "-"

Cordialement, janus57

[fritz2cat]

Si les 2 champs suivants existent dans ta base de données (utiut_id et maiuyil) , alors il est possible que le pirate ait pu prendre connaissance d'une pratie de ton code source. Attention !

[janus57]

Bonjour,

surtout que le robot cherche une faille SQL pour essayer d'accéder à votre BDD.

Je vous conseil de vérifier si votre site n'est pas vulnérable à ce genre d'attaque.

Cordialement, janus57

[boteha]

Bonjour,

Dans les logs j'ai trouvé ces requêtes :

59.152.240.71 www.monsite.com - [12/Nov/2015:15:10:45 +0100] "GET /b.php?a=E2OL*srt&c=Voi&h=2123'%20and%205=6%20union%20select%201,concat(0x5E252421,ifnull(`utiut_id`,0x4E554C4C),char(9),ifnull(`maiuyil`,0x4E554C4C),char(9),ifnull(`pagdfstss`,0x4E554C4C),char(9),0x2A5B7D2F),3,4,5,6,7,8%20from%20`botegtredfta_sqlprive`.`utftropicab`%20limit%2025933,1%20%20--%20%20And%20'6'='6 HTTP/1.1" 200 3625 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0;)"

On cherche à me piquer mes adresses mails, non ?

[boteha]

Bonjour,

Les robots d'indéxation passent tous les jours sans causer de dégâts.

J'ai regardé les logs en temps réel le jour de l'attaque.
Je vais essayer de les retrouver, j'espère qu'OVH conserve le détail.

Mais il me semble que l'idée est de bloquer les requêtes d'un ID quand elles dépassent une certaine fréquence.

Je pense que c'est un problème très connu, non ?

[janus57]

Bonjour,

avez-vous analyser les logs durant cette période pour savoir ce que le robot ou la personne cherchez ?

Car certains robots d'indexation sont un peu "lourd" si le webmaster ne fait rien pour les aider un peu (genre avec un robots.txt et/ou un sitemap).
Ensuite si vous avez vraiment pas de chance, soit c'est effectivement un mini-DoS qui a sans doute un but derrière (genre bruteforce pour essayer de trouver un accès admin voir trouver une faille exploitable), soit c'est juste la malchance d’avoir eu 4-5 robots d'indexation au même moment sur le site (c'est très rare mais déjà) vu).

Donc là dans l’absolu faut analyser vos logs sur la période de temps et trouver toute les actions effectués qui semble "bizarre".

Cordialement, janus57

[boteha]

Bonjour,

Merci de ta réponse.

C'est un site codé à la main en PHP, pas de CMS.

C'est un site marchand, il ne fait pas le buzz, impossible que le trafic soit soudain multiplié par 10 et qu'il redevienne normal quelques heures plus tard (quand le robot le lache).

Le htaccess se limite en gros à URL rewriting.
J'ai l'impression que c'est là qu'il faut entrer les sécurités.

Bonjour,
mettre des sécurité anti-flood etc…

Qu'est-ce que c'est ?

[janus57]

Bonjour,

cela va dépendre d 'un tas de paramètre et surtout de votre site.

On peu toujours donner des conseils générale tel que mettre à jour votre CMS, mettre des sécurité anti-flood etc…

Mais après impossible d'entrer plus dans les détails, mais déjà avoir son site à jour est un point positif, et oui la sécurité des sites c'est pas à OVH de s'en charger mais bien au webmaster, car un trafic x10 c'est "rien" du moment que l'on ne sais pas très exactement ce qui a été fait durant la période ou la trafic a été multiplié par 10 car cela peu très bien être des requêtes légitimes car votre site a été relayé et a fait un mini-buzz.

P.S. c'est pas du piratage du moment que personne ne c'est introduit sur le site par une faille de sécurité ou sans votre accord, là on parlerais plus de flood/DoS voir DDoS (mais le DDoS c'est OVH qui s'en charge sur les mutualisé).

Cordialement, janus57

[boteha]

Bonjour,

Mon site en Mutu chez OVH avec Sql privé a été gravement ralenti.

Trafic soudain multiplié par 10, ce qui ne peut s'expliquer que par un robot qui voulait je ne sais trop quoi.

J'ai appelé OVH et ils m'ont dit que c'était à moi de régler le problème, ce qui m'a étonné car je considère qu'il s'agit d'un problème serveur.

J'ai trouvé cet article excellent :

Sécuriser son site web des attaques des pirates et hackers

Comme je veux aller vite, quelles sont les solutions qui dans cet article sont les mieux adaptées à mon cas ?

Merci d'avance.