Aide pour affichage disponibilites

Bonsoir,

Utiliser $_POST au lieu de $_REQUEST permet de s'assurer que les
données sont transmises dans des circonstances normales
Non. Il permet de détecter *certaines tentatives de transmission

anormale*. Pas toutes, ce serait trop simple (donc s'il en reste,
pourquoi se fatiguer vu qu'il FAUDRA une AUTRE protection).

Heureusement que vous coupez ma phrase pour dénaturer mon propos.

Je spécifie bien qu'il permet de "s'assurer de la transmission dans des
circonstances normales face aux CSRF" pas qu'il n'y a pas tentative de
piratage.

L'utilisation de $_REQUEST accroit les risques de manière totalement
inutile. C'est encore une des belles inventions des développeurs PHP à
mettre dans le même panier que les deux exemples un peu plus bas.

pourquoi se fatiguer vu qu'il FAUDRA une AUTRE protection

Qui parle de se fatiguer, il suffit de savoir comment on doit récupérer
les données.

Pourquoi se fatiguer à utiliser $_REQUEST, $_GET ou $_POST d'ailleurs
quand on peut mettre en register_global à on ?
Pourquoi se fatiguer à vouloir utiliser des fonctions d'échappement
alors qu'il suffit de régler en magic_quotes_gpc à on ?

Tout simplement pour augmenter la sécurité et que de toute façon une
seule protection ne suffit jamais.

C'est bien la flemme de certains développeurs qui a amené aux deux
aberrations précédentes.

et pas une tentative de CSRF.
http://shiflett.org/articles/security-corner-dec2004
Oui et ? A part rajouter un token en plus du session_id (et puis

pourquoi pas un token2 et un token3, des fois qu'on ait deviné le
premier puis le second) qu'est-ce que cet article indique ?

Relisez l'article, je crois que vous n'avez pas bien compris le principe
ni des CSRF ni de l'utilisation du token dans ce cas précis.

<CITE>
[le code qui est envoyé par l'image]
Every user that visits this page sends a request to example.org just as
if the user clicked a link to the same URL. Because the sample
application uses $_REQUEST instead of the more specific $_POST, it
cannot distinguish between data sent in the URL from data provided in
the proper HTML form.
</CITE>
BFD ! (big furry deal). C'est surtout parce qu'on ne vérifie pas que
cette requête est valide (i.e. cette personne a le droit de l'exécuter)
que le risque est là.

Vous montrer là une bien mauvaise connaissance des CSRF. L'envoi des
données et bel et bien valide et les droits de la personne aussi ( id,
de session, cookie etc ... ) puisque la requête est envoyée par la bonne
personne avec les bons droits et c'est le but de la méthode.

<CITE>
POST requests can also be forged, so do not consider a strict use of
$_POST to be sufficient protection.
</CITE>

Jamais dit le contraire.

Donc C.S. fait partie des gens qui considèrent que tout ce qui permet de
mettre des batons dans les roues à l'attaquant est bon à prendre, quel
que soit le coût en maintenance et complexification du code (dont il ne
parle pas d'ailleurs).
Moi je considère que quand ça m'oblige à modifier
mon code toutes les 5 minutes parce qu'on golio (cf plus bas) change
d'avis comme de chemise et qu'en plus la "protection" se contourne en 3
secondes, ça ne vaut pas le coup de s'emmerder.

Toutes les méthodes de protection sur le web sont contournables en moins
de 3 secondes, c'est bel et bien la combinaison des techniques qui fait
que la sécurité est accrue ( et surtout pas absolue ), c'est directement
lié aux spécificités du protocole HTTP.

Quand à la complexification du code, il suffit de réfléchir deux
secondes pour surmonter cette *énorme épreuve*. Je suppose que vous n'en
êtes quand même plus à coder vos formulaires à partir de zéro à chaque
fois mais que vous avez des libs qui vous permettent des les générer et
d'en valider les entrées.

De plus je ne vois pas l'intérêt de changer des requêtes GET en POST,
l'utilisation de chacune des méthodes étant bien différenciée.
Nous sommes tout à fait d'accord : strictement aucun !! Mais va dire ça

à la @#*! d'agence graphiste qui te fournit 15 versions de la même page
en 3 semaines avec un coup l'un, un coup l'autre, et la troisième fois
du JS qui transforme le clic sur une image en POST...

Il suffit de travailler avec des gens qui connaissent leur boulot ( qui
n'utilisent pas GET pour valider des formulaires, qui respectent un
minimum les standards d'accessibilité etc ...) Il y a assez de monde sur
le marché pour ne pas s'encombrer des boulets de ce genre.

Utiliser GET pour envoyer un formulaire ou pour faire autre chose que de
demander un document est une violation du protocole HTTP.

Il est marrant de voir comment vous défendez ce protocole dans certaines
circonstances ( cf le cas rabattu du header Location ) et de voir
comment ça ne vous dérange pas de la violer dans d'autres circonstances.

Le 18/02/2006 09:54, ftc me répondait :

Utiliser $_POST au lieu de $_REQUEST permet de s'assurer que les données
sont transmises dans des circonstances normales et pas une tentative de
CSRF.
http://shiflett.org/articles/security-corner-dec2004

Non, ça ne permet pas de s'en « assurer ».

Si, car un CSRF ne peut se faire que par la méthode GET et que les
données devraient être faites en POST puisque c'est une action d'envoi
de données.

Tu reprochais à John Gallet de couper une partie de ta réponse, mais je
peux te faire le même reproche. J'avais complété ma remarque de :

<cit.>
Si tu peux modifier le code HTML pour y mettre une image, tu peux tout
aussi bien y mettre un formulaire avec tous les champs cachés, et validé
en JavaScript.
</cit.>

En gros, à tous les endroits où tu peux faire un CSRF en GET au moyen
d'une image, tu peux tout aussi facilement faire un CSRF en POST au
moyen de JavaScript. Tu pourrais m'objecter que tout le monde n'a pas
JavaScript, mais la proportion est quand même suffisamment forte.

Tu reprochais à John Gallet de couper une partie de ta réponse, mais je
peux te faire le même reproche. J'avais complété ma remarque de :

<cit.>
Si tu peux modifier le code HTML pour y mettre une image, tu peux tout
aussi bien y mettre un formulaire avec tous les champs cachés, et validé
en JavaScript.
</cit.>

En gros, à tous les endroits où tu peux faire un CSRF en GET au moyen
d'une image, tu peux tout aussi facilement faire un CSRF en POST au
moyen de JavaScript. Tu pourrais m'objecter que tout le monde n'a pas
JavaScript, mais la proportion est quand même suffisamment forte.

Personne ne parle de modifier le code HTML pour y mettre une image, les
CSRF sont des attaques à partir de sites autres que les sites visés ou à
partir d'email.

Les restrictions de Javascript ne permettent pas d'invoquer un élément
qui ne se trouve pas sur le même domaine, je ne vois donc pas trop
comment ce serait possible.

Pour faire un CSRF, il faut pouvoir contacter un autre domaine à l'insu
de l'utilisateur.

En gros, à tous les endroits où tu peux faire un CSRF en GET au moyen
d'une image, tu peux tout aussi facilement faire un CSRF en POST au
moyen de JavaScript. Tu pourrais m'objecter que tout le monde n'a pas
JavaScript, mais la proportion est quand même suffisamment forte.

Personne ne parle de modifier le code HTML pour y mettre une image, les
CSRF sont des attaques à partir de sites autres que les sites visés ou à
partir d'email.

Il n'est pas modifié, le code HTML, pour y inclure cette balise <img>
contre laquelle tu veux te protéger en vérifiant qu'on fait bien un POST
et pas un GET ?

Bon, peu importe les mots employés : si un code HTML peut contenir un
<img src="xxx?var=truc"> où xxx est la ressource à attaquer, il peut
aussi bien contenir :
<form action="xxx" method="post" id="le-formulaire">
<input type="hidden" name="var" value="truc">
...
</form>
N'est-ce pas ?

Et il peut aussi contenir un code JavaScript qui fait un
getElementById("le-formulaire") et qui déclenche le submit,
n'est-ce pas ?

En quoi est-ce si difficile ?

Les restrictions de Javascript ne permettent pas d'invoquer un élément
qui ne se trouve pas sur le même domaine, je ne vois donc pas trop
comment ce serait possible.

Tu veux parler de XMLHttpRequest, peut-être. Mais un simple formulaire
tel que celui ci-dessus, il n'a pas le droit de faire des requêtes sur
un autre domaine ?

Pour faire un CSRF, il faut pouvoir contacter un autre domaine à l'insu
de l'utilisateur.

C'est d'accord.

Utiliser $_POST au lieu de $_REQUEST permet de s'assurer que les données
sont transmises dans des circonstances normales et pas une tentative de
CSRF.
http://shiflett.org/articles/security-corner-dec2004

Vous citez bizarrement. Voici ce que dit l'article:
There are a few steps you can take to mitigate the risk of CSRF attacks.
Minor steps include using POST rather than GET in HTML forms that perform
actions, using $_POST instead of $_REQUEST

Puis plus loin sont citées les vraies bonnes solutions (avec le token,
mais on peut penser à bien d'autres choses encore).

Donc l'article que vous utilisez ne va pas du tout dans votre sens.
Utiliser $_POST à la place de $_REQUEST c'est le genre de sécurité
saupoudrée en fin de projet, de la poudre de perlinpinpin qui ne résout
rien...

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Bon, peu importe les mots employés : si un code HTML peut contenir un
<img src="xxx?var=truc"> où xxx est la ressource à attaquer, il peut
aussi bien contenir :
<form action="xxx" method="post" id="le-formulaire">
<input type="hidden" name="var" value="truc">
...
</form>
N'est-ce pas ?

Et il peut aussi contenir un code JavaScript qui fait un
getElementById("le-formulaire") et qui déclenche le submit,
n'est-ce pas ?

En quoi est-ce si difficile ?

OK, 1 point ;-)
Je présupposais que le navigateur envoyait une alerte en cas de
soumission d'un formulaire via post et javascript sur un autre domaine.

Cependant, il y a deux restrictions à la méthode:

1) il faut que le visiteur aille sur le site ou est présent le code ou
bien que le code soit injecté sur un autre site. C'est quand même plus
facile de laisser trainer le code d'une image que d'injecter un
formulaire et du code javascript.

2) il faut que javascript puisse être invoqué, ce qui est rarement le
cas des lecteurs de mail ( vecteur principal des tentatives de CSRF ).

Mais ma conclusion ne change pas, a quoi bon laisser une porte grande
ouverte à part vouloir attirer les script kiddies.

Ce genre de protection est du même niveau que de cacher la signature du
serveur web, du serveur mail ou de PHP, facilement contournable mais
faisant parti des pré-requis.

En faisant la distinction entre les requêtes POST et GET, on sait déjà
que les variables ne doivent pas subir le même type de traitement, les
données fournies par POST étant par définition ( cf protocole HTTP ) des
données non sûres. Ca ne veut bien sûr pas dire qu'il ne faut pas
filtrer les données fournies par GET, mais que les filtes à appliquer ne
sont pas forcément les mêmes.

Utiliser $_POST au lieu de $_REQUEST permet de s'assurer que les données
sont transmises dans des circonstances normales et pas une tentative de
CSRF.
http://shiflett.org/articles/security-corner-dec2004

Vous citez bizarrement. Voici ce que dit l'article:
There are a few steps you can take to mitigate the risk of CSRF attacks.
Minor steps include using POST rather than GET in HTML forms that perform
actions, using $_POST instead of $_REQUEST

Puis plus loin sont citées les vraies bonnes solutions (avec le token,
mais on peut penser à bien d'autres choses encore).

Je n'ai jamais dit que c'était la seule et unique solution pour s'en
prémunir, c'est juste une précaution de base.

Donc l'article que vous utilisez ne va pas du tout dans votre sens.

Ah bon, je cite:
"This is an intentional mistake that I want to highlight. Using
$_REQUEST unnecessarily increases your risk. In addition, if you perform
an action (such as buying stocks) as a result of a GET request, you are
violating the HTTP specification."

C'est tout à fait ce que je dis non ?

Utiliser $_POST à la place de $_REQUEST c'est le genre de sécurité
saupoudrée en fin de projet, de la poudre de perlinpinpin qui ne résout
rien...

Je dirais que c'est plutôt le genre de chose que l'on doit faire en
début de projet, tout comme toutes les autres solutions pour se prémunir
des différentes failles potentielles. C'est bien parce que la sécurité
n'est souvent prise en compte qu'en fin de projet ( pour différentes
raisons dont la flemme du développeur est souvent la cause principale )
qu'on se retrouve avec une floppée de script qui sont de vrais passoires.

Je trouve, comme CS d'ailleurs, que l'utilisation de $_REQUEST accroit
le risque de façon totalement inutile. L'utilisation de $_POST à la
place de $_REQUEST permet quand même de se libérer de tout un tas de
problèmes.

La soumission d'un formulaire via POST est plus compliquée à faire à
l'insu de l'utilisateur que l'utilisation d'un web bug, surtout
lorsqu'il s'agit d'un email ( sans doute 90% des cas de tentatives de
CSRF ).

Bonjour,

Heureusement que vous coupez ma phrase pour dénaturer mon propos.
Eh, ho, on n'est pas sur fufe ici hein. Si j'ai coupé la phrase ici

c'est parce que, à mon sens, quel que soit le type d'attaque, entre
autres les CSRF-rasxyz et tutti-quanti, l'attaquant aura autant la
possibilité d'envoyer ses données par get que par post.

Je spécifie bien qu'il permet de "s'assurer de la transmission dans des
circonstances normales face aux CSRF" pas qu'il n'y a pas tentative de
piratage.
Et bien je ne vois pas pourquoi dans le cas spécifique de cette attaque,

l'attaquant ne pourrait pas envoyer aussi simplement ses données par
POST que par GET. S'il y a une raison technique qui m'échappe, merci de
me la signaler.

L'utilisation de $_REQUEST accroit les risques de manière totalement
inutile.
La vérification de la méthode de transmission ne sert à rien.

C'est encore une des belles inventions des développeurs PHP
Je crois que ce n'est pas spécifique à PHP.

Qui parle de se fatiguer, il suffit de savoir comment on doit récupérer
les données.
Sur chaque interface publique du site.

Pourquoi se fatiguer à utiliser $_REQUEST, $_GET ou $_POST d'ailleurs
quand on peut mettre en register_global à on ?
C'est une excellente question à laquelle j'ai une réponse toute prête et

d'ailleurs le gars qui a écrit PHP aussi :
Le 1er octobre 2002 je disais ceci :
http://groups.google.com/group/fr.comp.lang.php/msg/13e64e15d2d8f24e

Et j'avais déjà dû sortir le même couplet sur fciwap, mais je n'ai pas
retrouvé en recherche rapide. En gros : register_globals en Off, c'est
de la connerie.

Et le gars qui a écrit le langage, de son côté, dit ceci :

http://www.sitepoint.com/article/phps-creator-rasmus-lerdorf/3

Kevin Yank -- May 22nd 2002

SP: What are your views on Magic Quotes and Register Globals?

RL: Register Globals is one of the features that brought people to PHP.
The simplicity of creating Web applications when form and other
variables were automatically available could not be beaten.
I was personally not in favour of turning Register Globals off by
default. It adds very little to the overall security of an application.
If people do not check data coming from the user then with or without
Register Globals enabled that application is going to be insecure.
The only time having Register Globals off helps is when you forget to
initialize a variable before you use it and someone who knows your code
exploits that. By changing the error reporting level you can have PHP
find these cases for you automatically. So in the end, all I think
turning Register Globals off has done is make writing PHP apps more
complicated.

And it has of course also generated 10-20 questions/bug reports per day
from users who are confused about this change.

Pourquoi se fatiguer à vouloir utiliser des fonctions d'échappement
alors qu'il suffit de régler en magic_quotes_gpc à on ?
Je ne vois pas le rapport avec le reste ? Mais je citerai aussi le gars

Rasmus :

The clueful who don't like this feature can simply turn it off and
handle all escaping themselves. And the clueful who write portable apps
can simply check the setting using get_magic_quotes_gpc() and add an
addslashes() call when appropriate.

(et merci de m'éviter le couplet sur le fait que l'échappement d'une '
n'est pas toujours , je sais).

C'est bien la flemme de certains développeurs qui a amené aux deux
aberrations précédentes.
On est bien d'accord.

Relisez l'article, je crois que vous n'avez pas bien compris le principe
ni des CSRF ni de l'utilisation du token dans ce cas précis.
C'est **tout à fait possible**. Mais je pense qu'alors je ne suis pas le

seul sur ce forum dans ce cas et qu'il serait bon que ledit article
*justifie* ses choix. Mon impression est qu'il s'agit, comme pour
register_globals, d'une mauvaise solution à un vrai problème : comme la
gestion de session utilisée est basée sur des cookies, une attaque peut
voler l'id_session et donc on se sent obligé de rajouter son équivalent
strict en rôle mais dans une variable HIDDEN. La solution était surtout
de ne pas utiliser les cookies (depuis le temps qu'on le rabâche).

Vous montrer là une bien mauvaise connaissance des CSRF. L'envoi des
données et bel et bien valide et les droits de la personne aussi ( id,
de session, cookie etc ... ) puisque la requête est envoyée par la bonne
personne avec les bons droits et c'est le but de la méthode.
Alors dans ce cas, ce n'est pas de rajouter un token qui changera quoi

que ce soit car s'il est transmis en get/post, l'id_session ou le token,
même combat. Le problème est plutôt que l'ajout de l'id_session est
automatique.

<CITE>
POST requests can also be forged, so do not consider a strict use of
$_POST to be sufficient protection.
</CITE>
Jamais dit le contraire.

Alors en quoi est-ce que vérifier que la requête http est bien du POST
est ***suffisant*** pour se protéger de ce type d'attaque ?

Toutes les méthodes de protection sur le web sont contournables en moins
de 3 secondes,
Un id_session aléatoire de 40 chars de long non stocké dans un cookie ça

se pirate en 3 secondes ? Va falloir qu'on se fasse du soucis.

Je suppose que vous n'en
êtes quand même plus à coder vos formulaires à partir de zéro à chaque
fois mais que vous avez des libs qui vous permettent des les générer et
d'en valider les entrées.
Mauvaise supposition, changer de supposition. Quand on arrive chez un

client sur une appli web qui tourne depuis 5 ans, on commence pas par
dire "les mecs, vot' truc c'est de la merde, il vous faut *mes* libs".

Il suffit de travailler avec des gens qui connaissent leur boulot ( qui
n'utilisent pas GET pour valider des formulaires, qui respectent un
minimum les standards d'accessibilité etc ...) Il y a assez de monde sur
le marché pour ne pas s'encombrer des boulets de ce genre.

Cette boutade est rafraîchissante de naïveté, on croirait entendre un
stagiaire au cours de sa première semaine en entreprise. Il va de soit
en effet qu'à chaque fois que j'arrive sur un projet, je commence par
faire la liste des autres prestataires et que le soir du premier jour je
dis à mon client "tous ceux là c'est des cons faut les virer". Et quand
en face de mes équipes j'ai un grand compte qui peut acheter ma boite ou
celle de mon client au petit déjeuner, je lui répond "tes équipes c'est
des brêles, change les moi". Réveil !!

Utiliser GET pour envoyer un formulaire ou pour faire autre chose que de
demander un document est une violation du protocole HTTP.
Oui et ? D'ailleurs, puisque ce protocole est aussi bien fait que ça,

pourquoi peut-on spécifier l'attribut METHOD dans un tag FORM ? Et
pourquoi par défaut est-il à GET si non spécifié ? Je crains qu'il n'y
ait beaucoup de violeurs "à l'insu de leur plein gré"...

Il est marrant de voir comment vous défendez ce protocole dans certaines
circonstances ( cf le cas rabattu du header Location ) et de voir
comment ça ne vous dérange pas de la violer dans d'autres circonstances.

Qu'est-ce que ce que je (entre autres) dis de header(Location) vient à
faire avec le respect du protocole ? Je m'engage à vous envoyer une
bouteille de champagne si vous arrivez à trouver dans un article écrit
par moi depuis que je fréquente les newsgroups (c'est à dire fin 1996)
où j'ai fait une quelconque allusion au "respect du protocole http" ou à
une RFC quelconque pour justifier un point technique (1). Je m'en fout
des specs du protocole http (dont un certain nombre sont encore marquées
"experimental" depuis 1997...) d'ailleurs je ne les ai jamais lues et
c'est pas demain la veille que je les lirai.

JG

(1) à part pour râler contre les @!*# de firewalls qui coupent les
sockets sans respecter la séquence SYN/ACK correcte, mais ce n'est pas
du http.

Re,

2) il faut que javascript puisse être invoqué, ce qui est rarement le
cas des lecteurs de mail ( vecteur principal des tentatives de CSRF ).
(je croyais qu'OE appliquait les mêmes paramètres qu'IE ? Enfin peu

importe).

Mais ma conclusion ne change pas, a quoi bon laisser une porte grande
ouverte à part vouloir attirer les script kiddies.
Etant donné qu'on ne peut pas se contenter de fermer la porte mais qu'il

faudra de toutes façons un chien de garde derrière...

Ce genre de protection est du même niveau que de cacher la signature du
serveur web, du serveur mail ou de PHP, facilement contournable mais
faisant parti des pré-requis.
A ceci près qu'ils sont totalement transparents pour le développeur.

100%. Tiens ça me fait penser qu'il faut que je rajoute l'url d'un
plugin nessus pour le fingerprinting sur ces deux critères.

En faisant la distinction entre les requêtes POST et GET, on sait déjà
que les variables ne doivent pas subir le même type de traitement, les
données fournies par POST étant par définition ( cf protocole HTTP ) des
données non sûres.
La douleur vous égare. ***Toutes*** les données venant du monde

extérieur, que ce soit en get, post ou cookie, sont par définition des
données non sûres (ainsi que tout ce qui est soit disant fournit par le
navigateur comme le user-agent ou remote_addr, etc.)

Ca ne veut bien sûr pas dire qu'il ne faut pas
filtrer les données fournies par GET, mais que les filtes à appliquer
ne sont pas forcément les mêmes.

Ca me parait dangereux intrinsèquement. Par curiosité, quelles
différences pourrions nous envisager en se basant exclusivement sur ce
critère ?

JG

Je n'ai jamais dit que c'était la seule et unique solution pour s'en
prémunir, c'est juste une précaution de base.

C'est une précaution qui ne sert strictement à rien, bref c'est du temps
perdu. Autrement dit cela donne peut-être (à ceux qui ne comprennent pas
ce qu'ils font/ce qui se passe, et qui font des copier coller de ce qu'ils
ont vu ailleurs) un *sentiment* de sécurité, et non une meilleure
sécurité.
Un sentiment de sécurité est encore pire que pas de sécurité.

Utiliser $_POST à la place de $_REQUEST c'est le genre de sécurité
saupoudrée en fin de projet, de la poudre de perlinpinpin qui ne
résout rien...

Je dirais que c'est plutôt le genre de chose que l'on doit faire en
début de projet,

Faire de la vraie sécurité, oui, pas de la mystification comme il est
proposé.

De la vraie sécurité, c'est comprendre pourquoi certaines données sont
dangereuses, et les manipuler correctement, et comprendre qu'elles sont
dangereuses quel que soit le canal qu'elles aient empruntées.
Voir autrement, c'est aussi croire qu'un site devient subitement
sécurisé parce qu'il utilise https plutôt que http.

La soumission d'un formulaire via POST est plus compliquée à faire à
l'insu de l'utilisateur que l'utilisation d'un web bug,

Si, via une faille, on peut ajouter n'importe quoi dans un document HTML,
et qu'on peut ajouter un web bug, on peut alors aussi ajouter un
formulaire et du javascript. Donc même faille, même attaque, même
niveau de complexité.
Vous pouvez vous amuser à essayer de vous prémunir contre une attaque...
mais si en fait vous ne vous occupez que de 1% du problème, dommage pour
vous.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>