Discussion :

[foufou.foufou]

Bonjour,

1- j'ai entendu parler de l'injection HTTP, je ne sais pas comment je peux me protéger contre ce type d'injection. (par exemple pour les injections sql, je sais que je dois vérifier les données avant de les utiliser dans une requete, mais pour l'injection http je ne sais pas comment faire)

2- Je veux rediriger le client apres le remplisage d'un formulaire vers une autre page, Est ce que l'utilisation de la fonction

Code :

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

header('Location: http://www.example.com/page2.php')

est sécurisée ???
Qu'est ce que je dois faire pour la sécuriser.
Et ce que la redirection est sûre ou dépend de la configuration du navigateur du client. Est ce que le client peux configurer son navigateur pour désactiver les redirictions utilisant la fonction HEADER(...)

Merci beaucoup d'avance

[nosferapti]

le problème d'injection peut arriver si tu envoies un entête qui contient une donnée saisie par un visiteur du site et que tu ne contrôles pas

par défaut la fonction "header" à une sécurité qui fait que l'entête n'est pas envoyé si l'argument passé à la fonction contient un saut de ligne. ça empêche les injection les plus fâcheuses mais il faut quand même vérifier les données saisies

[foufou.foufou]

Merci beaucoup,
Comme ça la moitié de mes problèmes sont résolus, il reste à savoir est ce que la redirection est sûre ou dépend de la configuration du navigateur du client. Est ce que le client peut configurer son navigateur pour désactiver les redirictions utilisant la fonction HEADER(...)

[sabotage]

Quel problème serait posé dans ton code si l'utilisateur n'etait pas redirigé ?

[nosferapti]

Merci beaucoup,
Comment ça la moitié de mes problèmes sont résolus, il reste à savoir est ce que la redirection est sûre ou dépend de la configuration du navigateur du client. Est ce que le client peux configurer son navigateur pour désactiver les redirictions utilisant la fonction HEADER(...)

zut, j'ai lu ton 1er message trop vite, je n'avais même pas vu que tu avais posé cette question

l'entête de redirection fait partie des renseignements envoyés au client HTTP donc ensuite le client a tout à fait le choix de ne pas suivre cette redirection.

en quoi cela te gêne-t-il ?

[foufou.foufou]

En quoi cela me gêne-t-il ? Quel problème serait posé dans mon code si l'utilisateur n'était pas redirigé ?
Si l'utilisateur n'était pas redirigé ça touche l'efficacité de mon site.

Dans le manuel php j'ai trouvé ceci :
<< L'appel à la fonction header('Location:...'), non seulement il renvoie un en-tête au client, mais, en plus, il envoie un statut REDIRECT (302) à Apache. Du point de vue de l'auteur de script, cela importe peu, mais pour ceux qui connaissent les rouages internes d'Apache, c'est primordial.>>

Est cela signifie que l'appel à la fonction Header force Apache à rediriger le client, ou tout simplement il lui informe qu'il y a eu une redirection?

Est ce qu'il y a un parametre dans firefox ou internet explorer que l'utilisateur risque de modifier pour ne pas suivre les redirections?

Comment le client peut choisir de ne pas suivre la redirection?

[sabotage]

Si l'utilisateur n'était pas redirigé ça touche l'efficacité de mon site.

Ce n'est pas l'efficacité de ton site qui change, c'est la navigation de l'utilisateur qui aurait choisi étrangement de ne pas suivre les redirections.

