Discussion :

[Zachatim]

Bonjour,

Pour sécuriser les données que mes visiteurs envoient j'utilise la preg ci-dessous pour filtrer (pas les valider) leurs variables :

Pour les emails :

Code :

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

$email = preg_replace("#[^0-9a-zA-Z@._\-]#","",strtolower($_POST['email']));

Pour les variable alpha numérique avec accent :

Code :

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

$prenom=preg_replace("#[^0-9a-zA-Z-_.!?;:ÀÁÂÃÄÅàáâãäåÒÓÔÕÖØòóôõöøÈÉÊËèéêëÇçÌÍÎÏìíîïÙÚÛÜùúûüÿÑñ ']#","",$_POST['prenom']);

Et par exemple avec un GET qui est sensé avoir que des chiffres je fais :

Code :

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

$chiffre=preg_replace("#[^0-9]#","",$_GET['chiffre']);

Ca fonctionne bien.
Ma question est la suivante : est-ce qu'il y a un moyen plus léger en resource CPU pour faire la même chose que scanner la variable entière avec un preg_replace ?

[rawsrc]

Salut,

Holàààà ! Halte-là ! Démarre donc bien l'année 2016 s'il te plait et va lire la doc de la fonction filter_var() qui va pour le coup devenir ta meilleure amie

[Zachatim]

Bonjour,

Merci pour la réponse.
Effectivement je viens de voir qu'il y a un filtre FILTER_SANITIZE_EMAIL donc ca déjà c'est génial merci !

Par contre je vois rien pour l'aphanumérique avec accent, y a même rien pour l'alpha numérique tout court, c'est dommage je trouve.
Du coup pour filtrer les variable de type prénom obligé de faire du preg ?

[rawsrc]

Pour l'alphanumérique : ctype_alnum()
Après pour ce qui est des accents, tu peux faire effectivement du regex, mais il est aussi possible de remplacer tous les caractères spéciaux par une chaîne vide (str_replace) et vérifier que ce qui reste correspond à de l'alphanumérique. Si le test renvoie false alors c'est qu'il reste des caractères exotiques.

[Zachatim]

Bon j'ai fais un test rapide avec le code ci-dessous si ca intéresse quelqu'un, systèmatiquement FILTER_SANITIZE_EMAIL est plus rapide à exécuté que le preg_replace, donc ca c'est une bonne nouvelle

La mauvaise nouvelle c'est que FILTER_SANITIZE_EMAIL accepte des caractères qui sont quasiment ( pour pas dire jamais ) utilisé dans un email, je suppose que ca suit une norme RFC quelconque, mais par exemple ca accepte !#$%&'*+-=?^_`{|}~@.[] , perso je considère que quelqu'un qui mets un ! ou un # dans son adresse email a un gros doigt et à fait une faute de frappe, et je parle même pas de { }

En plus de ca t'as de grande chance que si t'utilise cet email ca n'arrive jamais à son destinataire. C'est a mon humble avis une très mauvaise idée d'accepter qu'un visiteur ajoute des ! ou des ^ dans son adresse email.

C'est dommage parce que sur le papier c'est génial FILTER_SANITIZE_EMAIL mais c'est inutilisable je trouve !

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
$email_bidon="sds!/dsd@sdsosdosdoisdisdoo010928129812981928198298128982mpdoILKID1ù^$*ù^$!:mloKIUZEEZZEEZZEEZEZZEdsd.c om)";
 
$timestart=microtime(true);
$email=strtolower(filter_var($email_bidon, FILTER_SANITIZE_EMAIL));
$timeend=microtime(true);
$time=$timeend-$timestart;
$page_load_time1 = number_format($time, 15);
 
echo "$email <br>$page_load_time";
echo"<br><br><br><br><br><br><br>";
 
 
$timestart=microtime(true);
$email = preg_replace("#[^0-9a-zA-Z@._\-]#","",strtolower($email_bidon));
$timeend=microtime(true);
$time=$timeend-$timestart;
$page_load_time2 = number_format($time, 15);
 
echo "$email<br> $page_load_time";
echo"<br><br><br><br><br><br><br>";
 
 
if($page_load_time2>$page_load_time1)
{
	echo"preg_replace plus long";
}
else
{
	echo"filter_var plus long";
}

[rawsrc]

Salut, pour les emails, il me semble que la norme c'est la RFC 822

[rawsrc]

Pour valider les email, tu as ceci :

Code :

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

$is_valid = filter_var("sds!/dsd@sdsosdosdoisdisdoo010928129812981928198298128982mpdoILKID1ù^$*ù^$!:mloKIUZEEZZEEZZEEZEZZEdsd.c om)", FILTER_VALIDATE_EMAIL); // false

[Zachatim]

Rebonjour,

Si je comprend bien la doc :

FILTER_SANITIZE_EMAIL : Supprime tous les caractères sauf les lettres, chiffres, et !#$%&'*+-=?^_`{|}~@.[]

