Discussion :

[Le nettoyeur]

Bonjour,

Je débute avec les fonctions et j'aimerais un exemple adapté à mon problème.
Voilà, j'ai une dizaine de pages qui utilisent ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$titre=htmlspecialchars(mysql_real_escape_string($_POST['titre']));
$contenu=htmlspecialchars(mysql_real_escape_string($_POST['contenu']));

L'idée serait bien sûr de créer une fonction dans un fichier qui serait inclu dans toutes les pages, puis d'appeler ladite fonction à l'endroit voulu, dans chaque page.

Mais ma compréhension de la chose s'arrête là. Bien sûr j'ai lu les cours, mais je voudrais un exemple concret, pour commencer.

Merci d'avance

[sabotage]

Déjà, les deux fonctions ne vont pas ensemble :

mysql_real_escape_string sert à l'utilisation d'une donnée externe dans une requête avec l'ancien driver mysql_
htmlspecialchars sert à l'affichage de données externes dans du HTML.

Ces deux fonctions ayant un usage spécifique, il n'y a pas de raison de généraliser leur utilisation à toutes les pages.

Après disons que si avant d'éxécuter une requête tu veux échapper toutes tes variables de formulaire, tu peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$_POST = array_map('mysql_real_escape_string', $_POST);

[Le nettoyeur]

Salut sabotage, merci pour ta réponse.
Mes scripts datent de plus de 5 ans, j'ai peut être beson de me remettre à jour question sécurité. J'ai toujours utilisé les fonctions ci-dessus mais bon... Qu'est-ce que cette hitoire d'ancien driver sql ? Qu'est-ce que ça change ? Ca date de quand ? On ne peut plus utiliser mysql_real_escape_string ? C'est quoi la nouvelle fonction ?
Et pour html_special_chars alors ? Il me faut une fonction qui filtre les caractères spéciaux. Si j'utilise htmlentities à la place, de mémoire ça me fait plein de caractères crades dans la base de données.

[Benjamin Delespierre]

Si tu as PHP 5.2, cette fonction peut t'aider à filtrer les données utilisateur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
/**
 * @brief Generic validation function
 * 
 * This function takes an input (either an INPUT_* integer or an associative array) and a required structure to filter
 * against and computes error messages (if any).
 * @c $structure parameter is described as follow 
 * @code
 * $structure = array(
 * 'a' => array(
 *    'filter' => FILTER_VALIDATE_INT,
 *    'missing' => 'A is missing',
 *    'invalid' => 'A is invalid',
 *   ),
 *   'b' => array(
 *    'filter' => FILTER_SANITIZE_STRING,
 *    'missing' => 'B is missing',
 *    'invalid' => 'B is invalid',
 *   ),
 *   'c' => array(
 *    'filter' => FILTER_VALIDATE_EMAIL,
 *    'missing' => 'C is missing',
 *    'invalid' => 'C is invalid',
 *   ),
 * );
 * @endcode
 *  
 * @param integer|array $input The input to validate, can be either INPUT_GET, INPUT_POST, INPUT_COOKIE, INPUT_SERVER, 
 * INPUT_ENV or an associative array
 * @param array $structure The filter structure, optionnaly padded with error messages
 * @param array (out) $messages Error messages fetched from missing or invalid entries in $structure array 
 * @param boolean $silent @optional @default{false} If set to true, will not throw errors when the 'filter' parameter
 * is missing 
 * @throws RuntimeException If used with PHP < 5.2
 * @throws InvalidArgumentException If a parameter is invalid
 */
