Filtrer les variables

Bonjour, je voulais savoir, jusqu’où on doit filtrer des variables.

Je souhaite me servir de la variable $_SERVER['REQUEST_URI'].

C'est une variable serveur, mais tout le monde peut y taper dedans n'importe quoi.

Avant de traiter cette variable si j'ai bien compris je dois la filtrer.

Mais des filtres y en a un paquet.... filtre de validation, filtre de nettoyage... filter_var(), filter_input()

Code:

---

1 2 3 4 5

filter_input( INPUT_SERVER , $url ) filter_var( $url , FILTER_VALIDATE_URL ) trim( $url ) stripslashes( $url ) htmlspecialchars( $url )

---

Filtrer pour filtrer cela ne sert a rien, donc je voulais voir avec vous comme se poser les bonnes questions pour appliquer le ou les bons filtres

Je vais avoir un modèle du style : /blabla/macategorie/monarticle/page2/edit

Je dois faire un explode( '/' , $url );
Dois-je filtrer avant ou après explode(), l'ensemble ou chaque $path[] un après l'autre de facon différente

$monarticle sera utilisé pour une include mais reformaté style include ('mon adresse' . $monarticle);
Je n'attend pas en réponse un script clé en main, mais plutôt des conseils pour me poser les bonnes questions et trouver les bonnes réponses

Salut,

la réponse est simple : à un moment dans le déroulé de tes scripts, tu dois être absolument certain de ce qui est manipulé.
S'il est attendu un entier à un moment, tu dois t'assurer que c'est un entier que tu vas présenter, si c'est une valeur parmi une liste, même raisonnement, etc.
Tu peux filtrer, nettoyer ou même caster pour s'assurer que ce qui est reçu est conforme à ce qui est attendu.

Et en la matière : tout ce qui provient de l'extérieur doit faire OBLIGATOIREMENT l'objet d'un contrôle de valeur et/ou de type.

Le pendant est : tout ce qui doit être envoyé au navigateur doit être rendu inoffensif par un échappement via

Code:

---

1 2	// échappement des caractères dangereux $hsc = function($p): string { return htmlspecialchars((string)$p, ENT_QUOTES, 'utf-8'); };

---

Avec l'URL : /aa a<script>

J'ai echo $_SERVER['REQUEST_URI'] -> aa%20a%3Cscript%3E

Et en passant $_SERVER['REQUEST_URI'] par htmlspecialchars(), j'ai $url = htmlspecialchars( ( string ) $url , ENT_QUOTES , 'utf-8' ); -> aa%20a%3Cscript%3E

Cela ne change rien $_SERVER['REQUEST_URI'] est-elle déjà filtrée ???
Du coup cela ne sert à rien de la filtrer ???

Plus de précisions sur les différentes fonctions :
La fonction filter_input va aller chercher directement dans $_SERVER la valeur par rapport à l'index et gérer le cas où l'index n'existe pas, alors que filter_var travaille directement sur la variable et que c'est à toi de vérifier que tu lui envoies bien quelque chose.
Donc basiquement :

Code:

---

1 2 3 4 5 6

$res = filter_input(INPUT_SERVER, 'REQUEST_URI', $filtres); // équivalent à $res = null; if (isset($_SERVER['REQUEST_URI'])) { $res = filter_var($_SERVER['REQUEST_URI']), $filtres); }

---

Dans ton cas, tu peux utiliser filter_input avec le filtre FILTER_SANITIZE_URL par exemple.

Merciiii, bon je vais utiliser

Code:

---

filter_input( INPUT_SERVER , 'REQUEST_URI' , FILTER_SANITIZE_URL )

---

Si j'ai bien compris, il gère si $_SERVER['REQUEST_URI'] n'existe pas

1°) Je suppose qu'il retourne NULL si $_SERVER['REQUEST_URI'] n'existe pas plutôt que de générer une erreur ?

2°) Comment $_SERVER['REQUEST_URI'] peut ne pas exister ?

3°) J'ai bien compris que FILTER_SANITIZE_URL filtre, mais je ne comprend pas quoi !!!
Si dans mon URL, je tape n’importe quoi histoire de tester le filtre...

http://monsite.com/a+ +aa@a<:!/

