Probleme avec la fonction htmlspecialchars

Version imprimable

Bonjour tout le monde!

J'ai un petit soucis de compréhension si vous pouviez m'éclairer ça serait sympa.

Problème 1:

Lorsque j'affiche une variable comportant des balises HTML avec la fonction "htmlspecialchars" ou "htmlentities" celles ci ne sont pas interprété comme le veut la fonction mais par contre les caractères HTML ne sont pas remplacés par des entités HTML comme il est stipulé dans la doc.

"&" (et commercial) devient "&amp
""" (guillemets doubles) devient """ lorsque ENT_NOQUOTES n'est pas utilisée.
"'" (guillemet simple) devient ' uniquement lorsque ENT_QUOTES est utilisée.
"<" (inférieur à) devient "<"
">" (supérieur à) devient ">

ex=> au lieu d'avoir ça :
Code:

1 2 3 4 5 <?php $new = htmlspecialchars("<a href='test'>Test</a>", ENT_QUOTES); echo $new; // Résultat:<a href='test'>Test</a> ?>
j'ai ça :
Code:

1 2 3 4 5 <?php $new = htmlspecialchars("<a href='test'>Test</a>", ENT_QUOTES); echo $new; // Résultat:<a href='test'>Test</a> ?>
Certes les balises ne sont pas interpretées mais j'aimerais savoir pourquoi elles ne sont pas remplacé par des entités ( et c'est pareille pour "htmlentities"). Le seul moyen d'avoir un code ou les balises HTML sont remplacées par des entités est de répéter l'opération 2 fois comme ceci :
Code:

1 2 3 4 5 6 7 8 <?php $orig = 'J\'ai "sorti" le chien tout à l\'heure'; $a = htmlentities(htmlentities($orig)); // J'ai "sorti" le chien tout à l'heure $b = htmlentities(htmlspecialchars($orig)); // J'ai "sorti" le chien tout à l'heure $c= htmlspecialchars(htmlentities($orig)); // J'ai "sorti" le chien tout à l'heure $c= htmlspecialchars(htmlspecialchars($orig)); // J'ai "sorti" le chien tout à l'heure ?>
Problème 2:

La fonction "mysql_real_escape_string" est utilisé lors de l'insertion de données dans la base de donnée et permet d'éviter les injections SQL en "échappant" les caractères spéciaux comme " ou ' en mettant un antislash avant chaque caractère.
La fonction "stripslash" est utilisé a l'affichage et permet de supprimer les antislashs d'une chaîne.
En résumé selon moi quand on utilise la fonction "mysql_real_escape_string" pour l'insertion dans une base de donnée on utilise forcement la fonction "stripslash" pour l'affichage donc je ne comprends pas le code suivant si jamais il s'avère juste :
Code:

1 2 3 4 <?php $username=mysql_real_escape_string(stripslashes($_POST['username'])); ?>
On ajoute des antislash avec "mysql_real_escape_string" et on les retires aussi sec avec "stripslashes" ? Cela ne revient-il pas a faire ceci:
Code:

1 2 3 4 <?php $username= $_POST['username']; ?>
et petite dernière question.. il est dit qu'on doit simplement utiliser "mysql_real_escape_string" pour les données qui doivent être inséré dans la base de donnée et non "htmlspecialchars" ou "htmlentities" qui servent uniquement à l'affichage, ce n 'est pas dangereux de laisser s'insérer des balises HTML,JavaScript ou autre dans la base de donnée sachant que "mysql_real_escape_string" ajoute unqiuement un anti-slash aux caractères suivants : NULL, \x00, \n, \r, \, ', "

voilou voilou si une âme charitable pouvait m'aider ça serait super sympa!! :)

Merci d'avance!

26/04/2012, 20h56
ericd69

salut,

non sinon comment fonctionnerait les sites comme celui là où tu passes ton temps à mettre du code dans des zone de texte... :mouarf:

le seul risque d'injection est lors de l'interprétation des requête si la syntaxe le permet... et pour que ce la puisse arriver c'est l'utilisation des ' et " qui compte au niveau du parseur mysql et php...

après pour l'échappement tu peux avoir plusieurs approches tout dépend quel parseur tu vises (HTML, php, SQL) et ce que tu manipules...

htmlentities sert, par exemple, à neutraliser les balises HTML pour qu'elles ne soient pas génératrices d'élément(s) de la page si elles sont lues hors d'une balise dédiée à l'insertion de code (rien à voir avec le SQL tu vois)

d'autres fonctions éliminent carrément les expressions liées au langage

une façon, plus efficace, je pense, c'est de replacer les caractères " ou ' par les caractères plus typographiques qui existent dans les charsets de manière à ne plus avoir à refaire l'échappement/dé-échappement de ceux-ci... cette technique nécessite d'appliquer la fonction de conversion maison à toute entrée texte que tu voudras chercher dans le texte en BD...

il faut se méfier avec l'utilisation des fonctions d'échappement... notamment en fonction des réglages php ou autre... elles peuvent être automatiques dans certains échanges... il faut donc s'assurer du comportement du serveur, sous peine d'avoir des \ qui apparaissent ou ne disparaissent pas...

ps: tu t'es plantée dans un de tes 2 exemple avec htmlentities sur la constante de configuration de la fonction

voilà j'espère que ça t'éclaire un peu
26/04/2012, 21h07
RunCodePhp
Salut

On va essayer d'apporter quelques précisions.

Il faut commencer par le début, c'est à dire par la directive (php.ini) magic_quote_gpc qui elle peut être activé (On) ou désactivée (Off) car beaucoup de confusions viennent de là, ne serait-ce qu'historiquement.