Pour ton autre question, comme il est bien indiqué dans la phrase que tu cites, header/location renvoit un en-tête au client (qui en fait ce qu'il veut).

[foufou.foufou]

J'ai trouvé une option dans firefox :
Outils --> Options --> Onglet Avancé/Général et cocher la case "Prévenir lorsque des sites Web tentent de rediriger ou de recharger la page"

j'ai testé une page qui me redirige vers une autre page (en utilisant la fonction header('location:...') mais firefox ne me prévient pas lors de la redirection.

Apres les testes, j'ai remarqué que firefox me prévient que si j'utilise la redirection utilisant une balise meta dans l'entete de la page, comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
<html>
  <head>
    <title>Redirection en htm</title>
    <meta http-equiv="refresh" content="3; URL=http://www.manouvelleadresse.com">
  </head>
  <body>
    Redirection vers www.manouvelleadresse.com dans 3 seconde.
  </body>
</html>

Voici mon raisonnement :
la fonction header('location:...') est appelé dans le code php, c'est à dire elle s'execute dans le code php, et le code php s'execute coté serveur, donc la redirection sera coté serveur tout à fait comme la redirection qui se fait par les fichier htaccess lors de l'utilisation du technique de l'URL rewriting. Donc l'utilisateur ne peut pas empécher la redirection lorsqu'elle se fait par la fonction header('location:...').

Est ce que mon raisonnement est juste???

Please help

[RunCodePhp]

Est ce que mon raisonnement est juste???

Dans l'ensemble, tout à fait.
En faite, on parle de redirection, c'est pour le dire simplement, et en général on se comprend.
Mais c'est pas tout à fait ça, car il n'y a pas de redirection de manière physique (si on peu dire), mais c'est une redéfinition de l'entête, celle du départ (celle que l'utilisateur à demander, la requête HTTP que le serveur à reçue au départ) par une autre, le contenu du header().

De plus, c'est bien plus sécurisé car tout ce fait coté serveur.
A l'inverse, les redirections faites par les <meta refrech /> font physiquement 1 aller/retour entre le serveur et le client, c'est autant de temps et de traitements gaspillés. Rien que pour ça j'estime que cette technique est une daube ... ça date de l'antiquité, faut oublier ça, ça sert à rien. Enfin, c'est mon avis

Cependant, et quand on fait un header(), on le fait dans la plus grande majorité des selon des conditions, des alternatives.
SI machin_truc -> header()
SINON on fait autre chose

Donc si l'information qu'on a reçu au départ comporte une injection HTTP, il y a toujours un risque qu'on propose une mauvaise redirection.
La pire, c'est de proposer un contenu qui normalement devrait être protégé (par une identification par exemple).
D'où l'intérêt de toujours vérifier les données entrantes (GET POST SESSION).

Et puis comme dit Sabotage, faut mesurer les risques qu'il y aurait lors d'une redirection.
Si la redirection mène vers une page de pure consultation, le risque est (théoriquement) faible.
Si la redirection mène vers une page qui aurait comme action de supprimer un contenu, le risque est fort. Ici, on peu se poser la question si faire une telle redirection est judicieux. Faudrait peut être faire autrement.


A savoir que l'URL rewriting n'a rien avoir avec une redirection, à part que ça se passe coté serveur.
Enfin, oui et non en faite. Disons qu'il faut distinguer les redirections pure (comme les redirection 301) et la réécriture de page dynamiques.
La réécriture c'est une sorte de subterfuge qui permet la création de liens uniques et sans paramètres selon des règles, qui vont permettre de recréer les paramètres afin de retrouver la page concernée.
C'est un mécanisme qu'on met en place à cause des moteurs de recherches qui n'apprécient pas les liens/pages dynamiques, les considérant comme de la duplication de contenu.
(casse co(q)uilles ces moteurs )
Ici, il n'y a pas de redirection, c'est bel et bien la bonne page qui est demandée, il n'y a pas de redéfinition au niveau de l'entête.

[nosferapti]

Est ce que mon raisonnement est juste???

nous avons déjà répondu à la question et la réponse est "non" :

l'entête de redirection fait partie des renseignements envoyés au client HTTP donc ensuite le client a tout à fait le choix de ne pas suivre cette redirection.

header/location renvoit un en-tête au client (qui en fait ce qu'il veut).

si tu veux qu'on t'aide, il faudra que tu nous montre un exemple concret où le fait de ne pas suivre la redirection pose problème dans ton site

[RunCodePhp]

nous avons déjà répondu à la question et la réponse est "non" :

Et pourquoi donc ?

Pour ma part le raisonnement évoqué en dernier est juste, quand bien même qu'on ne peux garantir qu'un header() soit totalement sécurisé. Ca dépend de l'URL qu'il contient.
N'empêche que ce sera toujours mieux qu'une redirection faite part une <meta>.


A coté de ça, sans code, difficile d'apprécier

[foufou.foufou]

Merci beaucoup à tous,
Je suis entrain de developper un code qui permet d'enchainer la validation de n formulaires.

Prenons l'exemple de 4 formulaires enchainés :
->après la validation du 1er formulaire l'utilisateur se redirige (à l'aide de la fonction header) vers le 2eme formulaire
->après la validation du 2eme formulaire l'utilisateur se redirige (à l'aide de la fonction header) vers le 3eme formulaire
->après la validation du 3eme formulaire l'utilisateur se redirige (à l'aide de la fonction header) vers le 4eme formulaire
->après la validation du 4eme formulaire l'utilisateur se redirige (à l'aide de la fonction header) vers une page qui affiche le résultat final.

A noter que qu'il s'agit de n formulaires différentes.

Si l'utilisateur choisi de ne pas accepter la redirection utilisant header('location:...') il ne va pas aboutir au résultat. (dans ce cas, je crois que la solution est d'afficher un lien vers la page voulu [vers laquelle la redirection doit se faire])

Jusqu'à maintenant personne ne m'a répondu comment l'utilisateur peut ne pas accepter la redirection utilisant header('location:...') ???

[DevArt]

Il ne peux pas refuser étant donné que la redirection se passe coté serveur, ça lui est absolument invisible.

Je ne vois vraiment pas comment le navigateur pourrai avoir la moindre idée de ce qui se passe sur le serveur (Je me trompe ?).

[RunCodePhp]

Je ne vois pas pourquoi ce genre de truc te tracasse autant.

Pour ce qui est qu'un utilisateur (poste client) refuse la redirection faite par un header(), théoriquement il ne peux pas la refuser, car à juste titre, c'est un mécanisme coté serveur. Le poste client n'est pas au courant de se qu'il s'y passe.