Ca voudrais dire que FILTER_SANITIZE_EMAIL protége des attaque XSS par exemple, et d'une manière général ca nettoie bien une variable utilisateur assez simplement.

Est-ce que l'on pourrais pas utiliser :

Code :

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

1
2
 
$var = filter_var($_POST['var'], FILTER_SANITIZE_EMAIL);

pour protéger simplement la plupart des variables qui viens d'un post (sauf les variables avec accent ou espace) ?


Est-ce que je me trompe ?

[Tsilefy]

Mauvaise idée. Tu confonds filtrer et échapper. Ils peuvent sembler similaires (ex FILTER_SANITIZE_FULL_SPECIAL_CHARS et htmlspecialchars) mais correspondent à des cas d'utilisations différentes.

Filtrer et valider veut dire que tu as un format que tu acceptes (email, téléphone, code postal etc...) et tu rejettes ou transforme toutes les données externes qui ne correspondent pas à ce format. Point. Un filtre ne sécurise pas ton code, il a pour but d'éviter que l'utilisateur t'envoie des données inutilisables.

Échapper consiste à transformer une variable en fonction d'un contexte pour des raisons de sécurité. L'échappement est donc en fonction du contexte: tu n'échappes pas de la même manière selon que ta variable est envoyée dans une base de donnée, affichée dans une balise html, insérée dans du javascript, du CSS, un champ header ou utilisée en tant que chemin de fichier.

Donc:

1) Tu ne peux donc pas utiliser un filtre, qui n'a pas de contexe, à la place d'un échappement.
2) Le filtrage/la validation s'effectue à l'arrivée de la variable, alors que tu dois échapper au tout dernier moment, quand tu es sûr du contexte dans lequel tu vas utiliser la variable. Imaginons que tu utilises FILTER_SANITIZE_FULL_SPECIAL_CHARS comme flag pour tes filtres et que tu enregistres ensuite tes données dans ta base. Ça ne va pas te protéger d'une injection SQL, d'une injection json, d'une injection CSS, d'une injection de fichier, d'une attaque par path traversal, d'un empoisonnement des headers, des cookies, de unserialize() etc etc. Seule un échappement en fonction du contexte te garantit ça.

Conclusion: il faut utiliser les deux, et ne pas méprendre l'un pour l'autre.

[Tsilefy]

Quand aux critères de validation d'un email, il faut faire attention parce que certains caractères qu'on peut ne pas considérer "normales" au premier abord sont en fait utilisées par un certain nombre de gens. Par exemple, un certain nombre de fournisseurs d'email (gmail, hotmail par exemple) permettent la création d'alias illimités en utilisant les caractères "+" ou ".". En rejetant ces caractères (ou pire, en les transformant), tu ferais une grave erreur (que beaucoup de regex pour emails font). Et je suis sûr qu'il y a d'autres caractères tout aussi fréquemment utilisés.

Au final, tu risques de faire comme certains sites anglophones d'il y a quelques années, qui rejetaient (ou transformaient) les noms à accents parce que les accents n'était jamais utilisés chez eux.

[Celira]

Au passage, si tu veux tester/filtrer des données provenant d'un formulaire/url, tu peux utiliser filter_​input à la place de filter_var.
En plus du filtre, ça vérifie que la variable existe bien,ce qui évite d'avoir à ajouter des isset() un peu partout (ou les notice Undefined Index )