function validate ($input, array $structure, array & $messages = null, $silent = false) {
    if (!defined('PHP_VERSION_ID') || PHP_VERSION_ID < 50200)
        throw new RuntimeException(__FUNCTION__ . " requires PHP 5.2 or higher");
 
    if (empty($structure))
        throw new InvalidArgumentException("Structure paramter is empty");
 
    if (is_int($input) && !in_array($input, array(INPUT_GET, INPUT_POST, INPUT_COOKIE, INPUT_SERVER, INPUT_ENV)))
        throw new InvalidArgumentException(
            "Input parameter must be one of INPUT_GET, INPUT_POST, INPUT_COOKIE, INPUT_SERVER, or INPUT_ENV");
    elseif (is_int($input))
        $validate = 'filter_input_array';
    elseif (is_array($input))
        $validate = 'filter_var_array';
    else
        throw new InvalidArgumentException(
            "Input parameter is expected to be integer or array," . gettype($input) . "given");
 
    $filter           = array();
    $messages_missing = array();
    $messages_invalid = array();
    foreach ($structure as $key => $value) {
        if (isset($value['filter'])) {
            $filter[$key] = $value['filter'];
        }
        else {
            !$silent && trigger_error("No filter specified for $key, using FILTER_UNSAFE_RAW", E_USER_WARNING);
            $filter[$key] = FILTER_UNSAFE_RAW;
        }
        if (isset($value['missing'])) $messages_missing[$key] = $value['missing'];
        if (isset($value['invalid'])) $messages_invalid[$key] = $value['invalid'];
    }
 
    if (!$data = $validate($input, $filter))
        return $data;
 
    $messages  = array();
    $messages += array_intersect_key($messages_invalid, array_flip(array_keys($data, false, true)));
    $messages += array_intersect_key($messages_missing, array_flip(array_keys($data, null,  true)));
    return $data;
}

Elle permet de filtrer d'un coup tous les inputs utilisateurs et renvoie les messages d'erreurs pour les données manquantes ou invalides. Tout est expliqué dans la description.

[Le nettoyeur]

Holala... C'est affreusement compliqué, j'ai l'impression de repartir 5 ans en arrière quand j'apprenais à coder. Cela fait 2 ans que je n'ai pas codé, et je découvre des fonctions que je n'avais jamais vues...

Qu'est-ce que ce : FILTER_SANITIZE_STRING par exemple ? Ca a été ajouté quand dans php ?
Si ce sont de nouvelles fonctions, il me faudrait un guide pour m'y retrouver dans les nouveautés php de ces dernières années. Parce qu'à vous lire les mysql_real_escape_string et autre htmlspecialchars ne sont plus d'actualité et en les utilisant, je risque désormais de me faire pirater.

**edition **
Faut-il désormais utiliser ces fonctions ? http://php.net/manual/en/filter.filters.sanitize.php

[Benjamin Delespierre]

En effet, désormais l'API des filtres à supplanté les mécanismes traditionnels d'échapement de données et PDO (ou mysqli) avec les requêtes préparées rend inutile mysql_real_escape_string.

[sabotage]

La documentation t'indiquera les fonctions obsolètes.
Toute la série mysql_ est obsolète mais elle n'est pas moins sécurisée que ses successeurs.

htmlspecialchars et htmlentities sont toujours valables, il faut juste les utiliser à bon escient.

[Le nettoyeur]

HeM... Bon il faut que j'approfondisse tout ça.

Donc a priori, donc a priori, dans mon cas ça donnerait ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$titre= filter_input(INPUT_POST, 'titre', FILTER_SANITIZE_SPECIAL_CHARS);

Ca c'est pour filtrer les caractères spéciaux et ça remplace le vieux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$titre=html_special_chars($_POST['titre']).

J'ai bon ?

Et pour remplacer mysql_real_escape_string, j'utilise quoi alors comme filter_sanitize ? FILTER_SANITIZE_STRING, c'est ça ?

[Benjamin Delespierre]

Et pour remplacer mysql_real_escape_string, j'utilise quoi alors comme filter_sanitize ? FILTER_SANITIZE_STRING, c'est ça ?

Nan, utilise les requêtes préparées.

[ABCIWEB]

Le pb est comme l'a dit sabotage est que ton code initial mélange une fonction pour la protection des variables à l'affichage et une fonction pour protéger les variables lors de l'insertion en bdd.

