Protection Injection MySql

Bonsoir,

Je regarde actuellement dans votre tuto les protections pour tout ce qui est faille Xss et injection SQL.

Je me demandais si elles étaient toujours d'actualité ?

Faille Xss :

Code:

---

function failleXss($string) { return htmlentities($string,ENT_QUOTES,'UTF-8'); }

---

Et pour l'injection Sql que je n'ai pas très bien saisi :

Code:

---

1 2 3 4 5 6 7 8 9

function quote_smart($value) { if(get_magic_quotes_gpc()) { $value = stripslashes($value); }   return mysql_real_escape_string($value); }

---

pour un code du type :

Code:

---

1 2	$req=$bdd->prepare('INSERT INTO minichat values (default, :pseudo , :message )'); $req->execute(array('pseudo' => quote_smart($_POST['pseudo']),...(etc)

---

Si elle est toujours d'actualité, quelqu'un pourrait m'expliquer l'utilisé du get_lagic_quotes_gpc et du stripslahes ?

Merci beaucoup d'avance !
Ca m'est d'une grande aide

magic_quotes était un mécanisme de protection automatique des données de formulaire mais c'est complétement obsolète (même si on pourra bien le trouver encore sur certains serveurs).
mysql_real_escape_string() concerne l'ancienne extension mysql_ (qu'on trouve encore largement sur tous les serveurs).

Étant donné que tu utilises PDO avec des requêtes préparées, cela ne te concerne pas.

Par contre htmlentities() à l'affichage c'est toujours valable.

Salut, merci du retour.

Concernant l'affichage , il existe strip_tags qui permet non pas d'écrire les balises pour éviter la faille , mais au contraire de les enlever.
T'en penses quoi si je mets celle ci à la place de htmlentities. ( on m'a également parlé de htmlspecialchars )

Concernant les failles SQL, je suis un peu perdu.
Comment je dois me protéger actuellement ?

La fonction ne me sert à rien ? :

Code:

---

1 2 3 4 5 6 7 8 9

function quote_smart($value) { if(get_magic_quotes_gpc()) { $value = stripslashes($value); }   return mysql_real_escape_string($value); }

---

Citation:

---

Envoyé par tchoumo

Salut, merci du retour.

Concernant l'affichage , il existe strip_tags qui permet non pas d'écrire les balises pour éviter la faille , mais au contraire de les enlever.
T'en penses quoi si je mets celle ci à la place de htmlentities. ( on m'a également parlé de htmlspecialchars )

---

Ca serait une mauvaise utilisation de la dite fonction, qui conduiront tôt ou tard à des problèmes (c'est bête, mais par exemple, il se peut que tu te retrouve un jour avec des utilisateurs qui peuvent pas écrire de formule de math dans un champs texte, car les symboles < et > pourraient former des balises).

edit : d'ailleurs, en faisant ça, je n'aurais pas pu écrire < et > dans ce forum !

Par ailleurs, htmlentities, en plus des caractères des balises convertis également tous les caractères accentués, évitant de fait des problèmes d'encodage chez certains utilisateurs. Donc à partir du moment ou tu veux ecrire du texte dans le code html depuis le code php, si ça vient d'une bdd ou d'un formulaire, le htmlentities devrait être systématique.

Citation:

---

Concernant les failles SQL, je suis un peu perdu.
Comment je dois me protéger actuellement ?

---

si tu utilises la PDO et les requetes préparées (comme dans ton exemple), tu es totalement protégé sans n'avoir rien à faire.

Citation:

---

$req=$bdd->prepare('INSERT INTO minichat values (default, :pseudo , :message )');
$req->execute(array('pseudo' =>$_POST['pseudo']),...(etc)

---

l'exemple ci-dessus est exempt de faille, bien que tu ailles chercher la valeur direct dans le post sans la protégé car la PDO gèrera automatiquement la protection en fonction du type !

Par contre, si tu fais :

Citation:

---

$req=$bdd->prepare('INSERT INTO minichat values (default, :pseudo , "'.$variable.'" )');
$req->execute(array('pseudo' =>$_POST['pseudo']),...(etc)

---

là, tu ouvres potentiellement un faille.

Donc tant que tu utilises la PDO et que tu passe tes variables à ta requetes via execute() ou bindValue(), tu es protégé !

Pour les injections SQL ce que tu fais est bon : requête préparée avec paramètres nommés et execution avec les valeurs.

Pour XSS, strip_tags() n'est pas suffisant et peut par contre retirer du texte innoncent en pensant que c'est un tag html.

Bon bah voilà, je vous aime :roll:

Merci infiniment, c'est très clair et ça m'enlève un clou !