[ascito]

je serais presque à proposer cela

Code :

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

1
2
3
4
5
 
<?php
$email_bidon = strtolower("sds!/dsd@sdsosdosdoisdisdoo010928129812981928198298128982mpdoILKID1ù^$*ù^$!:mloKIUZEEZZEEZZEEZEZZEdsd.c om)");
 
$is_valid = filter_var($email_bidon, FILTER_VALIDATE_EMAIL) && filter_var($email_bidon, FILTER_SANITIZE_EMAIL) === $email_bidon ? true : false;

on confirme que l'email match le filtre, et on confirme que le sanitize ne transforme pas l'email.

(même si je me dit que les filtres sont un peu les même )

[Zachatim]

Mauvaise idée. Tu confonds filtrer et échapper. Ils peuvent sembler similaires (ex FILTER_SANITIZE_FULL_SPECIAL_CHARS et htmlspecialchars) mais correspondent à des cas d'utilisations différentes.

Bonjour à tous et merci pour vos réponses,

J'ai relus plusieurs fois votre message, pour essayer de ne pas dire de bétise.
Ce que je cherche avant tout c'est protéger mes variable post et get de quelqu'un de mal intentionné, je ne cherche pas à les valider, la dessus j'ai bien compris la différence.

Après ca se complique, peut être que je m'exprime mal ou peut être que j'utilise les mauvais terme.
Ce que je voulais dire c'est détourner ces filtres pour s'en servir comme liste blanche et éviter de faire des preg_replace qui sont lent, exemple :

$chiffre = filter_var($_POST['chiffre'], FILTER_SANITIZE_NUMBER_INT);

Imaginons que vous attendez que des chiffres de cette variable $_POST['chiffre']
Peut-on considérer que le filtre FILTER_SANITIZE_NUMBER_INT (qui supprime tout sauf les chiffres) se comporte comme une liste blanche, et protège cette variable des xss, injection etc ?
Si quelqu'un ajoute par exemple un ' ou un < ou je ne sais quelle autre cochonnerie dans cette variable cela va être effacén ca reviens donc au final à protéger cette variable non ?

[Tsilefy]

Ce que je voulais dire c'est détourner ces filtres pour s'en servir comme liste blanche et éviter de faire des preg_replace qui sont lent, exemple :

Imaginons que vous attendez que des chiffres de cette variable $_POST['chiffre']
Peut-on considérer que le filtre FILTER_SANITIZE_NUMBER_INT (qui supprime tout sauf les chiffres) se comporte comme une liste blanche, et protège cette variable des xss, injection etc ?
Si quelqu'un ajoute par exemple un ' ou un < ou je ne sais quelle autre cochonnerie dans cette variable cela va être effacén ca reviens donc au final à protéger cette variable non ?

- Oui, un filtre est une liste blanche et te permets d'éliminer des valeurs inacceptables

- Non, un filtre n'est jamais suffisant pour te protéger. Tu dois te protéger contre "quelque chose" (injection SQL, XSS, injection de code etc...), c'est-à-dire un "contexte", et pour te protéger efficacement tu dois savoir quel est ce contexte et utiliser la fonction qui correspond à ce contexte (htmlspecialchars pour XSS dans un HTML, json_encode pour XSS dans un javascript, requête préparée pour mysql, basename et realpath pour une directory/path traversal, etc...).

Donc, tu dois filtrer ta variable juste après la soumission du formulaire mais ce n'est pas suffisant. Il faut ensuite l'échapper:
- au moment d'enregistrer l'email dans la base de données, il faut utiliser une requête préparée.
- Au moment d'afficher l'email sur une page HTML (que ce soit directement ou en l'ayant récupéré de la base de données), il faut faire echo htmlspecialchars($email, ENT_QUOTES);
- et ainsi de suite.

Bref, tu ne peux pas te contenter de filtrer, tu dois aussi échapper au moment d'utiliser la valeur (çad au moment de l'insérer dans la base, de l'afficher dans une page, de le stocker dans une cookie, etc...).
Le principe est: Filtrer au début, Échapper à la fin.