Normalement on ne fait pas les deux à la fois bien que cela ait été une pratique assez courante il y a quelques temps pour enregistrer des variables en bdd. C'était juste par facilité et évitait d'avoir à utiliser la fonction htmlspecialchars (ou htmlentities) pour afficher les données en provenance de la bdd. Le revers de la médaille est que cela rendait la base impropre à l'exportation des données sans traitement préalable, que cela encombrait la base avec les caractères spéciaux codés, et surtout que cela rend impossible une recherche sur le texte insensible aux caractères accentués.
De ce fait cette méthode a été pratiquement abandonnée et l'on prend soin d'utiliser htmlspecialchars uniquement à l'affichage (<?php echo htmlspecialchars($var)?>) et on protège les données pour enregistrement en bdd avec uniquement mysql_real_escape_string.

Ensuite l'utilisation de l'extension mysql_ ayant été dépréciée on conseille maintenant pour les nouveaux projets d'utiliser mysqli ou pdo (avant de t'y mettre vérifie quand même que ces extensions sont supportées chez ton hébergeur).

L'équivalent mysql de "mysql_real_escape_string" est la fonction "mysqli_real_escape_string" pour mysqli
L'équivalent mysql de "mysql_real_escape_string" est la fonction "quote" pour pdo.

A noter que mysqli et pdo supportent les requêtes préparées et dans le cas de requêtes préparées on bind les variables ce qui fait que l'on a pas besoin d'utiliser "mysqli_real_escape_string" ou "quote".

Voilà il faudrait que ces choses soient claires avant d'aller plus loin.

Les nouvelles fonctions de filtrage/validation de variables n'ont pas de rapport direct avec les fonctions citées ci-dessus.

[ABCIWEB]

En effet, désormais l'API des filtres à supplanté les mécanismes traditionnels d'échappement de données

??

[Le nettoyeur]

Nan, utilise les requêtes préparées.

Hum... Que sont les requêtes séparées ? Et sinon, hormis le fait qu'il ne faille pas le faire avant insertion, ce bout de code que j'ai écrit est-il correct :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$titre= filter_input(INPUT_POST, 'titre', FILTER_SANITIZE_SPECIAL_CHARS);

Normalement on ne fait pas les deux à la fois bien que cela ait été une pratique assez courante il y a quelques temps pour enregistrer des variables en bdd. C'était juste par facilité et évitait d'avoir à utiliser la fonction htmlspecialchars (ou htmlentities) pour afficher les données en provenance de la bdd. Le revers de la médaille est que cela rendait la base impropre à l'exportation des données sans traitement préalable, que cela encombrait la base avec les caractères spéciaux codés, et surtout que cela rend impossible une recherche sur le texte insensible aux caractères accentués.
De ce fait cette méthode a été pratiquement abandonnée et l'on prend soin d'utiliser htmlspecialchars uniquement à l'affichage (<?php echo htmlspecialchars($var)?>) et on protège les données pour enregistrement en bdd avec uniquement mysql_real_escape_string.

Remarque, ça on me le disait aussi il y a 5 ans.

Ensuite l'utilisation de l'extension mysql_ ayant été dépréciée on conseille maintenant pour les nouveaux projets d'utiliser mysqli ou pdo (avant de t'y mettre vérifie quand même que ces extensions sont supportées chez ton hébergeur).

L'équivalent mysql de "mysql_real_escape_string" est la fonction "mysqli_real_escape_string" pour mysqli
L'équivalent mysql de "mysql_real_escape_string" est la fonction "quote" pour pdo.

Et finalement en deux mots quelles différences entre mysql et mysqli ?

A noter que mysqli et pdo supportent les requêtes préparées et dans le cas de requêtes préparées on bind les variables ce qui fait que l'on a pas besoin d'utiliser "mysqli_real_escape_string" ou "quote"..

Encore ces "requêtes préparées"...