avec echo $_SERVER['REQUEST_URI']; -> cela affiche /a+%20+aa@a%3C:!/et si je filtre... et bien... cela affiche toujours la même chose...

Code:

---

echo filter_input( INPUT_SERVER , 'REQUEST_URI' , FILTER_SANITIZE_URL )

---

->

Citation:

---

/a+%20+aa@a%3C:!/

---

Donc cela filtre... cela transforme < en %3C

Mais $_SERVER['REQUEST_URI'] le fait déjà tout seul, c'est ça que je ne comprends pas

Message de Savageman

Citation:

---

à noter que $_SERVER['PHP_SELF'] est vulnérable à la faille XSS !
Pour l'afficher, on utilisera donc htmlspecialchars().
$_SERVER['REQUEST_URI'] n'est pas affecté par cette faille, on peut l'afficher directement.

---

Mais comme il ne faut pas croire ce qui vient de l'extérieur lol je préfère filtrer heuuu vous demander votre avis

Bonjour,

rawsrc t'a dit quoi faire.

Après.... Il faut arrêter la parano...
Si tu codes "proprement" (= rigoureusement) et que tes requêtes SQL sont correctement préparées, ça sera un bon début.

Je ne suis pas parano... bien au contraire

Tout le mode dit il faut filtrer... filtrer pour filtrer sans se poser la question de savoir si c'est utile.

Ma question est : est-ce utile de filtrer $_SERVER['REQUEST_URI']
2 réponses =

1°) Oui on filtre sans savoir pourquoi, alors on filtre aussi $_SERVER['REQUEST_URI']
2°) C'est pas si évident que cela car $_SERVER['REQUEST_URI'] est ENTIEREMENT générée par le serveur et semble donc sure (si on peut modifier les variables serveur c'est qu'on a accès au serveur donc c'est déjà trop tard)

Oui certaines variables serveur sont générées à partir d'info extérieures entêtes HTTP donc modifiables depuis l'extérieur comme $_SERVER['PHP_SELF'], $_SERVER['HTTPS'], $_SERVER['HTTP_REFERER']
Mais certaines sont générées uniquement par le serveur donc non modifiables (injectable).

Filtrer pour filtrer c'est pas si évident que cela :

https://stackoverflow.com/questions/...i-is-it-secure

J'ai bien compris qu'il fallait filtrer les variables a risque (filtre, liste banche, liste noire, liste grise...) et que cela fait partie des bonnes pratiques.
Mais une bonne pratique n'a de sens que si elle sert a quelque chose.
Mettre un slip c'est une bonne pratique, en mettre 2 ça sert a rien et en mettre 1 pour prendre son bain c'est contre productif, sauf explication particulière.

Mais quand je filtre j'aime bien savoir pourquoi ???

et dans le cas de $_SERVER['REQUEST_URI'] cela ne semble pas avoir de sens, d'après mes lectures.

Mais comme je ne suis pas un pro, je n'ai pas la réponse... mais cela ne m’empêche pas de poser la question

Si quelqu'un a une réponse argumentée, je suis preneur.

Pas du style "on filtre, parce que c'est comme, cherche pas a savoir c'est comme ça".

La question ne porte pas sur les variables en GENERAL, mais bien que sur $_SERVER['REQUEST_URI']
Si quelqu'un a une réponse du style : On filtre aussi $_SERVER['REQUEST_URI'] parceque .... $_SERVER['REQUEST_URI'] est également a risque parce que ....

Le seul truc qui me fait douter c'est l’existence de filter_input(INPUT_SERVER, 'REQUEST_URI', $filtres) pourquoi avoir une fonction pour filtrer un truc qui na pas de sens... mais cela pourrait être que filter_input(INPUT_SERVER) est générique et sert surtout pour les autres valeurs que REQUEST_URI.

Citation:

---

Envoyé par rawsrc

tout ce qui provient de l'extérieur doit faire OBLIGATOIREMENT l'objet d'un contrôle de valeur et/ou de type.

---

C'est pourtant clair, non ?

C'est ta conception du mot "filtrer" qui est biaisée.

• On ne filtre pas seulement parce qu'il y a un "risque".
• On s'assure aussi que la donnée a bien la forme (syntaxe,...) et le type voulu.

