[RÉSOLU] Get_magic_quotes_gpc

Bonjour,

je dois monter une interface de gestion de news, avec PHP et MySQL. Je voudrais que l'auteur d'un article puisse utiliser des balises HTML (comme <strong> ou <em>) lorsqu'il rédige son texte.

En même temps, je veux être sûr de bien protéger ma base des injections SQL (même non-intentionnelles, avec une simple apostrophe dans un mot).

Je ne dois donc pas utiliser htmlspecialchars() qui m'empêcherait d'utiliser des balises dans le texte, et je n'ai pas besoin d'utiliser addslashes() puisque mon serveur me retourne 1 si j'appelle get_magic_quotes_gpc().

Actuellement, tout fonctionne bien (mes textes comportent des balises, des apostrophes et toutes sortes de caractères) avec de simples $article = $_POST['article']; non protégés.

Ma question (un peu parano ) : est-ce que tout va bien dans le meilleur des mondes, ou est-ce que j'oublie une protection quelconque ?

Merci d'avance !

Bonjour, (ou bonsoir, c'est selon )

La question n'est pas du tout parano, c'est toujours une très mauvaise idée d'autoriser les balises HTML dans les posts !
Donc, il ne faut pas le faire..

Comme (et si) le besoin est d'avoir seulement quelques balises de mise en forme du document (comme strong et em, telles que citées), il y a 2 solutions :
- utiliser la fonction strip_tags en ne permettant que les quelques balises nécessaires.
- (beaucoup) mieux : ce que font tous les forums (comme ici), implémenter un système de BBcode ; l'utilisateur tape des balises du genre [ b] et [ /b] qui sont transcrites à l'affichage par <strong> et </strong>.

Du moment que les magic quotes sont actifs, tu ne risques rien au niveau du SQL.
Par contre pour le HTML, je rejoins l'avis précédent.

Pour l'anecdote, j'avais voulu montrer à quelqu'un d'un peu niais qui avait justement autorisé le HTML dans les posts que ce n'était pas vraiment une bonne idée....
Quelques exemples de codes malicieux, dans l'ordre du plus "gentil" au plus " méchant" (je lui avais posté quelque chose dans quelque chose qui ressemblait au deuxième exemple) :

1.
<a href="http://..." style="text-decoration:blink; font-size:144pt; font-weight:900; color:white; background-color:red;">Cliquez ici !</a>

2.
<script type="text/javascript"< alert("Cracked  !"); </script>

Ca reste relativement sympa jusque-là, mais si on était vraiment sadique...

3.
<script type="text/javascript"> document.location.href = "http://..."; </script>

J'ai pire, je connais un code javascript d'une seule ligne qui fait planter IE à coup sûr. Je ne le mettrai pas ici cependant, pour éviter de donner des mauvaises idées à certains...

Salut,

Mpok a écrit :
La question n'est pas du tout parano, c'est toujours une très mauvaise idée d'autoriser les balises HTML dans les posts !
Donc, il ne faut pas le faire..

Je ne suis pas tout à fait d'accord.

Tout dépend du niveau de confiance que l'on accorde à l'utilisateur. Typiquement, dans le cas d'une interface d'administration (et dans le cas où l'utilisateur connait au minimum le HTML), il me semble que le fait de passer par une syntaxe Wiki ou BBCode est inutile.

Mpok a écrit :
c'est toujours une très mauvaise idée d'autoriser les balises HTML dans les posts !

Source ? (surtout pour le "toujours")

C'est pour une interface de gestion de news, donc très probablement pas ouverte à n'importe qui, et si l'auteur connaît (X)HTML pourquoi le lui interdire ? Pourquoi restreindre sa liberté au BBcode (et à ses <br /> à foison) ? Vous croyez que l'auteur va saboter lui-même son site ?

QuentinC a écrit :
Du moment que les magic quotes sont actifs, tu ne risques rien au niveau du SQL.

Ah ? Tu devrais en toucher 2 mots à Chris Shiflett alors...

Pour l'échappement des données pour MySQL, il existe une fonction qui est faite (et bien faite) pour ça : mysql_real_escape_string().

Salut,
effectivement, mieux vaut ne pas se fier aux magic_quote et se préoccuper de toujours protéger soi-même les données qui transitent par la base, TOUJOURS !

Mais ce n'est pas ce qui m'amène, c'est plus drôle, le BBcode. L'implémentation du BBcode par le script (caret en général et ici en particulier) qui va bien est relativement une horreur en termes d'intrusivité du javascript.

Bon, je ne vais pas faire mon chipoteur, surtout ici, ce serait de mauvais goût, mais dans le source de cette même page on trouve malgré tout

<a href="#" onclick="javascript:void(window.open(

pas over accessible !!

Enfin, ça doit être parce qu'en plein mootools et en voyant la façon élégante dont javascript peut-être impléménté, ça me fait pousser une troisième manie après css/xhtml et php

Bref, tout ça pour dire que pour donner la possibilité de mise en forme, à la dose que l'on veut, dans des éléments de formulaire, il existe des outils fabuleux dont FCKeditor, gratuit et opensource, qui, si on se prend un poil le choux avec, permettent de n'intégrer que des balises de styles de la façon la plus propre qui soit.

Ne soyons pas plus royaliste que le roi, développer un forum complet serait une entreprise délirante, mais quand on monte une appli perso avec des champs de formulaire comprenant de la mise en forme, ici en particulier, ça vaut le jus de jeter un oeil aux outils qui permettent de le faire en obtenant un résultat, propre, accessible et valide.

Voilou, désolés auprès des maîtres des lieux pour la pointe d'ironie mais ce sont sans doute les diatribes du thread consacré à gucci.com (ils étaient d'ailleurs parmi les plus modérés sur le sujet, je tiens à le préciser) qui me font une petite poussée de paille et poutre dans l'oeil de son voisin

Have swing

Julien Royer a écrit :
Tout dépend du niveau de confiance que l'on accorde à l'utilisateur. Typiquement, dans le cas d'une interface d'administration (et dans le cas où l'utilisateur connait au minimum le HTML), il me semble que le fait de passer par une syntaxe Wiki ou BBCode est inutile.

Effectivement, seules une ou 2 personnes auront accès à l'interface de rédaction des articles ; et je n'ai plus le temps d'implémenter BBCode (je ne sais pas le faire d'ailleurs).

QuentinC a écrit :
Quelques exemples de codes malicieux, dans l'ordre du plus "gentil" au plus " méchant" (je lui avais posté quelque chose dans quelque chose qui ressemblait au deuxième exemple) [...]

Mpok a écrit :
- utiliser la fonction strip_tags en ne permettant que les quelques balises nécessaires.

Je peux effectivement, par sécurité, limiter l'accès à seulement certaines balises, genre <strong>, <em>, <br /> et <img>

djfeat a écrit :
Pour l'échappement des données pour MySQL, il existe une fonction qui est faite (et bien faite) pour ça : mysql_real_escape_string().

virtualgadjo a écrit :
effectivement, mieux vaut ne pas se fier aux magic_quote et se préoccuper de toujours protéger soi-même les données qui transitent par la base, TOUJOURS !

En lisant plusieurs articles sur le net, tout le monde s'accorde à dire qu'il vaut mieux effectivement compter sur mysql_real_escape_string qui échappe plus de caractères que les magic_quotes (qui seraient d'ailleurs en voie de disparition ?).

Je suis aussi tombé sur un forum où un utilisateur donne une solution simple et pratique pour éviter certaines injections :

$q="SELECT nom,prenom FROM utilisateurs WHERE id='".[#red](int)[/#]$id."' LIMIT 1";

Ma base ne comprend que les textes des articles, l'accès à l'interface est protégée par un .htaccess (il n'y a pas d'utilisateurs dans la base), je ne pense pas avoir vraiment besoin de la surprotéger, mais autant prendre de bons réflexes, je vais donc utiliser mysql_real_escape_string et stripslashes.

Merci pour vos réponses !
Modifié par Opentype (23 Mar 2007 - 15:29)