Tentative de hack par l'url !

[defacta]

Salut,

J'ai un site sur lequel on a fait des tentatives de hack, dans les url ils ont ajouté:

Code :

book.php?b=16/**/union/**/select/**/1,2,3,4,5,6,7,8,9/**/from+user/**/

une autre:

Code :

book.php?b=999999.9+UNION+ALL+SELECT+0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x3130323534383030

une autre:

Code :

book.php?b=9999+and+1%3D1

allez, une dernière pour la route:

Code :

book.php?b=16/**/union/**/select/**/1,2,3,4,5,6,version(),8,9/**/from+user/**/

Il y a en a plus d'une cinquantaine comme ça !
Mais dans mon code au tout début du fichier book.php, il y a:

Code :

1
2
3
4
5
6
foreach ($_POST as $key => $value) {
  $_POST[$key] = mysql_real_escape_string($value);
}
foreach ($_GET as $key => $value) {
  $_GET[$key] = mysql_real_escape_string($value);
}

Vous croyez que ca a suffit pour me protéger ? Qu'est qu'il a essayé de faire avec ces unions et autres codes bizarres comme 1%3D1 ?

J'ai vérifié d'où venait l'addresse IP qui a fait ces tentatives de hack, et elle vient de : IRAN, ISLAMIC REPUBLIC OF

Iran ! Y a pas grand chose à faire, non ? Je vais pas essayer d'avertir les autorités compétentes...non ?

Merci pour votre éclaircissement

[rawsrc]

Bonjour,

si tu as absolument protégé tous tes filtres avec mysql_real_escape_string(), je pense sincèrement que rien n'a été compromis. Dans tous les cas, regardes du côté du journal des requêtes exécutées sur le serveur mysql et tu devrais voir comment les données ont été présentées.

J'avais lu un poste similaire sur cette attaque ici.
Ensuite pour la suite à donner, je suis dubitatif quant à l'efficacité. Dépose une plainte pour tentative d'intrusion dans un système automatisé de traitement de données.
J'avais gardé ce lien dans mes archives. Bon ça date mais tu auras déjà de quoi ronger un os.
Essaies tant bien que mal de maintenir à jour tes versions de softs parce que les versions obsolètes sont à la longue dangereuses. Je t'invite quand même (si ce n'est déjà fait) à blinder à mort la gestion de tes logs tant du côté du PHP que de la base de données.

[defacta]

Salut,

Qu'est ce que tu veux dire par filtre ? Toutes les variables sont parsée mysql_real_escape()...

Sinon, la personne avant de faire ces tentatives d'injection SQL était ici: (history_url)
http://www.yougetsignal.com/tools/we...on-web-server/

Donc, à mon avis ce n'est pas moi qui était visé mais plutôt le serveur sur lequel tourne mon site...pour peut-être attaquer un autre site.

On peut accéder au journal des requêtes exécutées sur le serveur mysql avec phpMyadmin ?

Merci.

[stealth35]

si t'es en utf8 pense bien a mettre le mysql_set_charset qui lui agis aussi le mysql_real_escape_string

[Celira]

Juste pour expliquer les codes "bizarres"

Code :

book.php?b=9999+and+1%3D1

L'idée est d'ajouter 1=1 comme condition dans une requête. Comme 1=1 est toujours vrai, ça supprime toutes les autres conditions de ta requête et retourne toute(s) la(les) table(s) de la requête :

Code :

book.php?b=16/**/union/**/select/**/1,2,3,4,5,6,7,8,9/**/from+user/**/

L'idée cette fois est d'ajouter l'affichage de ta table des utilisateurs, pour récupérer au moins les identifiants et des informations comme les adresses, voire les mots de passe si ils sont stockés en clair (ce qui n'est pas une bonne idée)

[Doksuri]

pour que tu y vois plus clair dans les requetes de l'url : cherche "asciifull" comme image


pour l'explication book.php?b=9999+and+1%3D1
dans la colonne "Hx" (de l'image) tu cherche 3D (tu vois que ca correspond au caractere '=')
donc %3D sera interprete comme un '='.
=> donc ca donnera le fameux 1=1 explique par Celira
(c'est souvent utilise.)

[s.n.a.f.u]

Petite note au passage : utiliser PDO et les requêtes préparées aide grandement à se prémunir de ce genre de plaisanteries....