A savoir que cette directive doit être désactivée de nos jours (très largement conseillé) car à l'époque elle avait été créé et donnait à tord (c'était une erreur) l'impression de sécuriser les données (GET, POST et COOKIES) en les échappant toutes lorsqu'elle était activée.

Ce point est important à prendre en compte car tout en dépend selon comment cette directive est configurée.

Donc plus d'échappement sur ces données systématiquement.
De ce fait c'est à soit même de le faire uniquement sur les données qui le demande et aussi uniquement lorsque cela est nécessaire et encore avec la fonction prévue pour si elle existe.

Concernant la base de donnée, les données doivent être protégées, mais pas seulement pour l'insertion, mais pour toutes les données exploitées dans tous les types de requêtes (SELECT, INSERT INTO, UPDATE et DELETE).

Si on utilise les fonction comme mysql_* (mysql query par exemple) toutes les données exploitées devront être protégées avec mysql_real_escape_string().
Cette fonction est la fonction prévue/dédiée à cela.

Par conséquent, il n'y a pas lieu d'appliquer de striplashes() sur ces données.
(A condition bien sûr que cette directive magic_quote_gpc soit bien désactivée)

Pour ce qui est de htmlentities() ou htmlspecialchars(), ces fonctions sont faite pour convertir les données en entités HTML (tout ou en partie selon la fonction et des paramètres).

Ces fonctions ne sont théoriquement pas faites pour des données en base de données, mais essentiellement pour les afficher dans un document HTML.

Code:

$new = htmlspecialchars("<a href='test'>Test</a>", ENT_QUOTES);

Ce code est alors incorrecte dans la majeur partie.
En général on fera ainsi :

Code:

$new = '<a href="test.php">'.htmlspecialchars('Test', ENT_QUOTES).'</a>';

Encore que, vu que le contenu (Test) est mis "en dur", et donc ne comporte aucun risque ni pour la sécurité ni de conflit entre les quotes et balise, appliquer la fonction devient inutile.

Admettons ce cas suivant maintenant :
Code:

1 2 3 4 <?php $test = 'Un contenu <conflictuel> ...'; echo '<a href="test.php">'.$test.'</a>'; ?>
Cette fois, la chaine dans $test contient quelque chose qui peu dérouter un navigateur car sela ressemble comme 2 goutes d'eau à une balise HTML, même si cette balise n'existe pas.

A savoir que bien souvent on ne sait pas ce que contient une variable, car son contenu peu à l'origine venir d'une donnée en POST, GET, COOKIE, ou de la Bdd.
Donc appliquer la fonction htmlspecialchars() devient alors nécessaire, et pas seulement pour une question de sécurité mais juste pour éviter des conflits.
On fera alors :
Code:

1 2 $test = 'Un contenu <conflictuel> ...'; echo '<a href="test.php">'.htmlspecialchars($test, ENT_QUOTES).'</a>';
En somme, il ne faut pas appliquer cette fonction à notre code HTML, mais aux données (dynamiques) que l'on rajoute à ce code HTML qui elles présentent des risques (sécurité et conflit).

Un cas qu'on peu considérer comme particulier, c'est celui de ce forum, c'est à dire du contenu avec du code (HTML, Php, etc ...), extrêmement risqué à plein de niveau.
Si on est dans ce cas là, alors il faut appliquer la fonction htmlentities().
Mais encore une fois, à appliquer uniquement sur ces données là et pas notre propre code HTML.

Faut juste ne pas confondre les données (GET, POST, base données, etc ...) et notre propre code HTML, Css, JS, etc ...

Il ne faut pas appliquer ces fonctions sur tout comme ça, sinon c'est inévitablement l'embrouille. ;)

J'espère ne pas avoir créer d'embrouille cependant. ;)

Merci pour vos réponse!:ccool:

Citation:

non sinon comment fonctionnerait les sites comme celui là où tu passes ton temps à mettre du code dans des zone de texte...

Avec le bbcode non ? ici je ne peux pas mettre en gras en faisant mais avec lebbcode qu'on me propose en l'occurrence ici pour mettre en gras [\B][/B].

Citation:

htmlentities sert, par exemple, à neutraliser les balises HTML pour qu'elles ne soient pas génératrices d'élément(s) de la page si elles sont lues hors d'une balise dédiée à l'insertion de code (rien à voir avec le SQL tu vois)

D'accord mais que se soit avec htmlentities ou htmlspecialchars quand je récupère se qu'a tapé l'utilisateur via un $_GET ou un $_POST pour ensuite le réafficher,à l'affichage le contenu doit être remplacé par des entités :
"&" (et commercial) devient "&amp
""" (guillemets doubles) devient """ lorsque ENT_NOQUOTES n'est pas utilisée.
"'" (guillemet simple) devient ' uniquement lorsque ENT_QUOTES est utilisée.
"<" (inférieur à) devient "<"
">" (supérieur à) devient ">

et pourtant ce n'est pas le cas!
Je reprends un meilleur exemple:mrgreen:
si dans un système de billet un utilisateur écrit dans la zone de texte coucou
Dans la base de donnée ça sera affiché exactement pareil mais à l'affichage je devrais voir grâce à htmlentities ou a htmlspecialchars: coucou
et pourtant je reçois coucou donc la balise html n'est pas interprété(donc ce n'est pas grave en soit) mais le contenu n'est pas remplacé par des entités comme marqué dans la bible du php
est ce normal ?

Citation:

ps: tu t'es plantée dans un de tes 2 exemple avec htmlentities sur la constante de configuration de la fonction

Ui j' ai pas réussi a l'éditer :cry: fichu copier coller!

Citation:

Il faut commencer par le début, c'est à dire par la directive (php.ini) magic_quote_gpc qui elle peut être activé (On) ou désactivée (Off) car beaucoup de confusions viennent de là, ne serait-ce qu'historiquement.

A savoir que cette directive doit être désactivée de nos jours (très largement conseillé) car à l'époque elle avait été créé et donnait à tord (c'était une erreur) l'impression de sécuriser les données (GET, POST et COOKIES) en les échappant toutes lorsqu'elle était activée.

Ce point est important à prendre en compte car tout en dépend selon comment cette directive est configurée.

ui biensur je ne l'ai pas préciser mais la fonction magic_quote_gpc est désactivé comme conseillé!

Citation:

Concernant la base de donnée, les données doivent être protégées, mais pas seulement pour l'insertion, mais pour toutes les données exploitées dans tous les types de requêtes (SELECT, INSERT INTO, UPDATE et DELETE).

ui j'utilise mysql_real_escape_string() que se soit sur INSERT INTO, UPDATE mais j'avoue ne pas savoir pourquoi l'utiliser sur SELECT car on utilise des données qui ont déja été sécurisé lors de l'insertion dans la table et pareil pour DELETE surtout que pour SELECT comme pour le reste j'utilise des requetes preparé (je ne sais pas si c'est plus sécurisé ou pas mais j'aimerais bien un exemple avec SELECT protégé avec mysql_real_escape_string()) :
Code:

1 2 3 $req = $bdd->prepare('SELECT id, titre, contenu, DATE_FORMAT(date_creation, \'%d/%m/%Y à*%Hh%imin%ss\') AS date_creation_fr FROM billets WHERE id = :billet'); $req->bindValue('billet', intval($_GET['billet']), PDO::PARAM_INT); $req->execute();
Citation:

Par conséquent, il n'y a pas lieu d'appliquer de striplashes() sur ces données.
(A condition bien sûr que cette directive magic_quote_gpc soit bien désactivée)

voila c 'est ça je ne comprends pas >< j' avais vu l'exemple ci-dessous sur un autre site quand magic quote était activé même si ce n'est pas mon cas:
Code:

1 2 3 4 5 On ajoute des antislash avec mysql_real_escape_string et on les retires avec stripslashes <?php $username=mysql_real_escape_string(stripslashes($_POST['username'])); ?>
Si magic_quote_gpc est activé il mettra automatiquement des anti-slash devant les guillemets simple ou double si j'ai bien compris et mysql_real_escape_string lui aussi va échapper les caractères spéciaux comme " ou ' en mettant un antislash avant chaque caractères et stripslash supprime les antislashs d'une chaîne, c'est ça que je ne comprends pas: magic quote + mysql_real_escape_string donc les caracteres speciaux seront échappé 2fois et on enlève un échappement sur les 2 en utilisant stripslash donc en gros pour les personnes qui ont magic quote activé autant rien mettre nan vu que magic quote est déja activé et fait le boulot de mysql_real_escape_string (même si c'est pas conseillé, juste pour info)?

Citation:

Pour ce qui est de htmlentities() ou htmlspecialchars(), ces fonctions sont faite pour convertir les données en entités HTML (tout ou en partie selon la fonction et des paramètres).

Ces fonctions ne sont théoriquement pas faites pour des données en base de données, mais essentiellement pour les afficher dans un document HTML.

ui voila mais moi ils convertissent pas en entités :p comme je les dis en haut de mon message même si ils n'interprètent pas la balise html.

Citation:

$new = htmlspecialchars("<a href='test'>Test</a>", ENT_QUOTES);

Ce code est alors incorrecte dans la majeur partie.
En général on fera ainsi :
Code :
Sélectionner tout - Visualiser dans une fenêtre à part

$new = '<a href="test.php">'.htmlspecialchars('Test', ENT_QUOTES).'</a>';

Encore que, vu que le contenu (Test) est mis "en dur", et donc ne comporte aucun risque ni pour la sécurité ni de conflit entre les quotes et balise, appliquer la fonction devient inutile.

Hé oh j'ai pris ce code dans la bible du php il doit être bon quand même ><
Je ne comprends pas:

Citation:

vu que le contenu (Test) est mis "en dur", et donc ne comporte aucun risque ni pour la sécurité ni de conflit entre les quotes et balise, appliquer la fonction devient inutile new = '<a href="test.php">'.htmlspecialchars('Test', ENT_QUOTES).'</a>';

$test(t'as pas oublié le $ ?) étant une variable que peut modifier l'utilisateur ce n'est pas risqué vu qu'il peut écrire des balises html ?

Citation:

Un cas qu'on peu considérer comme particulier, c'est celui de ce forum, c'est à dire du contenu avec du code (HTML, Php, etc ...), extrêmement risqué à plein de niveau.
Si on est dans ce cas là, alors il faut appliquer la fonction htmlentities().
Mais encore une fois, à appliquer uniquement sur ces données là et pas notre propre code HTML.

et pourquoi pas htmlspecialchars pour les forum il fait le même boulot que htmlentities,htmlentities convertit même en entités toutes les lettres avec accents :( pas très pratique pour un forum ?!

voilou encore un grand merci à vous pour vos reponses :ccool:

27/04/2012, 07h51
RunCodePhp

Citation:

mais j'avoue ne pas savoir pourquoi l'utiliser sur SELECT car on utilise des données qui ont déja été sécurisé lors de l'insertion dans la table et pareil pour DELETE surtout que pour SELECT comme pour le reste j'utilise des requetes preparé (je ne sais pas si c'est plus sécurisé ou pas mais j'aimerais bien un exemple avec SELECT protégé avec mysql_real_escape_string())

Je ne l'avais pas évoqué pour évité l'amalgame, puis le sujet est vaste si on veut faire tout le tour.

Donc surtout pas d'amalgame.
La fonction mysql_real_escape_string() doit être utilisée si on utilise les fonctions mysql (mysql_query, etc ...).

Mais si on utilise PDO, ou MySQLi, qui est une toute autre façon d'exploiter sa Bdd en Php (il n'y pas de comparaison possible) car ces 2 derniers ont leur propre extension (librairie dans le core de Php) on doit cette fois faire des requêtes préparées, c'est Php qui s'occupe à sécuriser les données manipulées.

Admettons cet exemple avec PDO sans requête préparée :

Code:

$req = $bdd->query("SELECT id FROM billets WHERE titre = '".$_GET['titre']."'");

Et ici malgré utiliser PDO, le fait de ne pas faire de requête préparée on s'expose à une injection SQL, cette donnée $_GET['titre'] n'est pas protégée.

Et si on effectue cette même requête avec cette fois les fonctions mysql_* (avec mysq_query), et bien on s'exposera tout autant à une injection SQL.
Vu que les fonctions mysql_* ne propose pas nativement de faire des requêtes préparées, la méthode à appliquer est de faire un mysql_real_escape_string() sur $_GET['titre'].

Une requête SELECT est donc tout autant risquée que toutes les autres types de requêtes, peut être même plus car une injection SQL dans une requête qui effectue une identification pourrait permettre à tout hacker de s'identifier comme Admin (si le site le propose et n'est pas suffisamment sécurisé).

Citation:

Si magic_quote_gpc est activé il mettra automatiquement des anti-slash

Pas d'amalgame là encore.
Si dans son propre projet on marque sur ces tablettes (cahier des charges) que quelque soit là où sera hébergé notre site (distant, en local) on désactivera cette directive magic_quotes_gpc, c'est une bêtise de se prendre la tête à supprimer les antislashes.
En tout logique il est inutile de faire des choses inutiles.

Par contre, il ne faut pas confondre la création d'un projet Open Source (genre WordPress) ou on ne sait pas dans quel contexte/environnement sera installé le site.
Donc le cas est radicalement pas le même.
Ces CMS prévoient souvent de vérifier la valeur de cette directive pour régler ce problème d'antislashes selon le cas.
Ceci c'est pour offrir une compatibilité.

Donc si on revient à notre cas, on a largement de quoi éviter toutes ses sur-couches de codes de compatibilités (pas seulement pour les magic_quotes_gpc), on peu s'imposer un environnement quelque peu cadré.

Citation:

et pourtant ce n'est pas le cas!

Dans la base de donnée ça sera affiché exactement pareil mais à l'affichage je devrais voir grâce à htmlentities ou a htmlspecialchars: coucou
donc la balise html n'est pas interprété

Si justement, elle est interprétée sinon tu ne verrais pas ces balises mais des entités.

En appliquant htmlentities() Php va convertir les caractères en entités HTML, donc le navigateur va recevoir ce contenu ainsi.
Pour t'en rendre compte il suffit de faire un clic droit dans la page et observer le code HTML généré.

Ce qu'il faut comprendre c'est qu'en appliquant cette fonction, tu dis à Php et au navigateur d'afficher du code HTML brut, des balises, etc ..., c'est se qui ce fait (on voit les balises).

Si maintenant tu veux que ce code HTML soit interprété en tant que contenu HTML tout comme ton propre code HTML, alors il ne faut pas appliquer cette fonction htmlentities (ou htmlspecialchars), il faut juste afficher la variable telle quelle (son contenu).
Le gros problème c'est que cela est très risqué.

C'est pour cette raison que les éditeurs HTML ou BBCode (comme ce forum) ont été créés et utilisés, l'idée général est d'éviter de tout accepter ce que pourrait saisir un utilisateur mais de cadrer les choses.
Grosso modo, n'est autorisé que ce que l'éditeur permet.
Cependant, vu que le contexte est particulier et est risqué, en général une sur-couche de code est effectuée pour éventuellement filtrer ces données juste avant de les enregistrer dans la Bdd (genre supprimer un éventuel contenu Javascript, etc ...).

Ce que fait donc ce forum c'est qu'il permet de faire une certaine mise en forme (mise en gras, italique, etc ...), de créer un lien, etc ... tout cela via un code BBCode.
A l'affichage il ne sera pas appliqué de fonctions (ni htmlentities ni htmlspecialchars), le BBCode sera juste converti en code HTML (tout comme la structure du site).
Pour tout le reste (ce qu'on saisie et non converti en html) une de ces fonction sera appliquée.
-> Ici je saisie une balise : elle est convertie en entité HTML
-> Ici je met ceci en gras : Le BBCode "en gras" est converti en html.

D'accord donc on doit l'utiliser comme ca (px conseillé):

Citation:

$req = $bdd->query("SELECT id FROM billets WHERE titre = '".mysql_real_escape_string( $_GET['titre'])."'");

ou comme ca:

Citation:

$req = $bdd->prepare('SELECT id FROM billets WHERE id = :titre');
$req->bindValue('titre',$_GET['titre'], PDO:: PARAM_STR);
$req->execute();

mais ceci ne sert strictement a rien:

Citation:

$req = $bdd->prepare('SELECT id FROM billets WHERE id = :titre');
$req->bindValue('titre',mysql_real_escape_string( $_GET['titre']), PDO:: PARAM_STR);
$req->execute();

c'est bien ça ?

Et c'est donc pareil pour DELETE ? :roll:

Citation:

Si magic_quote_gpc est activé il mettra automatiquement des anti-slash
Pas d'amalgame là encore.
Si dans son propre projet on marque sur ces tablettes (cahier des charges) que quelque soit là où sera hébergé notre site (distant, en local) on désactivera cette directive magic_quotes_gpc, c'est une bêtise de se prendre la tête à supprimer les antislashes.
En tout logique il est inutile de faire des choses inutiles.

Par contre, il ne faut pas confondre la création d'un projet Open Source (genre WordPress) ou on ne sait pas dans quel contexte/environnement sera installé le site.
Donc le cas est radicalement pas le même.
Ces CMS prévoient souvent de vérifier la valeur de cette directive pour régler ce problème d'antislashes selon le cas.
Ceci c'est pour offrir une compatibilité.

Donc si on revient à notre cas, on a largement de quoi éviter toutes ses sur-couches de codes de compatibilités (pas seulement pour les magic_quotes_gpc), on peu s'imposer un environnement quelque peu cadré.

Ui biensur il est désactivé chez moi mais c était par simple curiosité je ne comprends pas sachant que mysql_real_escape_string fais le même boulot que les guillemet magique et qu'on retire un échappement apres avec striplslash; que signifie cette phrase en dessous ? :
Code:

1 2 3 <?php $username=mysql_real_escape_string(stripslashes($_POST['username'])); ?>
Je met un échappement aux caractères spéciaux et je le retire direct apres :x comme dans mon 1er post pour moi la phrase au-dessus revient à faire ça:
Code:

1 2 3 <?php $username=$_POST['username']; ?>
Citation:

Si justement, elle est interprétée sinon tu ne verrais pas ces balises mais des entités.

En appliquant htmlentities() Php va convertir les caractères en entités HTML, donc le navigateur va recevoir ce contenu ainsi.
Pour t'en rendre compte il suffit de faire un clic droit dans la page et observer le code HTML généré.

Ce qu'il faut comprendre c'est qu'en appliquant cette fonction, tu dis à Php et au navigateur d'afficher du code HTML brut, des balises, etc ..., c'est se qui ce fait (on voit les balises).

Si maintenant tu veux que ce code HTML soit interprété en tant que contenu HTML tout comme ton propre code HTML, alors il ne faut pas appliquer cette fonction htmlentities (ou htmlspecialchars), il faut juste afficher la variable telle quelle (son contenu).
Le gros problème c'est que cela est très risqué.

Quand je dis que la balise n'est pas interpreté c'est que la balise ne fait pas son boulot et heuresement par exemple coucou à l'affichage donnera coucou et non coucou!
Mais se qui m'inquiète c'est que dans la doc c'est marqué que toutes les balises sont transformé en entité hors la se n 'est pas le cas tu serais d'ou ça vient ? bien sur le code généré est le même coucou et pour avoir c'est fameuse entité je dois comme je l'ai marqué dans le 1er poste repéter l'opération plusieurs fois:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 <?php $orig = 'J\'ai "sorti" le chien tout à l\'heure'; $a = htmlentities(htmlentities($orig)); $b = htmlentities(htmlspecialchars($orig)); $c= htmlspecialchars(htmlentities($orig)); $d= htmlspecialchars(htmlspecialchars($orig)); $e= htmlspecialchars($orig); echo $a.' '; // J'ai "sorti" le chien tout &agrave; l'heure echo $b.' '; // J'ai "sorti" le chien tout à l'heure echo $c.' '; // J'ai "sorti" le chien tout &agrave; l'heure echo $d.' '; // J'ai "sorti" le chien tout à l'heure echo $e; //J'ai "sorti" le chien tout à l'heure ?>
La variable $e devrait me donner le résultat de la variable $b et $d mais ce n'est pas le cas, obligé de répéter l'opération 2fois de suite pour avoir les fameuses entitées, ou bien de l'enregistrer dans la base de donnée avec htmlspecialchars ou htmlentities + mysql_real_escape_string() et à l'affichage quand j'utilise htmlspecialchars ou htmlentities une seule fois, la j'ai les fameuses entités! ><

27/04/2012, 13h50
RunCodePhp
Citation:

D'accord donc on doit l'utiliser comme ca (px conseillé):
Citation:
$req = $bdd->query("SELECT id FROM billets WHERE titre = '".mysql_real_escape_string( $_GET['titre'])."'");

Absolument pas, surtout pas :cry:

Il faut être clair :
Php offre 3 façons différentes pour interroger une Bdd MySQL, par conséquent il ne faut pas mélanger ces 3 façons.
On fait le choix d'1 des 3 et on s'y tient.

Les 3 façons sont :
1/ toutes les fonctions mysql_* (mysql_query, mysql_real_escape_string, mysql_fecth_assoc, etc ...)
2/ MySQLi
3/ PDO

Donc si on fait le choix d'utiliser PDO, alors il faut oublier toutes ces fonctions mysql_* y compris MySQLi.
On utilise uniquement les fonctionnalités de PDO :
PDO::query(...)
PDO::prepare(...)
PDO::fetch(...)
... etc ...

Pas d'amalgame !!!
Je ne vois pas comment expliquer ça autrement.

Citation:

Ui biensur il est désactivé chez moi mais c était par simple curiosité je ne comprends pas sachant que mysql_real_escape_string fais le même boulot que les guillemet magique et qu'on retire un échappement apres avec striplslash; que signifie cette phrase en dessous ? :

Si tu utilises PDO, alors la 1ère chose à faire c'est d'oublier cette fonction mysql_real_escape_string(), tu la mets définitivement au placard, y compris toutes les autres fonctions mysql_truc_muche().

Là encore une fois pas d'amalgame.
Si de ton coté tu as prévu de désactiver cette directive magic_quotes_gpc, ne passons pas part 4 chemins : il n'y a pas à faire de stripslashes
Point, et l'affaire est réglée. ;)

Cette fonction stripslaches n'a de sens QUE si cette directive est activé et qu'on ne peu pas la désactivée, par conséquent on va retirer les antislashes créés à tord.
On revient alors à une situation normale.
Citation:
Je met un échappement aux caractères spéciaux et je le retire direct apres comme dans mon 1er post pour moi la phrase au-dessus revient à faire ça:

Code:

1 2 3 <?php $username=$_POST['username']; ?>
Oui, et c'est très bien ainsi. ;)

Ne perds pas de vu que cette donnée $username peut être exploitée dans 2 contextes différents.
1/ -> être exploitée dans une requête SQL (quelque soit le type de requête)
2/ -> et aussi être affichée dans la page HTML

1/ Et bien lorsqu'elle sera exploitée dans la Bdd, cette donnée étant risquée et bien :
a/ -> Avec PDO on utilisera une requête préparée avec PDO pour se protéger.
b/ -> (j'espère ne pas créer d'amalgame) Avec les fonctions mysql_* on utilisera mysql_real_escape_string() pour se protéger.
c/-> Avec MySQLi on fera une requête préparée pour se protéger.
(comme vu plus haut, on utilisera 1 seule façon de faire : soit a soit b soit c)

2/ Pour afficher dans la page HTML on utilisera par exemple la fonction htmlspecialchars().
(aucune fonction d'échappement n'est utile ni même de fonctions pour supprimer des échappements)

Si en affichant une donnée dans la partie HTML on voit des antislahes de trop c'est qu'en amont il y a eu une fonction qui les a rajoutés de trop.
Faut réparer cette erreur car c'est une erreur.
Il n'y a pas à faire de stripslashes dans une partie HTML.
(je parts bien sûr dans le cas ou le magic_quotes_gpc est désactivé).

La encore je ne vois pas comment expliquer ça autrement.

Citation:

Mais se qui m'inquiète c'est que dans la doc c'est marqué que toutes les balises sont transformé en entité hors la se n 'est pas le cas tu serais d'ou ça vient ? bien sur le code généré est le même coucou et pour avoir c'est fameuse entité je dois comme je l'ai marqué dans le 1er poste repéter l'opération plusieurs fois:

La doc dit vrai pourtant mais peut être tu ne le perçois pas.
Pour t'en rendre compte il te faut voir le code que le navigateur interpréte, et pour cela il suffit de faire un clic droit dans la page HTML et -> "code source de la page".

Quand on applique cette fonction il y a réellement une différence entre le code généré et le résultat visuel, ce n'est pas la même chose.

Dans le code source il y a des entités, et le but de faire cela n'est justement pas de voir (de ces yeux) des entités, mais pour que le navigateur interprète ces entités pour nous offrir le résultat visuel attendu : de voir des balises (si le contenu contient des balises).

Moi ce qui m'intrigue dans ta démarche c'est pourquoi veux tu visualiser des entités ?
Dans la majorité des cas on n'en a rien à faire de voir des entités HTML.
Ca intéresse qui de voir des entités ?
27/04/2012, 17h09
Royade
Citation:

Il faut être clair :
Php offre 3 façons différentes pour interroger une Bdd MySQL, par conséquent il ne faut pas mélanger ces 3 façons.
On fait le choix d'1 des 3 et on s'y tient.

Les 3 façons sont :
1/ toutes les fonctions mysql_* (mysql_query, mysql_real_escape_string, mysql_fecth_assoc, etc ...)
2/ MySQLi
3/ PDO

Donc si on fait le choix d'utiliser PDO, alors il faut oublier toutes ces fonctions mysql_* y compris MySQLi.
On utilise uniquement les fonctionnalités de PDO :
PDO::query(...)
PDO::prepare(...)
PDO::fetch(...)
... etc ...

Pas d'amalgame !!!
Je ne vois pas comment expliquer ça autrement.

Merci >< en effet je mélangeais les fonctions mysql_* avec la méthode
PDO . En faite la méthode PDO échappe automatiquement avec les requêtes préparées il n'y a pas besoin de rajouter de fontcion mysql_* qui n'ont rien a faire la dedans. En faite moi je rajoutais mysql_real_escape_string dans mes requêtes préparées et du coup à l'affichage je me retrouvais avec des anti-slash qui n'avaient rien à faire la donc je me sentais obligé d'utiliser stripslashes pour les enlever mais effectivement le problème était en amont!

Citation:

Là encore une fois pas d'amalgame.
Si de ton coté tu as prévu de désactiver cette directive magic_quotes_gpc, ne passons pas part 4 chemins : il n'y a pas à faire de stripslashes
Point, et l'affaire est réglée.

ui voila j'ai compris :ccool: mais qu'on prenne une des trois méthodes:
1/ toutes les fonctions mysql_*
2/ MySQLi
3/ PDO

par exemple avec mysql_* si les magic_quotes sont activés on fait mysql_real_escape_string(stripslashes(donnees))
mais si on utilise la methode PDO?
Pourquoi tester si magic_quotes_gpc est activé? pour la portabilité du programme? ne vaut mieux pas mettre une fonction qui désactive d'entré magic_quotes vu que celui ci est obsolete?

Citation:

La doc dit vrai pourtant mais peut être tu ne le perçois pas.
Pour t'en rendre compte il te faut voir le code que le navigateur interpréte, et pour cela il suffit de faire un clic droit dans la page HTML et -> "code source de la page".

Quand on applique cette fonction il y a réellement une différence entre le code généré et le résultat visuel, ce n'est pas la même chose.

exacte le code généré n'est pas le même que le résultat visuel!

en effet ce code la:
Code:

1 2 3 4 5 6 <?php $orig = 'J\'ai "sorti" le chien tout à l\'heure'; $e= htmlspecialchars($orig); echo $e; //J'ai "sorti" le chien tout à l'heure ?>
me donne visuellement la phrase à l'identique sur la page html sauf que chien n'est pas en gras donc la balise n'est pas interpreté:
J'ai "sorti" le chien tout à l'heure
quand je fais clic droit le code généré est celui-ci:
J'ai "sorti" le chien tout à l'heure

Citation:

Dans le code source il y a des entités, et le but de faire cela n'est justement pas de voir (de ces yeux) des entités, mais pour que le navigateur interprète ces entités pour nous offrir le résultat visuel attendu : de voir des balises (si le contenu contient des balises).

Moi ce qui m'intrigue dans ta démarche c'est pourquoi veux tu visualiser des entités ?
Dans la majorité des cas on n'en a rien à faire de voir des entités HTML.
Ca intéresse qui de voir des entités ?

ui voila mais quand j'ai lu ça sur la doc je pensais que j'allais voir visuellement les entitées c 'est pour ça... ça m'intriguais ^^ la finalité n'étant pas de voir les entitées en elles même mais c'était de savoir pourquoi je n'avais pas le même resultat que dans la doc , je suis rassuré! :mouarf:

Merci pour les réponses précises
27/04/2012, 21h25
RunCodePhp
Citation:

ui voila j'ai compris mais qu'on prenne une des trois méthodes:
1/ toutes les fonctions mysql_*
2/ MySQLi
3/ PDO

Très bien, c'est essentiel de le comprendre, de ne pas faire de confusions. ;)

Je rajouterais que les fonctions mysql_* sont obsolètes car vouées à être supprimés du core de Php.
Quand, je ne saurait le dire.
A l'heure actuelle cette extension n'évolue plus.

Donc pour toutes personne qui développe un projet actuellement, faire le choix d'utiliser PDO ou MySQLi serait un meilleurs choix.

Citation:

par exemple avec mysql_* si les magic_quotes sont activés on fait mysql_real_escape_string(stripslashes(donnees))

Dans ce cadre là, oui, il faut faire ainsi.

Sans vouloir créer d'amalgame, il faut tout de même apporter une précision qui à mon sens en vaut la peine.
Cette directive magic_quotes_gpc si elle est activé va échapper d'office toutes les données GET, POST et COOKIE (d'où son nom : GPC).
Ce n'est pas un détail et c'est cela qui cause de sacrées problème car le fond du problème c'est que toutes les données ne demandent pas à être échappées.

Si on a pas l'opportunité de la désactiver alors le plus simple est de prévoir une routine de code (un truc automatisé) très tôt dans son code et cela systématique pour supprimer tous ces échappements de trop sur toutes ces données GET POST et COOKIE (stripslashes).
Histoire de revenir à une situation normale (comme si elle était désactivée).
C'est largement plus simple.

Si on procède ainsi, alors dans son programme que je qualifierait de normal, on va coder normalement.
Si je reprend ton exemple ci-dessus où on utilise les fonctions mysql_*, il suffira juste faire un mysql_real_escape_string() sur la donnée (vu que notre routine de code automatique aura déjà supprimé les échappement).

Citation:

mais si on utilise la methode PDO?

Il faut faire des requêtes préparées, c'est prévu pour ça.
Ceci :
Code:

1 2 3 4 5 6 $calories = 150; $sth = $dbh->prepare('SELECT nom FROM fruit WHERE calories = :calories'); $sth->bindValue(':calories', $calories, PDO::PARAM_INT); $sth->execute();
Citation:

Pourquoi tester si magic_quotes_gpc est activé? pour la portabilité du programme? ne vaut mieux pas mettre une fonction qui désactive d'entré magic_quotes vu que celui ci est obsolete?

Oui, tout à fait.
Quand on fait un programme qui doit fonctionner sans imposer certaines valeurs pour certaines directives il n'y a pas d'autres choix que de vérifier ces directives et adapter le code selon le ou les cas.
C'est cela la compatibilité.
Par moment c'est la croix et la bannière, faut être sacrément bon codeur pour le proposer.

A titre personnel je le fait rarement (sinon jamais), je code selon la généralité, ce qui est théoriquement mieux ou conseillé, quitte à modifier le php.ini (ou .htaccess ou ini_set) pour être dans ce cadre là.
C'est largement plus simple.

Donc oui, il vaut mieux 100 fois désactiver cette directive.
Théoriquement tous les hébergeurs offrent cette possibilité là, donc théoriquement on aura pas à faire de sur-couche de code pour ça.
Soit comme le mien ça se fait directement via un panel Admin (une 10ènes de directives peu se gérer ainsi), donc au bout j'ai pas un seul code à faire.
Soit ça se fait dans un .htaccess, soit en Php avec ini_set().
En local on fait se qu'on veut vu qu'on a "la main" sur tout.

Citation:

ui voila mais quand j'ai lu ça sur la doc je pensais que j'allais voir visuellement les entitées c 'est pour ça... ça m'intriguais ^^ la finalité n'étant pas de voir les entitées en elles même mais c'était de savoir pourquoi je n'avais pas le même resultat que dans la doc , je suis rassuré!

En faite la doc est juste, il faut peut être lire entre les lignes, ou ne pas sur-interpréter ce qui est dit.

En fait la doc ne fait pas état de l'interprétation du navigateur, elle donne le résultat réelle, et c'est bien des entités qui est obtenue.

Faut savoir (ou intégrer) que le code généré par Php (des balises HTML par exemple) ne sera pas obligatoirement interprété par un navigateur.
C'est certes le plus courant, mais Php peut être exécuté en ligne de commande, en mode CLI, voir être utilisé uniquement comme serveur, etc ...

Si la doc fait état de tous les cas possibles à chaque fonction, ça peu déboucher sur 1 bouquin par fonction.
Vois tu la difficulté ?

Une doc c'est juste une doc, c'est juste fait pour expliquer quelque chose de précis, sans plus.
Les exemples sont par moment (voire souvent) simplistes, ces code sont souvent à ne pas prendre pour "argent comptant" (si on peu dire).
Faut faire attention à cela. ;)

Voilà voilà. ;)
27/04/2012, 22h11
Royade
Citation:

mais si on utilise la methode PDO?
Il faut faire des requêtes préparées, c'est prévu pour ça.

$calories = 150;
$sth = $dbh->prepare('SELECT nom
FROM fruit
WHERE calories = :calories');
$sth->bindValue(':calories', $calories, PDO::PARAM_INT);
$sth->execute();

ui mais se que je veux dire c'est qu' avec les fonctions mysql_* :si magic_quotes_gpc est activé on fait : mysql_real_escape_string(stripslashes(donnees))
mais si on utilise des requêtes preparées avec PDO on a pas besoin de savoir si magic_quotes_gpc est sur on ou off, cela à peux d'importance ?
Par exemple si on ne px pas desactiver magic_quotes_gpc avec les fonctions mysql_*on fera:
Code:

1 2 3 4 5 6 7 8 <?php function Recupgpc($chaine) { if(get_magic_quotes_gpc()) return stripslashes($chaine); return $chaine; } ?>
mais avec PDO? pas besoin ?
28/04/2012, 03h02
ericd69

c'est indépendant oui...

mais attention, tu as intérêt à bien lire les exemples donnés par les utilisateurs dans la doc car ces fonction engendre un certains nombre de subtilités d'écriture pour les requêtes à cause de leurs formes d'échappement...
28/04/2012, 07h18
RunCodePhp

Citation:

ui mais se que je veux dire c'est qu' avec les fonctions mysql_* :si magic_quotes_gpc est activé on fait : mysql_real_escape_string(stripslashes(donnees))

Pour mysql_* oui, il faut échapper avec la fonction dédiée, et justement, comme il faut le faire avec cette fonction là on supprimera avant les échappements effectués que Php aura fait avec stripslashes du fait que le magic_quotes_gpc est activé.

Citation:

mais si on utilise des requêtes preparées avec PDO on a pas besoin de savoir si magic_quotes_gpc est sur on ou off, cela à peux d'importance ?

Si, il faut supprimer les échappements effectués par Php si le magic_quotes_gpc est activé sinon les données seront échappées.

Je ne sais pas si tu perçois bien ce problème lié à cette directive, mais bien que dans certains cas il faudra échapper des données, dans la plus grande majorité des cas il ne faudra pas le faire.
De plus, comme les échappement effectués par cette directive ne sont pas faits correctement, cela rajoute encore plus l'inutilité d'activer cette directive.
C'est pour ces raisons multiples que cette directive est devenu obsolète.

Par conséquent il est bon de mettre un point final sur cette directive.
Faut juste savoir quelle existe, son impact désastreux si elle est activé.
C'était juste pour cette raison que je l'avais évoqué, juste histoire de comprendre dans les grandes lignes, et non en faire un débat.

Et comme je te l'ai dit, tout hébergeur digne de ce nom offre la possibilité de la désactiver.
Si demain tu tombes sur un hébergeur ne le proposant pas, alors j'estime qu'il faudra mettre de grosse réserve sur la qualité de cet hébergeur.
Personnellement j'y mettrais une croix dessus illico presto et voir ailleurs dans la seconde qui suit.

Bref ... te prends pas la tête sur ce point là. ;)

Même chose pour les fonctions mysql_*, elle sont aussi obsolètes, donc vouées à disparaitre.
Là aussi il n'y a pas à débattre sur quelque chose qui n'en vaut pas la peine.
Utilise PDO par exemple et l'affaire est réglée.

En conclusion, si tu respectes ces 2 points là, les choses sont simples car il y a juste à faire des requêtes préparées quand une requête SQL contient des paramètres.
C'est tout, on ne peut pas faire plus simple.
09/05/2012, 00h34
Royade

Citation:

C'était juste pour cette raison que je l'avais évoqué, juste histoire de comprendre dans les grandes lignes, et non en faire un débat.

Et comme je te l'ai dit, tout hébergeur digne de ce nom offre la possibilité de la désactiver.
Si demain tu tombes sur un hébergeur ne le proposant pas, alors j'estime qu'il faudra mettre de grosse réserve sur la qualité de cet hébergeur.
Personnellement j'y mettrais une croix dessus illico presto et voir ailleurs dans la seconde qui suit.

Bref ... te prends pas la tête sur ce point là.

Citation:

Même chose pour les fonctions mysql_*, elle sont aussi obsolètes, donc vouées à disparaitre.
Là aussi il n'y a pas à débattre sur quelque chose qui n'en vaut pas la peine.
Utilise PDO par exemple et l'affaire est réglée.

C'était pour agrandir mes connaissances :p Merci pour toutes vos réponses!
ps:désolé pour avoir mis du temps a répondre