Voilà il faudrait que ces choses soient claires avant d'aller plus loin.

Bah justement

Les nouvelles fonctions de filtrage/validation de variables n'ont pas de rapport direct avec les fonctions citées ci-dessus.

Je sais même plus lesquelles

Bon, j'y vois quand même déjà plus clair qu'au début mais va falloir encore débroussailler tout ça. S'en est passées des choses en deux ans...

Et merci pour vos réponses

[Benjamin Delespierre]

??

Personne ne dira le contraire, les filtres sont beaucoup plus puissants que les dizaines de fonctions de nettoyage du langage.

Que sont les requêtes séparées ?

Les requêtes préparées sont des requêtes qu'on prépare (duh) avant de les exécuter. En clair, ça permet d'envoyer séparément la requête et les données.

Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?php
 
$pdo = new PDO(...);
$stmt = $pdo->prepare('INSERT INTO foo (`bar`) VALUES (:bar)');
 
$stmt->execute(array('bar' => 1));
$stmt->execute(array('bar' => 2));
$stmt->execute(array('bar' => 3));

Vu que les données sont envoyées séparément, ce mécanisme est imperméable aux injections SQL en plus d'être plus rapide s'il y a plusieurs requêtes à faire car la requête préparée est maintenue tant que la connexion est active.

Et finalement en deux mots quelles différences entre mysql et mysqli ?

Ce sont deux interface qui parlent à MySQL. La différence réside dans le support des requêtes préparées, des transactions etc.

Bon, j'y vois quand même déjà plus clair qu'au début mais va falloir encore débroussailler tout ça. S'en est passées des choses en deux ans...

T'as arrêté le PHP sur quel version qu'on se fasse une idée ? C'est vrai que le web évolue très vite, c'est ce qui fait l'intérêt de la chose.

[ABCIWEB]

Je sais même plus lesquelles

Je parlais plus haut de htmlspecialchars et de mysql_real_escape_string.

A part cela si tu veux mettre à jour un ancien code utilisant mysql, l'extension mysqli en mode procédural est tout à fait indiquée car cela te demanderas peu de modification (sauf à passer l'identifiant de connexion dans certaines requêtes ou fonctions). Plus d'infos ici

[ABCIWEB]

En effet, désormais l'API des filtres à supplanté les mécanismes traditionnels d'échapement de données...

??

Personne ne dira le contraire, les filtres sont beaucoup plus puissants que les dizaines de fonctions de nettoyage du langage.

Nettoyage, validation, ok, mais c'est le mot "échappement" que je trouve très ambigu

[Benjamin Delespierre]

??

Nettoyage, validation, ok, mais c'est le mot "échappement" que je trouve très ambigu

Pas faux, utilisons des termes clairs.

[Le nettoyeur]

Bonjour,
Alors reprenons, si vous le voulez bien.

Les requêtes préparées sont des requêtes qu'on prépare (duh) avant de les exécuter. En clair, ça permet d'envoyer séparément la requête et les données.

Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?php
 
$pdo = new PDO(...);
$stmt = $pdo->prepare('INSERT INTO foo (`bar`) VALUES (:bar)');
 
$stmt->execute(array('bar' => 1));
$stmt->execute(array('bar' => 2));
$stmt->execute(array('bar' => 3));

Vu que les données sont envoyées séparément, ce mécanisme est imperméable aux injections SQL en plus d'être plus rapide s'il y a plusieurs requêtes à faire car la requête préparée est maintenue tant que la connexion est active.

D'accord et donc ça, ça date de ces deux dernières années ? C'est désormais indispensable ou pour le moins hautement recommandé ? Quite à refaire mon site, autant respecter les nouveaux standards. Au passage, pourquoi utilisez-vous toujours $stmt dans les exemples de requêtes préparées ? Que signifie stmt à l'origine ?

Ce sont deux interface qui parlent à MySQL. La différence réside dans le support des requêtes préparées, des transactions etc.