Donc, PAS BESOIN de se demander quel est le DEGRÉ de risque (faible ? élevé ? proche de zéro ? ...).
Non.
On fait fait.

Et on dort sur ses deux oreilles.


Pour enfoncer le clou... :
$_SERVER['REQUEST_URI'] est censé renvoyer une URI (qui respecte la syntaxe d'une URL).
Donc, on s'assure que c'est bien le cas.
Point barre.

Pour fracasser le clou... :
Quand tu mets tes chaussures le matin, tu ne te demandes pas si tu vas devoir marcher sur de la moquette toute douce, ou sur du gravier ou du verre coupant.
Tu les mets.
Point barre.

SI $_SERVER['REQUEST_URI'] = a+ +aa@a<:!/
echo $_SERVER['REQUEST_URI']
Donne : /a+%20+aa@a%3C:!/
Sans filtre $_SERVER['REQUEST_URI'] à déjà remplacé < par %3C (sans filtre tout seul comme un grand)

Bon partons du principe qu'on filtre, y aurait-il un exemple concret au je pourrais voir en pratique l'utilité du filtre

Voila un exemple me permettrait de comprendre, car pour le moment les seuls exemples que je teste, je trouve pas de différence

Citation:

---

Pour fracasser le clou... :
Quand tu mets tes chaussures le matin, tu ne te demandes pas si tu vas devoir marcher sur de la moquette toute douce, ou sur du gravier ou du verre coupant.
Tu les mets.
Point barre.

---

Et bien SI justement, c'est ça mon problème lol

Si je vais faire un jogging, aller à la mer, à la montagne au foot ou au resto je ne mets pas les mêmes chaussures.

OK.

Remplace le mot "FILTRER" par le mot "VÉRIFIER".
Ça changera peut-être ta vision des choses.

Sinon... Fais comme tu veux... :roll:

Citation:

---

Envoyé par scamphp

...Si je vais faire un jogging, aller à la mer, à la montagne au foot ou au resto je ne mets pas les mêmes chaussures.

---

Là, on est d'accord !
Mais pas pour la même raison : "on ne met pas les mêmes" en fonction de CE QU'ON VEUT/DOIT EN FAIRE.
Par conséquent, on VÉRIFIE qu'on a les BONNES chaussures / données.

Oui voila tu as raison

Citation:

---

Par conséquent, on VÉRIFIE qu'on a les BONNES chaussures / données.

---

"VÉRIFIER" c'est mieux que filtrer.

Sur GG la tendance est quand même a dire que $_SERVER['REQUEST_URI'] est sûr.

Mais comme personne n'est d'accord, j'en déduis que personne ne sait en réalité.

Principe de précaution comme on ne sait pas comment est générée $_SERVER['REQUEST_URI'], car on n'est pas développeur de la team PHP, alors on filtre dans le doute.

Mais du coup il faudrait aussi VÉRIFIER dirname( __DIR__ ) ???

Et si je mets des chaussures $chaussure faudrait aussi vérifier que $chaussure sont bien des chaussures même si c'est moi qui vient de les mettre ??? et vérifier ses propres variables...

La pour le coup, je vais être parano...

A la base, on ne fait pas confiance à $_SERVER['REQUEST_URI'] parce que ça vient de la requête HTTP, autrement dit, du poste de l'utilisateur et qu'on ne fait pas confiance aux utilisateurs.

Pour prendre une métaphore (autre que celles de chaussures :mouarf:) : quand tu reçois un colis tu vérifies qu'il contient bien ce que tu as commandé. Non pas parce que tu crains qu'il explose, mais parce que si tu reçois le DVD de "Dans un grand vent de fleurs" alors que tu t'attends à "Vendée Globe 2012, le film officiel", c'est mieux de le savoir tout de suite plutôt qu'au moment de de lancer le film, installé sur ton canapé pour la soirée.

Pour en revenir au point de départ, tu peux mettre une validation pour vérifier que la chaine ne contient que des choses correctes : tu disais avoir un modèle du type "/blabla/macategorie/monarticle/page2/edit". Est-ce que tu peux raisonnablement avoir des caractères spéciaux là-dedans ? Si non, tu peux passer un filtre pour virer/encoder tous les caractères spéciaux, parce qu'ils ne sont pas censés être là.

Ensuite pour parser ton URI, tu peux utiliser parse_url() et parse_str().

Re-bonjour et merci à tous pour vos réponses.

Bon, je ne sais pas si vous avez regardé, les liens que j'avais indiqué vers les sites US (forum) qui parlent du sujet, les échanges me semblent mois catégoriques...
Il faut croire que les anglo-saxon sont plus pragmatiques et moins dogmatique que les Latins... et que les variables n'ont pas le même comportement d'un côté ou l'autre de l'océan.

Même sur les forums US les avis divergent, en réalité vous avez raison, cela ne sert a rien de polémiquer 3 jours à savoir si c'est sur ou pas sur...

car ceux qui affirment que c'est une Valeur SURE n'en savent surement rien et en tout cas pas plus que ceux qui disent qu'elle n'est pas SURE. Si elle était vraiment si sure que cela -> cela se serait plus explicitement énoncé dans le documentation et ces interrogation n'aurait pas lieux... Si on se pose la question et que la réponse n'est pas évidente, c'est qu'il y a un doute... qui dis doute dit de vérifier...


Toute le monde semble penser la même chose, donc ok pour vérifier cette fameuse variable.

On a dit PLUS VERIFIER que FILTRER

- Donc vérifier QUOI ?

1°) Qu'elle existe ?
2°) Qu'elle ne contient pas de Caractères pouvant générer un Bug -> soit en PHP / Javascript / Mysql

