injection de code

Bonjour, j'explique mon cas :

je suis en train de développer une application web et je n'y connais pas grand chose en sécurité. Et même si mon application ne referme pas de donnée vital pour la nation, j'apprécierais pouvoir dormir sur mes 2 oreilles lorsque je la métrais en ligne.

pour le moment, je m'intéresse aux injection de codes (XSS) et après avoir tester dans mon coin, j'ai trouver une petite parade toute simple, mais elle me parait trop simple pour être réellement efficace :

je fais passer chaque $_POST venant de l'extérieur dans une petite fonction que voici :

Code:

---

1 2 3 4 5 6 7

public static function replace_to_insert($str){ $res = str_replace("'", "&acute;", $str); $res = str_replace("\n", "<br />", $res); $res = str_replace("<", "&lt;", $res); $res = str_replace(">", "&gt;", $res); return $res; }

---

j'ai tester d'ajouter ceci dans tout mes champs de saisie :

Code:

---

<script>alert("ça craint")</script>

---

est j'affiche bien la ligne sans avoir l'alert.

mais est-ce suffisant ??

de plus, serait-il possible d'avoir une liste des différentes les plus élémentaire don je doit faire attention, y en a tellement que j'en découvre tout les jours en me baladant sur developpez.com

merci

édit : finalement, mon code ne récupère plus les balise <br />, et je ne comprend pas pourquoi ...
édit2 : le problème des <br />est réglé, c'était juste une erreur très bête d'ordre d'instruction dans ma fonction replace_to_insert. il faut mètre le remplacement de \n a la fin.

Salut

A ce que j'en sais (c'est soumis à caution hein, j'ai moi même une question concernant les failles XSS, mais je vais ouvrir un sujet dessus), le plus simple est d'utiliser htmlentities($ton_texte, ENTQUOTES); . J'ai lu à plusieurs endroits que c'était efficace, et simple à mettre en place...

Le soucis que j'ai (mais ton code pose le même problème) est que dans ce cas, TOUTES les balises html sont inopérantes. Donc les sauts à la ligne (<br/>), les images (<img src="" />) etc... Ce qui dans mon cas pose problème.

J'espère t'avoir un peu éclairé ;)

alor oui, ca ma un peu écléré, surtout si tu peu m'assuré qu'aucune balise ne peu plus etre inséré. car c'est ce que je recherche. le problem du <br />, je le regle dans mon second edith. c'est a dir en changeant les \n en <br /> en tout dernier lieu.

mais je voudrai quand meme savoir si ca semble réellement suffisant.

je vais reguarder plus en detail le htmlentities pour voir ce que je peu en faire.

Pour construire tes requêtes SQL, il ne faut jamais appeler directement les variables dans le code de la requête (par exemple ne jamais faire : "insert into matable (x, y) values ('$var1', '$var2')") mais passer par des fonctions qui transforment les valeurs en chaînes compatibles SQL. Par exemple, en PHP, il faut utiliser une combinaison de mysql_real_escape_string et de sprintf (http://www.php.net/manual/fr/function.mysql-query.php en donne un exemple). Si tu fais du J2EE, toujours passer par les PreparedStatement, ça fera les transformations qui vont bien.

Ensuite pour l'affichage de ce que tu récupères de ta base, il faut effectivement passer par un htmlentities pour transformer les < en &lt; etc.

Y a sûrement d'autres trucs comme par exemple ne jamais mettre de paramètre d'URL ou de formulaire contenant un semblant de bout de code SQL, nom de table, etc.

Grand Merci Mac, je vais modifier toute mes requetes et ajouter des 'mysql_real_escape_string'. Par contre, peut-on se contenter de htmlentities pour tout ce qui est champs de saisie ??? ou quelque test de plus peuvent etre util ??

Je sais pas trop. Je pense qu'un htmlentities suffit mais peut-être que ça ne marche pas bien si c'est pour afficher une valeur dans un attribut : (<input ... value="<?php echo htmlentities($var); ?>" ...>) : comme il y a des " autour, y a peut-être une transformation des quotes à faire en plus. J'ai fait ç il y a longtemps, je ne m'en rappelle plus.

htmlentities($ton_texte, ENTQUOTES); permet justement, sauf erreur de ma part, de convertir les guillemets doubles ou simples. On peux aussi spécifier l'encodage en dernier argument, en cas de soucis d'accents, il me semble (il va les encoder lui même, si tu utilise l'ISO-8859-1 par exemple).

Après il est certain qu'à la base, on l'utilise plutôt pour afficher du texte... Que ce soit dans un <input>, ou pas :)

Voici un article abordant le sujet des failles XSS, qui est plutôt bien fait à mon sens : http://www.tux-planet.fr/blog/?2008/...site-scripting . Il parle des différents types de failles existant, et pas juste de la plus connue (utilisation de la balise <script>), et explique pourquoi telle ou telle protection est insuffisante ou non.

Très bon article, en effet ... merci beaucoup.

J'espère que le htmlentities est aussi magique que ça.