e.MiLoU Posté 24 Août 2005 Posté 24 Août 2005 (modifié) Normalement, rien qu'en mettant strip_tags, ça devrait fonctionner. Mais néanmoins si tu veux par exemple afficher du code html dans un example tel que. <p>Cette balise sert à afficher un paragraphe.</p> Il t'affichera alors Cette balise sert à afficher un paragraphe. Pour afficher le texte tel-quel, tu dois utiliser la fonction htmlspecialchars. Il te remplacera les "<" et ">" et tout code vicieux Concernant tes question avec tes requêtes sql, personnelement je procède comme cela. <?phpfunction addquotes($string){ return str_replace("'", "''", $string);}function prepare($string){ return addquotes(nl2br(htmlspecialchars($string)));}// Pour enregistrer un message dans ta base$text = prepare($_POST['text']);$sql = "INSERT INTO table (text) VALUES ('$text')";$sql = mysql_query($sql);?> Ce qui te permets d'avoir plus de compatibilité avec les différents serveurs. Modifié 24 Août 2005 par e.MiLoU
recherche_webmaster Posté 24 Août 2005 Auteur Posté 24 Août 2005 ouf enfin une réponse, je me sens plus proche de la civilisation, merci. Bon les problèmes du dessus ont été en parti résolu, pour les balises autorisées et strip_tags je procède ainsi $bob=strip_tags($_POST['bob']). ça fonctionne, mais si vous avez quelque chose à y redire n'hésitez pas. Maintenant j'ai un autre problème : J'utilise un système de validation par email qui compare le numéro aléatoire (md5)contenu dans le lien du mail et le même numéro aléatoire contenu dans la base, si c'est le même c'est validé. ça fonctionne(ait). Maintenant j'ai rajouté simplement $validation=strip_tags($_POST['validation']); et ça ne fonctionne plus c'est le $validation qui contient le numéro aléatoire renvoyé par le lien, avant il fonctinnait maintenant ça ne fonctionne plus depuis que je filtre avec strip_tags. Une idée ?
recherche_webmaster Posté 24 Août 2005 Auteur Posté 24 Août 2005 J'utilise un système de validation par email qui compare le numéro aléatoire (md5)contenu dans le lien du mail et le même numéro aléatoire contenu dans la base, si c'est le même c'est validé.ça fonctionne(ait).Maintenant j'ai rajouté simplement$validation=strip_tags($_POST['validation']); et ça ne fonctionne plus c'est le $validation qui contient le numéro aléatoire renvoyé par le lien, avant il fonctinnait maintenant ça ne fonctionne plus depuis que je filtre avec strip_tags Auto réponse : Ne serait-ce pas parce que la variable est transmise à la page via une url contenu dans le lien et non par un formulaire ce qui signifie que $_post est ici en trop ? Donc la bonne formule ne serait-elle point $validation = strip_tags($validation) tout simplement?
e.MiLoU Posté 24 Août 2005 Posté 24 Août 2005 [...]ce qui signifie que $_post est ici en trop ? [...] Je dirai plutot qu'il faut mettre $_GET et non $_POST
TheRec Posté 24 Août 2005 Posté 24 Août 2005 Au risque de me faire recevoir comme la dernière fois... c'est effectivement $_GET ... et si dans ton cas l'utilisation de $validation = strip_tags($validation), sans que tu aies fait péalablement $validation = $_GET['validation'], fontionne c'est que tu as le mode register_globals qui est activé ... et là, avant de "filtrer" tes requêtes SQL tu ferais mieux de commencer par le désactiver si tu veux parler de sécurité... PS: Ne me dis pas que tu as passé tellement de temps dans ton code, selon tes dire, que tu ne t'es pas apperçu que depuis PHP4 il est recommandé de ne jamais utiliser register_globals... Il subsite surtout pour des raisons de compatibilité descendante...
recherche_webmaster Posté 24 Août 2005 Auteur Posté 24 Août 2005 (modifié) Ne me dis pas que tu as passé tellement de temps dans ton code, selon tes dire, que tu ne t'es pas apperçu que depuis PHP4 il est recommandé de ne jamais utiliser register_globals... Il subsite surtout pour des raisons de compatibilité descendante... Je ne dis rien du tout je suis en hébergement mutualisé je ne me suis même pas posé la question. et là, avant de "filtrer" tes requêtes SQL tu ferais mieux de commencer par le désactiver si tu veux parler de sécurité... Je suis chez ovh ils ont dû faire le nécessaire non ? Je dirai plutot qu'il faut mettre $_GET et non $_POST En fait si quelqu'un veut m'expliquer quand on utilise l'une plutot que l'autre parce que tout ce que j'ai lu sur le sujet c'est que GET est une ancienne méthode et que l'on doit utiliser POST, maintenant ça ne doit pas être tout à fait ça à vous lire. Modifié 24 Août 2005 par recherche_webmaster
recherche_webmaster Posté 24 Août 2005 Auteur Posté 24 Août 2005 Bon effectivement register-globals est à on. à priori je ne peux pas changer cela non, puisque je suis en mutualisé? Qu'est ce que je dois faire alors ? Déclarer les variables qui contiennent les valeurs à insérer dans la base en faisant $var=strip_tags($_Get['var'] au lieu de $var= strip_tags ($var) ? C'est ça ?
TheRec Posté 24 Août 2005 Posté 24 Août 2005 As-tu seulement essayé ceci dans un fichier .htaccess, à la racine de ton site : php_flag register_globals 0
recherche_webmaster Posté 24 Août 2005 Auteur Posté 24 Août 2005 non c'est gentil je ne veux pas bidouiller ce genre de chose pour le moment, je débute encore pour les 3 mois qui viennent. Par contre j'ai quand même fait fonctionner mes 139 neurones et j'ai capté la différence, énorme, entre htmlentities et strip_tags. Et donc j'ai conservé seulement le premier bien sur. Alors je fais comme cela (sur la page qui recoit les variables du formulaire) et je voudrais votre avis SVP. $var= htmlentities($_POST['var']) ça fonctionne, je viens d'essayer. Mais ne devrais-je pas par exemple remplacer POST par GET? Et comment je fais maintenant pour conserver les balises <br>, <b> etc... j'ai essayé ça bug. Enfin dernière question : htmlentities me protège t'elle des problèmes de register global à on voir de tout comme j'ai pu le lire sur ce forum?
Anonymus Posté 24 Août 2005 Posté 24 Août 2005 Pour la balise <br>, ca ne devrait pas poser de soucis : Une personne rentre un texte dans un champ 'textarea', et la balise se met en place automatiquement (grace à la fonction nl2br). Il te suffit donc de faire d'abord htmlentities, puis ensuite nl2br. Pour les autres balises, en fait elles sont changées. Concrètement, il ne s'agit plus de <b>, mais de "<b>". C'est donc cette chaine de caractères qu'il te faut chercher, et remplacer par l'original, à savoir <b>. Et ton 'gras' devrait s'afficher.
recherche_webmaster Posté 24 Août 2005 Auteur Posté 24 Août 2005 ok mais je ne pige pas comment je met en place le nl2br là par contre. Je viens de faire le test: j'entre un message en sautant une ligne dans le textarea. Je filtre ça avec htmlentities, ça arrive dans la base. Je retrouve mon saut de ligne dans le champ correspondant de phpmyadmin, sans qu'il n'y ait de balise. Dans mon admin le texte s'affiche avec le saut de ligne, et se replace dans la base avec le même saut de ligne. Toujours sans balises, elles n'apparaissent pas par magie. Donc ensuite sur le site bien sur plus de saut ligne puisque pas de balise. A quel endroit je les place alors ces balises? au moment ou le visiteur rempli le textarea pour que lorsqu'il clique "entrée" il y ait une balise <br> qui apparaissent. ensuite elle est défaite par htmlentities et recomposée par le navigateur et hop ça suit sont cours c'est bon. Mais comment je fais pour transformer ce saut de ligne en <br>. A quel moment et comment ça se passe ? Là je n'ai pas compris.
Anonymus Posté 24 Août 2005 Posté 24 Août 2005 Normalement sauf erreur de ma part, htmlentities ne touche pas aux caractères spéciaux. Donc, tu peux mettre la fonction nl2be juste avant l'affichage. En gros : L'internaute remplit le formulaire, tu récupères les données que tu formates avec htmlentities, tu stockes dans la db, tu sors les données de la db, tu les affiches. Lorsque tu les affiches, au lieu de faire : echo $texte, tu fais echo nl2br($texte); tout simplement.
TheRec Posté 24 Août 2005 Posté 24 Août 2005 (modifié) non c'est gentil je ne veux pas bidouiller ce genre de chose pour le moment, je débute encore pour les 3 mois qui viennent. <{POST_SNAPBACK}> A ta place je ne considérerais pas ça comme une "bidouille"... s'était une des principale faille (la faille vient du fait que peu de monde "sécurisait" ses variables, pas de PHP.). Libre à toi de ne pas le faire, tu auras beau sécuriser tes requêtes SQL comme tu veux tant que register_globals est activé, tu risques plus que si tu les laissais telle quelle sont maintenant. Mais bon je ne suis pas à ta place... Modifié 24 Août 2005 par TheRec
recherche_webmaster Posté 24 Août 2005 Auteur Posté 24 Août 2005 (modifié) tout simplement. futé J'essaye ça je te dis le résultat tu risques plus que si tu les laissais telle quelle sont maintenant Tout de même ça n'est pas des idiots chez ovh pourquoi eux l'ont laissé sur on ce paramètre? Modifié 24 Août 2005 par recherche_webmaster
Anonymus Posté 24 Août 2005 Posté 24 Août 2005 Ils ne l'ont pas laissé, c'est le paramètre par défaut dans la plupart des cas. Ce n'est pas pour ca qu'il faut le laisser comme ca. De plus, ils sécurisent leurs serveurs, leurs accès, mais laissent libre les accès aux programmes, c'est au développeur de sécuriser le programme, pas à l'admin. réseau/système. De leur coté, c'est sécurisé. Dis différemment, s'ils mettaient à off le register_globals, la plupart des scripts ne marcheraient pas. Ou tout du moins, un bon paquet. Ce n'est pas pour ca qu'il faut laisser comme c'est. Voilà.
recherche_webmaster Posté 24 Août 2005 Auteur Posté 24 Août 2005 Bon alors je vais faire le nécessaire. Mais comment ? ça me fout les jetons de toucher aux paramètres du serveur, je ne sais pas du tout comment faire. Et après? je vais devoir redéclarer toutes mes variables au début de chaque script, en marquant $bob=$_POST[bob]? C'est ça? pas d'autre contrainte? Mais je n'ai pas besoin de faire cela pour les variables dont le contenu provient de la base non? juste pour les variables issuent d'un formulaire? Bon comment je fais s'il vous plait?
TheRec Posté 24 Août 2005 Posté 24 Août 2005 (modifié) Tu as assez bien résumé ce que tu devais faire tout seul... pour désactiver le flag "resgister_globals" regarde mon message précédent... tu créer un fichier texte .htaccess et tu met le contenu que j'ai donné précédemment. Tu le transferts en mode ASCII à la racine de ton site par FTP...et le tour est joué si tout va bien... la majorité des mutualisé que j'ai eu l'occasion d'utiliser permettent ceci...je n'ai pas eu l'occasion de tester chez OVH... Modifié 24 Août 2005 par TheRec
recherche_webmaster Posté 24 Août 2005 Auteur Posté 24 Août 2005 (modifié) j'ai un htaccess pour l'urlrewriting, donc je recopie bêtement le bout de code que tu m'as donné et ça doit fonctionner c'est ça? edit: bon ça doit pas être ça parce que je viens de copié coller nonchalament la ligne de code que tu as écrite, juste à la suite de mes règles de réécriture, maintenant je ne peux plus du tout accéder au site. Modifié 24 Août 2005 par recherche_webmaster
recherche_webmaster Posté 24 Août 2005 Auteur Posté 24 Août 2005 d'après ce que j'ai lu sur les guides d'ovh il faut être en serveur dédié pour pouvoir modifier ce paramètre. non? en tout cas comme j'ai essayé ça ne donne rien du tout.
TheRec Posté 24 Août 2005 Posté 24 Août 2005 (modifié) Si tu reçois une erreur 500 (Erreur Interne au Serveur), c'est que tu n'a pas les privilèges pour désactiver le register_global ... Dans ce cas, vérifie TOUJOURS toutes les variables que tu utilises, même (et surtout) une variable qui ne provient pas d'un forumlaire... par vérifier j'entends, s'assurer du type des variables (entirers, chaînes de caractères, ...) et de leur contenu. Par exemple, dans tous les cas où c'est possible, limite les valeurs possibles seulement à ce qui est suceptible d'être utilise. Le problème réside dans le fait que n'importe qui peut initaliser une variable en ajoutant un paramètre à l'URL... Si tu utilises par exemple l'opérateur de concaténation ".=" avec une variable que tu n'a pas initialisée toi-même, il est possible que l'utilisateur l'initialise lui-même par l'URL...et il peut y mettre un contenu nuisible à ton site... Modifié 24 Août 2005 par TheRec
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant