Gérer les apostrophes entrées par l’usager dans un formulaire

Avez-vous déjà affiché à l'écran les données d'un formulaire Web et constaté que WordPress y avait ajouté des barres obliques inverses ? D'où vient ce comportement ? Pourquoi a-t-il été mis en place ? Et comment régler ce problème ?

▼Publicité

Un peu d'histoire

Avant PHP 5.4, PHP offrait un mécanisme permettant de protéger contre certaines injections SQL les valeurs reçues par HTTP (variables $_GET, $_POST et $_COOKIE) : les guillemets magiques (magic quotes). Ainsi, lorsqu'un internaute entrait la valeur « j'arrive » dans un formulaire, les guillemets magiques, s'ils étaient activés, le transformaient automatiquement en « j\'arrive ». Autrement dit, avec les guillemets magiques, PHP appliquait la fonction addslashes() et donc ajoutait une barre oblique inverse devant les apostrophes ( ' ), guillemets ( " ), barres obliques inverses ( \ ) et devant le caractère NUL pour chacune des valeurs contenues dans $_GET, $_POST et $_COOKIE. Certaines injections SQL étaient automatiquement annulées grâce aux guillemets magiques.

Il était possible d'activer ou non les guillemets magiques à l'aide d'une configuration dans le fichier php.ini : magic_quotes_gpc = On ou Off. Les guillemets magiques étaient donc contrôlés côté serveur. Dans un programme PHP, il était possible de vérifier s'ils étaient activés ou non à l'aide de la fonction get_magic_quotes_gpc().

Aujourd'hui, il n'est plus possible d'utiliser les guillemets magiques. Ils sont donc toujours considérés comme désactivés. Pourquoi PHP a-t-il supprimé les guillemets magiques ? Parce que dans plusieurs cas, les variables $_GET, $_POST et $_COOKIE n'étaient pas utilisées dans des requêtes SQL et donc n'avaient pas besoin de se voir appliquer un addslashes(). De plus, lorsque ces informations doivent être utilisées dans une requête, l'utilisation de requêtes préparées est plus efficace pour se protéger contre les injections SQL.

La réalité avec WordPress

Avec WordPress, le fonctionnement est différent. WordPress fait en sorte que peu importe que les guillemets magiques soient activés ou non côté serveur, les valeurs de $_GET, $_POST, $_COOKIE et même $_SERVER, qui n'était pas visé par les guillemets magiques, se voient automatiquement appliquer un addslashes(). Cette fonctionnalité est programmée dans la fonction wp_magic_quotes() dans le fichier wp-includes\load.php.

Pourquoi WordPress a-t-il choisi ce comportement alors que PHP l'a aboli ? Simplement pour des raisons de compatibilité.

Pour revenir à notre exemple de formulaire Web, nous sommes certains que les données reçues via $_POST contiennent des barres obliques inverses devant les caractères désignés (', ", \ et NUL). Il faut maintenant s'assurer que les barres obliques inverses ajoutées par wp_magic_quotes() ne soient pas affichées à l'écran. Il est possible d'y arriver en appliquant la fonction PHP stripslashes() aux éléments de $_POST avant de les afficher à l'écran. Mieux encore, la fonction WordPress stripslashes_deep() enlèvera les caractères d'échappement dans chacun des éléments d'un tableau.

Ex :

WordPress (PHP)

$_POST = stripslashes_deep( $_POST );

Attention : l'appel à wp_magic_quotes() a lieu après le chargement des extensions et avant le chargement du thème. Il faut donc être prudent lors du développement d'extensions : il se peut que les guillemets magiques n'aient pas été appliqués sur les valeurs reçues. 

Pour plus d'information

« Function Reference/stripslashes deepFunction Reference/stripslashes deep ». Codex WordPress. http://codex.wordpress.org/Function_Reference/stripslashes_deep

« Getting Rid of Unwanted Backslashes in WordPress Form Input ». Fearless Flyer. http://fearlessflyer.com/getting-rid-of-unwanted-backslashes-in-wordpress-form-input/

« Les magic quotes ou guillemets magiques ». Open Classroom. http://fr.openclassrooms.com/informatique/cours/les-magic-quotes-ou-guillemets-magiques

Merci de partager ! Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInPin on PinterestShare on StumbleUponEmail this to someone
Catégories

5 commentaires

  1. Bonjour Christiane,

    Merci pour cette article ! Je rencontre présentement un problème avec un formulaire pour l’envoi de cartes virtuelles avec une option de prévisualisation de la carte et génial, les apostrophes apparaissent en mode de prévisualisation mais un fois que je fais un retour pour aller éditer dans le formulaire, c’est là que ça cause problème. Dans le champ du (Sujet : L\\\\\’affaire) des barres obliques s’ajoutent. Et ensuite dans le textarea pour le Message le texte va être coupé à l’endroit il rencontre un apostrophe. Très frustrant j’aurai aimé mettre mon site en ligne avant Pâques pour offrir des cartes de souhaits pour l’occasion mais… j’ai frappé un mur. LOL. Si tu pouvais m’aider, j’apprécierais beaucoup. Voici l’url temporaire. http://www.waydego.ca/wp-waydego/

    Mon site est en développement, il me reste juste ça à solutionner pour le mettre officiellement en ligne.
    Wordpress 3.8.3 et le plugin de cartes virtuelles est wp-greet version 4,1

    • Christiane Lagacé

      Bonjour Madeleine,

      Généralement, le problème des barres obliques inverses qui se dédoublent devant un apostrophe est dû à la fonction addslashes() appliquée à une chaîne sur laquelle addslashes() a déjà été appliquée. Inversement, si une chaîne est coupée vis-à-vis un apostrophe, c’est probablement que la chaîne a été lue dans la base de données et que les apostrophes n’avaient pas été échappées avant que la chaîne soit enregistrée dans la base de données (il n’y a pas eu d’ajout de barre oblique inversée). Comme WordPress échappe les apostrophes automatiquement, c’est probablement que la fonction stripslashes() ou stripslashes_deep() a été appliquée alors qu’elle n’aurait pas dû.

      En regardant dans les fichiers de wp-greet, je vois que trois fichiers font appel à addslashes() : wp-greet.php, wpg-func-mail.php et wpg-form.php. Pour stripslashes(), on la retrouve dans wpg-admin-sec,php, wpg-admin.php, wpg-func.php,wpg-func-mail.php et wpg-form.php. Comme ton problème survient dans l’affichage du formulaire, je regarderais du côté de wpg-form.php.

      Voici comment mieux cerner le problème : avec le débogueur de CodeLobster (voir http://christianelagace.com/php/configurer-codelobster-pour-developper-et-deboguer-un-site-web/), placer un point d’arrêt juste avant l’affichage du formulaire. Il faut vérifier si les apostrophes sont échappés ou non au moment où le formulaire reçoit les données à afficher. Tu peux ensuite exécuter les lignes une à une afin de vérifier à quel endroit les barres obliques inversées sont dédoublées. Une fois la ligne problématique ciblée, tu peux enlever l’appel à addslashes() ou encore ajouter un appel à stripslashes(). Et si tu détectes qu’il manque une barre oblique inverse devant un apostrophe avant un enregistrement dans la base de données, tu peux ajouter addslashes() devant la variable en question avant qu’elle soit enregistrée.

      Attention toutefois : puisque tu modifies directement le code d’une extension, prends soin de bien noter tes modifications car elles seront perdues lors d’une mise à jour de l’extension.

      Bonne chance !

      Christiane

  2. Merci beaucoup Christiane,

    J’ai finalement résolu le problème effectivement dans le fichier wpg-form.php en ajoutant stripslashes(esc_attr($_POST[‘xxxxxxxx])); dans les champs concernés. J’ai tellement essayé de choses que ça finit par fonctionner….LOL J’ai communiqué avec le concepteur de l’extension et il me dit qu’il devrait faire une mise à jour prochainement, en attendant, je conserve précieusement mes notes. Le site est maintenant en ligne http//:www.waydego.ca

    Merci aussi pour ton travail, c’est rare de trouver des articles bien étoffé en français concernant wordpress. Bravo !
    Joyeuses Pâques

    Madeleine