Et donc ça aussi ça date d'après 2010 (je n'ai pratiquement rien codé depuis) ?

T'as arrêté le PHP sur quel version qu'on se fasse une idée ? C'est vrai que le web évolue très vite, c'est ce qui fait l'intérêt de la chose.

La version 5 avec les fonctions et les objets (que je n'utilisais pas) était déjà en route. Oui ça évolue vite et quand on est pas informaticien professionnel, on perd vite le fil.

Pourriez-vous me confirmer que mon misérable bout de code est correct, nonobstant le fait qu'il faille utiliser mysql_special_chars à l'affichage et non à l'insertion ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

titre= filter_input(INPUT_POST, 'titre', FILTER_SANITIZE_SPECIAL_CHARS);

Et donc si j'ai bien compris, pour l'insertion en revanche, c'est ça désormais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

titre= filter_input(INPUT_POST, 'titre', FILTER_SANITIZE_STRINGS);

Aussi, j'ai vu qu'il y a désormais une fonction filter_sanitisze dédié aux emails, c'est pour éviter d'utiliser les expressions régulières, c'est ça ?


Encore merci pour votre aide

[Benjamin Delespierre]

J'ai bien peur que ces "nouveautés" soient un peu plus anciennes que ça:

• PDO dispo. depuis PHP 5.1 (fin 2005)
• mysqli dispo. depuis PHP 5.0 (2004)
• filter_* dispo. depuis PHP 5.2 (2006)

Voir l'historique des versions.

La technologie bouge certes plus vite que les articles en ligne (et bien plus que les cours dispensés dans les universités, crois-moi) ce qui produit cet effet de nouveauté. Encore aujourd'hui, beaucoup d'articles sont écrits avec des mentions à mysql_* (tristesse...)

Concernant la validation/nettoyage des données, tu est dispensé d'échapper les caractères spéciaux si tu insère en base avec les requêtes préparées.
En revanche, échapper en entrée (validation) et en sortie (nettoyage) est un must.

Exemple simple:
commenter.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<?php
 
// Insérer des données
 
$inputs['author']  = filter_input(INPUT_POST, 'author', FILTER_SANITIZE_STRING);
$inputs['message'] = filter_input(INPUT_POST, 'message', FILTER_SANITIZE_STRING);
 
//  - ou -
 
$inputs = filter_input_array(INPUT_POST, array(
    'author'  => FILTER_SANITIZE_STRING,
    'message' => FILTER_SANITIER_STRING,
));
 
$pdo  = new PDO(...);
$stmt = $pdo->prepare('INSERT INTO comments (author,message) VALUES (:author,:message)');
 
if ($stmt->execute($inputs)) {
    // ok
}
else {
    // nok !
}

commentaires.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<?php
 
// Extraire les donnés puis afficher
 
$article_id = filter_input(INPUT_GET, 'article_id', FILTER_SANITIZE_INT);
 
if (!$article_id) {
    // erreur
}
 
$pdo  = new PDO(...);
$stmt = $pdo->prepare('SELECT author,message FROM comments WHERE article_id=:article_id');
 
if (!$stmt->execute(compact('article_id'))) {
    // erreur
}
 
$stmt->setFetchMode(PDO::FETCH_OBJ); // sera utile lors qu'on va traverser les résultats
?>
<!DOCTYPE HTML>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
    <title>Commentaires</title>
</head>
<body>
    <h1>Commentaires de l'article #<?php echo $article_id ?></h1>
    <?php foreach ($stmt as $comment): ?>
    <blockquote>
        <h3 class="author"><?php echo filter_var($comment->author,  FILTER_SANITIZE_STRING) ?></h3>
        <p class="message"><?php echo filter_var($comment->message, FILTER_SANITIZE_STRING) ?></p>
    </blockquote>
    <?php endforeach ?>
</body>
</html>

Pourquoi je netttoie à la fois en entrée et en sortie ? Blindage. Dans une application web, l'utilisateur c'est le mal et la base de données caractérise l'utilisateur donc la base de données c'est le mal.

Il faut toujours considérer les données provenant de l'utilisateur ($_GET, $_POST, $_COOKIE) ainsi que les données de la base comme "tâchées" (sales si tu préfère) et les traiter avec la précaution qu'elles méritent.

Oh et tant que j'y suis, les données $_GET et $_POST ont absolument le même niveau de sécurité. Il y a beaucoup de gens qui, encore aujourd'hui, pensent le contraire et se dispensent de vérifications sur les données $_POST. Je le répète, tout ce qui vient de l'utilisateur c'est le mal.

[Le nettoyeur]

J'ai bien peur que ces "nouveautés" soient un peu plus anciennes que ça:

• PDO dispo. depuis PHP 5.1 (fin 2005)
• mysqli dispo. depuis PHP 5.0 (2004)
• filter_* dispo. depuis PHP 5.2 (2006)

Voir l'historique des versions.

La technologie bouge certes plus vite que les articles en ligne (et bien plus que les cours dispensés dans les universités, crois-moi) ce qui produit cet effet de nouveauté. Encore aujourd'hui, beaucoup d'articles sont écrits avec des mentions à mysql_* (tristesse...)

J'ai codé intensivement de 2006 à 2010 et je n'ai jamais entendu parler de requêtes préparées (et D. sait si j'en ai codé).

J'apprécie ton sérieux, Benjamin Delespierre. Alors maintenant que je commence à avoir un apperçu de mes lacunes, que dois-je réapprendre pour être au goût du jour et coder un nouveau site qui n'ait pas l'air d'une Peugeot 205 d'occasion ?

- Les requêtes préparées
- Ce qu'est mysqli
- Les nouvelles fonctions FILTER_SANITIZE

C'est ça ?
D'ailleurs au sujet de ces nouvelles fonctions, y'en-a-t'il une liste quelque part ?

Encore merci

[Benjamin Delespierre]

Pour avoir un aperçu des nouvelles fonctionnalités, tu peux toujours consulter le changelog de PHP mais ça risque de te prendre pas mal de temps.

Maintenant, pour ce qui est de la refonte, je serai pour une fois plus tempéré dans mes avis. La technologie change vite dans le web certes, mais ce n'es pas une raison pour tout recommencer tous les deux ans, ce n'est pas forcément souhaitable. PHP à toujours mis l'accent sur la rétro-compatibilité, les fonctionnalités qui "disparaissent" sont chose rare. Une feature passe de l'état "standard" à "découragé" puis "déprécié" avant d'être finalement supprimée, ce processus peut s'étaler sur plusieurs versions, ce qui facilite grandement la migration des service vers des version plus récentes de l’interpréteur.

En résumé, l'évolution de la technologie est un choix influent mais non déterminant sur la décision de refonte d'une application. Je pense qu'il faut davantage s'appuyer sur l'architecture (ou son absence) pour décider si oui ou non un produit est en fin de vie et doit être refondu. Donc si ton appli marche bien et nécessite quelques ajustements, ne refais pas tout. Si en revanche, sa maintenance nécessite de plus en plus de temps (caractéristique d'une application sans ou avec un mauvais design d'architecture) alors ça peut être avantageux de refondre.

Pour reprendre ton exemple, ta Peugeot 205 elle roule toujours ? T'es bien dedans ? Alors pourquoi changer ? Si par contre il faut passer au garage tous les 10.000 km, il vaut mieux l'échanger pour un modèle plus récent.

Par exemple dans ton cas, passer de mysql à mysqli n'est ni long ni vraiment compliqué, c'est un bon moyen d'améliorer la sécurité en préservant la qualité de service.

Dans tous les cas, apprendre les nouvelles technologies / fonctionnalités et standards n'est jamais du temps perdu et je t'encourage à suivre ce chemin et faire de la veille technologique. Suivre le forum et la rubrique PHP sont un bon point de départ.

La décision t'appartient.