Ca reste néanmoins théorique, car en admettant que l'utilisateur clique sur le bouton submit, et qu'immédiatement il clique sur "Arrêter le chargement de la page" que propose tout navigateur, c'est une manière de refuser le contenu qu'il vient de demander (ou plutôt prévu de lui proposer).
Au même titre que de fermer l'onglet ou son navigateur.
Idem, il peut très bien ne pas faire chaque étape que tu as prévu, comme s'arrêter à la deuxième ... te planter là, et puis s'en aller faire ses courses.

Donc de toute manière, tu n'est pas maitre du jeu dans cette affaire, c'est à toi de faire avec.


C'est quoi le vrai problème dans cette affaire ?

[foufou.foufou]

C'est quoi le vrai problème dans cette affaire ?

Moi je ne peux utiliser une fonction (comme par exemple header('location:...')) que si je la maîtrise à 100%.

Pour ton autre question, comme il est bien indiqué dans la phrase que tu cites, header/location renvoit un en-tête au client (qui en fait ce qu'il veut).

l'entête de redirection fait partie des renseignements envoyés au client HTTP donc ensuite le client a tout à fait le choix de ne pas suivre cette redirection.

D'apres RunCodePhp le client n'a pas le choix de ne pas suivre la redirection fait avec header('location:...').

Ce que je comprend maintenant est :
- L'entete n'est envoyé qu'apres l'execution de la page cible.
- L'entete envoyé au client est seulement pour que le client sait l'url de la page qui a été affichée sur son navigateur.(on va pas comme meme afficher le résultat d'une page avec une url d'une autre)

Est cela est juste???

[sabotage]

header() provoque l'envoi au client d'un en-tête HTTP.
Dans le cas d'un header(Location), l'en-tête dit au client qu'il doit se rendre à l'adresse indiquée (code 302 - redirection temporaire).

Après, je peux avoir mal compris, mais toutes mes lectures et constatations vont dans le même sens.

[foufou.foufou]

header() Dans le cas d'un header(Location), l'en-tête dit au client qu'il doit se rendre à l'adresse indiquée (code 302 - redirection temporaire).

Merci beaucoup, comme ça c'est claire , donc il suffit de comprendre le fonctionnement de la redirection 302.

il me reste à savoir juste une seule choses. est ce qu'il y a une option dans les navigateurs qui empêche les redirections de code 302.

Merci

[sabotage]

Tu abordes ton problème par le mauvais bout.
Il ne faut pas se demander si les navigateurs le permettent ; le fait que ce soit techniquement réalisable est suffisant.

C'est un peu comme le referer : des sites basent leur securité sur le fait que dans les navigateurs on ne puisse pas spécifier le referer.
Malheureusement pour eux, modifier le referer reste un jeu d'enfant.

[RunCodePhp]

il me reste à savoir juste une seule choses. est ce qu'il y a une option dans les navigateurs qui empêche les redirections de code 302.

Personnellement, j'en sais rien.
Mais en quoi cela est important ?
Toujours est il que le post client peux très refuser un domaine, ou une page, un ensemble de page, ce qui reviendrait pratiquement au même.
A même titre que la personne peux quitter le site quand il veux, il n'y donc pas besoin d'avoir un mécanisme coté client pour qu'un personne interrompre un cycle prévu dans un site Web.


Pour ma part, tu recherche les cas ou une intervention de ta part (coté serveur) serait vu comme douteux coté client, ce qui aurait pour effet d'interrompre un cycle.
A ma connaissance, une redirection (que je qualifierais de classique) n'est pas un mécanisme douteux, donc il n'y a pas à se torturer l'esprit sur ce point.


Si tu estime malgré tout ta façon de procédé un peu risquée, et bien pourquoi ne pas procéder de manière inverse.
C'est à dire, (dans ton cas), qu'au lieu de faire recharger la même page au niveau du formulaire (l'url de l'attribut action) et ensuite faire une redirection pour proposer le contenu du formulaire de la page (étape) suivante ...
et bien faire autrement :
De mettre le nom de la page suivante (étape suivante) dans l'url du formulaire, ce qui évite de faire une redirection, donc plus de problème de 302.
La page demandée correspondra à l'entête et contenu demandée.
Par contre, si le contenu obtenu par le serveur suite au submit semble incorrecte (genre 1 champ non rempli), et bien ça sera le seul cas où une redirection vers la même page (la page précédente en faite) devra être effectué, ce qui serait théoriquement moins problématique.
Enfin, dans le sens où tu considère qu'une redirection soit un problème.
(je sais pas si j'ai bien expliqué).

Une autre technique consisterait à faire tout le temps recharger la même page, et ça pour toutes les pages (étapes), tous les formulaires.
Tout tient sur des include des page (ou formulaire) selon l'étape qui est a réaliser.
Plus l'ombre d'une redirection vu que c'est la même page à chaque fois.
Tout tient sur les vérifications qui devront être réaliser au tout début, et ensuite, et selon le cas, proposer le contenu (formulaire) adapté.


Ceci dit, on s'éloigne tout de même pas mal du sujet du départ, qui était l'injection HTTP.

[foufou.foufou]

J'ai pu comprendre beaucoup de choses,
Je vous remercie tous.