Voilà, voilà... Fin de l'aventure...

 

Fermeture de kolossaldrupal.org dans...


Bonjour tout le monde,

Drupal évolue, les versions changent et Kolossaldrupal.org était essentiellement consacré à la version 6 de Drupal.

Autant dire que les infos présentées ici commencent à dater...

Faute de temps, je ne peux plus garder le site Kolossaldrupal à jour...

Je vous aurais bien proposé de reprendre le flambeau mais... c'est tellement simple de nos jours de se faire son propre site à soi...Pourquoi s'embêter alors ? :-)

Ce site restera donc en l'état, tel qu'il était en 2011...

Ah la la ! Cela ne nous rajeunit pas !

Manuel Vila - Avril 2016

Manipuler les saisies Utilisateur avec précaution

Référence sur drupal.org : 2 Mars 2009 – 03h45 - http://drupal.org/node/101495


Les saisies, qu'elles viennent des internautes ou des serveurs, doivent être manipulées avec précaution.

Prenons l’exemple suivant, basé sur A programmer Introduction to PHP 4.0 de W.J. Gilmore. Il utilise une saisie effectuée par un utilisateur et la place dans une requête SQL :

<?php
/** Exemple 1 - Périlleux
  * SQL injection via $keyword
  */
$keyword $_REQUEST['keyword'];
$query "SELECT cust_id, cust_name, cust_email FROM customers WHERE category = '$keyword'";
$result db_query($query);
?>

Ceci permet à l’utilisateur d’injecter des instructions SQL dans une requête. Que se passera-t-il si l’utilisateur utilise le mot-clé '; DROP TABLE customers; -- ? La requête sera SELECT cust_id, cust_name, cust_email FROM customers WHERE category = ''; DROP TABLE customers; --'

La méthode Drupal : Échapper ou filtrer à bon escient

Vous avez peut-être déjà lu ce conseil d’expert dans les articles traitant des problèmes de sécurité : toujours valider les saisies. Le problème avec un CMS comme Drupal est que la notion de saisie n’est pas bien définie.

La seule chose que nous ayons à faire est que, indépendamment des données, leur contenu ne doit pouvoir être interprété comme du SQL. Nous utilisons pour cela les fonctions d’échappement fournies par l’API database. Nous faisons cet échappement dans la couche database et non juste après la saisie puisqu’il pourrait y avoir plus d’un échappement, ou filtrage, à faire.

<?php
/** Exemple 2 - Périlleux
  * SQL injection via $keyword
  * XSS via $keyword et (potentiellement) $row->cust_name, $row->cust_email
  */
$keyword $_REQUEST['keyword'];
$query "SELECT cust_id, cust_name, cust_email FROM customers WHERE category = '$keyword'";
$result db_query($query);
echo 
"<h2>$keyword</h2>":
while (
$row db_fetch_object($result)) {
  echo 
"$row->cust_name$row->cust_email <br />";
}
?>

Exemple 2 : bien qu’il soit modeste et truffé de failles, il met en évidence le problème du filtrage et de l’échappement des saisies. La variable $keyword doit être filtrée ou échappée deux fois pour différentes raisons : une pour empêcher les injections SQL, et une de plus pour empêcher les attaques par cross-scripting (XSS). Appliquer les deux filtres dès la saisie de $keyword provoquera l’apparition d’étranges barres obliques (slashes) dans les affichages, ou l’échec des recherches contenant des &quot;

La solution consiste en utiliser le filtre adéquat au bon moment. Par exemple, juste avant d’envoyer le texte au navigateur  ou avant de le mixer avec du code HTML, échappez-le avec check_plain.

<?php
/** Exemple 2 - corrigé
  */
$keyword $_REQUEST['keyword'];
$query "SELECT cust_id, cust_name, cust_email FROM customers WHERE category = '%s'";
$result db_query($query$keyword);
echo 
'<h2>'check_plain($keyword) .'</h2>':
while (
$row db_fetch_object($result)) {
  
// Not very elegant, but making a point.
  
echo check_plain($row->cust_name) .','check_plain($row->cust_email) .'<br />';
}
?>