- SI j'utilise PHP (ça tombe bien), je fois Transformer et ou supprimer les caractères dangereux.
- Même si je N'utilise PAS Javascript sur mon site, je fois Transformer et ou supprimer les caractères dangereux.
- Si j'utilise MySQL je dois Transformer et ou supprimer des caractères spécifiques à MySQL

Citation:

---

filter_input( INPUT_SERVER , 'REQUEST_URI' , FILTER_SANITIZE_URL )

---

Filter_input va gérer la question (1) -> si le filtre échou elle retourne FALSE ou NULL si la variable n'existe pas.


Pour la question (2) Le filtre FILTER_SANITIZE_URL supprime tous les caractères URL illégaux d'une chaîne.
Ce filtre autorise toutes les lettres, chiffres et $ -_. +! * '(), {} | \\ ^ ~ [] `"> <#%; /?: @ & =

Pour arriver a taper un caractère interdit va falloir faire des combinaisons avec les mains et les pieds sur le clavier.... car si je peux taper des lettres, des chiffres et aussi $ -_. +! * '(), {} | \\ ^ ~ [] `"> <#%; /?: @ & = la question inversé est... Que faut-il taper pour ne pas passer le filtre; il bloque quoi ???? il ne bloque rien -> il encode juste les caractères c'est ça ???

Pourtant, on a dit que le Filtre fait une VÉRIFICATION. Je commande des chaussures bleu -> je vérifie que j'ai des Chaussures bleu. Si elles ne sont pas bleu c'est pas bon la VERIFICATION est rejetée.

Alors que la, j'ai l'impression que c'est plutôt. Je commande des chaussures bleu -> je vérifie que j'ai des Chaussures bleu. Si elles ne sont pas bleu c'est pas grave je les repeints en bleu.

Au final j'ai vérifié si la valeur existe -> puis transformé encodé certains caractères dangereux -> mais je n'ai rien rejeté (je prend tout, je transforme tout, mais rien ne se perd...) donc au final tout le monde passe la vérification. C'est ni un filtre, ni un vérificateur c'est un transformateur...

PS : je prend le forum comme un lieu d'échange discussion, et de compréhension... du coup cela peux sembler étrange par rapport à des messages plus brefs qui n'attend qu'une réponse technique : 'combien font 1+2' -> 'salut la solution est 3' -> 'Merci : problème résolu' -> 'je déterre le sujet c'est aussi 1+1+1'

Je ne suis pas sur le forum pour avoir une réponse technique (une solution), mais plus pour comprendre les raisonnement et cheminements...

Houlà....

A mon avis, tu as un petit vélo dans la tête, qui a dû pédaler toute la nuit...
Change de braquet, et arrête de te/nous la prendre (la tête).