Victime d'une tentative de hack : "injection SQL"

LorenSnow · 27-06-2018 15:41:04

Bonjour à tous,

J'ai créé mon site internet suite à une formation en autodidacte au html, css, php et MySQL.
Il est constitué d'une base de données avec plusieurs tables (utilisateurs et stock).

Je m'aperçois qu'il y a deux jours, un utilisateur a tenté de rentrer dans ma base de données par injection SQL, via le biais du formulaire de contact et du formulaire de création de compte. L'attaque a duré environ 2 minutes, et l'utilisateur a posté durant ce laps de temps environ 350 messages et 350 comptes de créés. J'ai l'impression que l'attaque n'a pas abouti et que ses tentatives ont échouées grâce à mes protections.

Ma question se divise en deux :
- Reconnaissez vous ce type d'attaque ? Comment pouvons nous savoir si l'utilisateur a pu rentrer dans la base de données et la fouiller ? Ou alors si il n'a pas réussi ?

- Mes défenses sont-elles bonnes ?

Voici 4 messages postés lors de l'attaque, par le formulaire contact.

mail : sample@email.tst
nom : bbgjccst
prénom : -1 OR 3+319-319-1=0+0+0+1 --
message : 20
idstock : 0
(idstock est l'objet à partir duquel on pose la question, 0 signifie aucun objet sélectionné)

---

mail : sample@email.tst
nom : kyvclywx
prénom : kyvclywx
message : 20
idstock : 10622
(Formulaire contact appelé de la page de l'objet 10622)

---

mail : sample@email.tst
nom : toyWtwIv'));select pg_sleep(10); --
prénom : bbgjccst
message : 20
idstock : -1
(-1 impossible, l'adresse URL a été modifiée, car le numéro objet passe par l'URL)

---

mail : sample@email.tst
nom : azz0pgqH')); waitfor delay '0:0:15' --
prénom : bbgjccst
message : 20

- Dans le champ mail, il n'y a eu que " sample@email.tst "

- dans le champ nom et prénom il y a eu :
bbgjccst
mphYwrOB';select pg_sleep(5); --
azz0pgqH')); waitfor delay '0:0:15' --
hZksAILq'); waitfor delay '0:0:10' --
-1' OR 2+693-693-1=0+0+0+1 --
-1" OR 2+699-699-1=0+0+0+1 --
if(now()=sysdate(),sleep(12),0)/*'XOR(if(now()=sysdate(),sleep(12),0))OR'"XOR(if(now()=sysdate(),sleep(12),0))OR"*/
et aussi : 1 , ou -1 , ou 1'" , ou / etc...

et dans message, pareil, mais surtout : ' 20 '

Concernant mes défenses.

Lors de la conception, j'ai tenté comme j'ai pu de me prévenir des attaques venant de l'utilisateur, comme l'injection SQL. Avec les fonctions "addslashes" et "PDO:prepare, execute".

Dans mon formulaire création de compte, voici une partie de mon code, qui récupère les valeurs rentrées dans le formulaire, et les passe par la fonction addslashes avant de les utiliser dans la requête INSERT INTO :

  $nom = addslashes($_POST['fEnrNom']) ;

      $prenom = addslashes($_POST['fEnrPrenom']) ;

      $mail = addslashes($_POST['fEnrMail']) ;

      $mdp = addslashes($_POST['fEnrMdp']) ;

      $tel = addslashes($_POST['fEnrTel']) ;

      $adresse = addslashes($_POST['fEnrAdresse']) ;

      $sqlEnr = "INSERT INTO t_utilisateurs (

      mail, password, 

      nom, prenom,

      tel, adresse) 

      VALUES (

      '".$mail."','".$mdp."',

      '".$nom."','".$prenom."',

      '".$tel."','".$adresse."')" ;

      $reqEnr = $pdo -> query($sqlEnr)

      or die (print_r ( $pdo -> errorInfo())) ;

Pour mon formulaire contact ,

Mon code fonctionne avec PDO prepare et , PDO execute ,
Voici mon code :

if(strlen($_POST['FcontactPrenom']) < 40 AND strlen($_POST['FcontactNom']) < 40

  AND strlen($_POST['FcontactMail']) < 40 AND strlen($_POST['FcontactMessage']) < 1500)

  {

          $sqlMes = $pdo -> prepare ( " INSERT INTO t_messages (nom , prenom , mail , message , idOeuvre ) VALUES ( ? , ? , ? , ? , ? )" ) 

    or die (print_r ( $pdo -> errorInfo())) ;

    $sqlMes -> execute (array ($_POST['FcontactNom'],$_POST['FcontactPrenom'],$_POST['FcontactMail'],$_POST['FcontactMessage'],$_POST['FcontactId']));

Je rappelle mes questions :
- Reconnaissez vous ce type d'attaque ? Comment pouvons nous savoir si l'utilisateur a pu rentrer dans la base de données et la fouiller ? Ou alors si il n'a pas réussi ?

- Mes défenses sont-elles bonnes ?

Je vous remercie pour votre attention, et je vous souhaite une très bonne journée et fin de semaine.

Lorenzo

KOogar · 25-02-2019 05:44:47

Commence déjà par mieux te protéger des injonctions :
$connnection->real_escape_string ()

Le pirate, ou plutôt le robot spammeur, n'a pas pu lire ta base, soit rassuré.

Le mieux est d'avoir un script anti hack qui empêche les connections répétitives :
+ de 10 connections par minute -> IP backlisté

Avoir son site en HTTPS aide aussi.

Jc · 27-02-2019 14:01:36

Bonjour,

real_escape_string ou autre fonction du genre ne va pas vous protéger des injections SQL qu'on se le dise.
Je vous invite à relire la documentation de ce genre de fonction pour mieux comprendre ce qu'elle fait exactement. Elle vous évitera qu'une chaîne de caractères du style 'J'ai bu du café ce matin' génère une erreur lors de l'insertion en base. En effet si on échappe pas les apostrophe, php considérera l'apostrophe du J'ai comme un marqueur de fin de chaîne alors qu'il se situe après le mot matin.
Eviter les injections SQL ne relève d'aucune science ni d'une quelconque boule de cristal. C'est à vous donc de faire attention à votre façon de gérer les variables et aux requêtes utilisées passées en base de données notamment pour les éviter. C'est du simple bon sens. Faites en sorte notamment de supprimer de toute chaîne de caractère les symboles pouvant être considérés comme une marque de commentaires pour le moteur de bases de données utilisé dans votre applicatif.
Un petit lien pour commencer à vous familiariser avec l'injection que je viens de trouver pour vous : https://zestedesavoir.com/tutoriels/945 … scription/

Bonne journée,

KOogar · 28-02-2019 07:18:29

Jc a écrit :

real_escape_string ou autre fonction du genre ne va pas vous protéger des injections SQL qu'on se le dise.

mysql_real_escape_string() to escape special characters in a string before sending a query to MySQL. This function was adopted by many to escape single quotes in strings and by the same occasion prevent SQL injection attacks.

Jc · 06-03-2019 21:43:14

Continuez à l'utiliser pour vous protéger des injections
Je vous propose un test : appliquez votre real_escape_string à l'exemple du lien que je vous ai fourni, et observez le résultat.
Bonne continuation

KOogar · 07-03-2019 07:12:14

@Jc
Prends pas la mouche stp, d'autant plus que 99% de la solution se trouve bien dans la réponse que tu donnes:
"C'est à vous donc de faire attention à votre façon de gérer les variables et aux requêtes utilisées passées en base de données notamment pour les éviter. "

Mais de la a dire que mysql_real_escape_string est inutile contre le hack, ce n'est pas un avis partagé.

Pour compléter j'ajoute :
- avoir ses logiciels a jour (apache, nginx, mysql...)
- utilisation de la géolocalisation pour bannir des pays (Russie et Asie, particulièrement la Chine qui est très virulentes ses derniers temps)
- script anti hack : + de 10 connections par minute -> IP backlisté
- utilisation du HTTPS

Jc · 10-03-2019 15:02:05

Bonjour,

Je ne prends pas la mouche. On est ici sur un forum de débutant et affirmer de tels choses est pour moi irresponsable vis-à-vis des lecteurs de ce forum.
Je dis donc les choses comme elles sont et comme il est de ma responsabilité de les dire.
Ensuite, pour ceux qui utilisent mysql_real_escapte_string, outre le fait que je les encourage à passer à PDO, je n'ai pas dit qu'il était inutile mais très largement insuffisant car il n'offre aucune garantie contre le hack.

Bonne journée.

KOogar · 10-03-2019 18:54:23

Jc a écrit :

... affirmer de tels choses est pour moi irresponsable vis-à-vis des lecteurs de ce forum.

Et voila !! un de plus .... A quel moment j'affirme que mysql_real_escapte_string va résoudre les problèmes de hack ? Merci de ne pas me prêter de tel affirmations. Cdlt

KOogar · 07-04-2019 04:17:52

Je reviens au sujet, un développeur explique les problèmes d'injection, ca vient de la League des Packages

C’est la porte ouverte pour le piratage comme l’injection SQL......

https://eilgin.github.io/php-the-right- … _extension
http://wiki.hashphp.org/Validation

PHP|Débutant :: Forums

Advertisement

#1 27-06-2018 15:41:04

Victime d'une tentative de hack : "injection SQL"

#2 25-02-2019 05:44:47

Re : Victime d'une tentative de hack : "injection SQL"

#3 27-02-2019 14:01:36

Re : Victime d'une tentative de hack : "injection SQL"

#4 28-02-2019 07:18:29

Re : Victime d'une tentative de hack : "injection SQL"

#5 06-03-2019 21:43:14

Re : Victime d'une tentative de hack : "injection SQL"

#6 07-03-2019 07:12:14

Re : Victime d'une tentative de hack : "injection SQL"

#7 10-03-2019 15:02:05

Re : Victime d'une tentative de hack : "injection SQL"

#8 10-03-2019 18:54:23

Re : Victime d'une tentative de hack : "injection SQL"

#9 07-04-2019 04:17:52

Re : Victime d'une tentative de hack : "injection SQL"

C’est la porte ouverte pour le piratage comme l’injection SQL......

Pied de page des forums