Aucune recuperation des champs du formulaire

Le Mon, 22 Sep 2008 14:53:06 +0000, Olivier Miakinen a écrit:

je trouve que c'est presque mieux d'utiliser $_REQUEST, si
cela incite à vérifier d'autant mieux le *contenu* des variables plutôt
que leur *provenance*.

Tout à fait !
D'autant que leur provenance est connue, elles viennent de l'extérieur, ce
monde hostile qu'est Internet, et donc qu'elles soient transmises en POST
ou en GET, elles sont autant dangereuses, et doivent être traitées
toujours avec la même circonspection.

BTW, cela ne viendrait à l'idée de personne d'avoir 2 méthodes différentes
d'accès au données selon que ce soit un
POST application/x-www-form-urlencoded
ou un
POST multipart/form-data
alors que pourtant les deux sont très différents.

[filter]

Oh, mais c'est génial, ça ! Ça faisait longtemps que John Gallet
regrettait que ça n'existe pas en standard, mais je vois que tout finit
par arriver.

Pour moi ce qui serait encore mieux (peut-être cela existe) c'est
l'équivalent d'un « anti register_global » à la façon du « tainting » en
Perl : la possibilité d'accoler une étiquette « sûr / pas sûr » sur chaque
variable avec un étiquetage automatique « pas sûr » sur toutes les
variables construites directement et déduites d'informations venant de
l'extérieur du programme (donc dans un premier temps le User-agent, puis
aussi éventuellement l'OS/le serveur Web et les sources de données externes
au programme mais internes au système comme les bases de données) et un
interpréteur qui s'arrête immédiatement sur toutes les opérations
dangereuses (open, system, etc.) se faisant avec des variables étiquettées
« non sûr ».



--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>

Patrick Mevzek wrote:

Pour ma part, je considère que c'est une énorme faille que de passer par
$_REQUEST, essentiellement lorsqu'il s'agit de données provenant d'un
formulaire utilisateur.

Si la sécurité d'une application est uniquement basée sur le fait que
c'est un GET plutôt qu'un POST ou le contraire, alors cette application
n'a aucune réelle mesure de sécurité.

Je cherche le mot "uniquement" dans ma réponse. Il s'agit d'un simple
premier pas vers un peu plus de sécurité, et je ne parle pas forcément
de protection contre une attaque quelconque.

En utilisant $_REQUEST, on dépend de l'ordre défini dans variables_order
(par défaut Environment, GET, POST, Cookie, Server) et cela peut
engendrer des soucis de fonctionnement sur un site.

Tous les gens qui croient corriger un problème de sécurité en changeant un
GET par un POST ne comprennent en général pas grand chose au réel problème
de sécurité sous-jacent.

Je recherche aussi le mot "corriger" dans ma réponse.

De nombreux autres frameworks ne font pas de différence entre GET et POST
(à juste raison). Ce qui me gêne davantage c'est la présence de $_COOKIE
dans $_REQUEST, et c'est marrant personne ne le mentionne :-)

Si la majorité avait raison, ça se saurait.


--
Réseau IRC Francophone: http://www.zeolia.net
Aide et astuces webmasters : http://www.c-p-f.org
Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr

Le 22 Sep 2008 14:05:45 GMT, Mickaël écrivait:

Freddy DISSAUX a écrit :

Personnellement, je recommande chaudement l'utilisation de $_REQUEST
pour éviter les mélimélo $_GET/$_POST.

C'est que tu n'as pas compris la différence sémantique entre HTTP GET
et HTTP POST, ni les implications en terme de sécurité que cela implique.

La diférence sémantique entre GET et POST aura une importance le jour on
on aura aussi PUT, DELETE et CONNECT. Pour l'instant, très peu de REST à
l'horizon :)

Quant aux implications en termes de sécurité, qu'une donnée arrive par
GET ou POST, il faut qu'elle soit validée (à coup de filter ou autre)
et à partir de là, utiliser GET&POST / REQUEST n'a plus trop
d'importance.

Avec un heredoc du plus bel effet:

$msg = <<<EOT;
Nom: {$_REQUEST['nom']}
E-Mail: {$_REQUEST['email']}
Message: {$_REQUEST['message']}

EOT;

Comme au bon vieux temps du global_register.

Je me répète, une fois passé le validateur, pas de problème pour moi.

Et on n'hésite pas à utiliser filter: http://fr3.php.net/filter

Certes, la seule bonne idée du message.

Merci.


--
freddy <point> dsx <arobase> free <point> fr

Le 22/09/2008 17:24, CrazyCat a écrit :

Si la sécurité d'une application est uniquement basée sur le fait que
c'est un GET plutôt qu'un POST ou le contraire, alors cette application
n'a aucune réelle mesure de sécurité.

Je cherche le mot "uniquement" dans ma réponse. Il s'agit d'un simple
premier pas vers un peu plus de sécurité, et je ne parle pas forcément
de protection contre une attaque quelconque.

Le mot-clé, c'est « fausse impression de sécurité ». Si on a besoin de
restreindre la lecture des données externes à $_POST pour augmenter la
sécurité, fût-ce d'un millionième de chouia, c'est que le contrôle sur
les valeurs n'est pas suffisant.

En utilisant $_REQUEST, on dépend de l'ordre défini dans variables_order
(par défaut Environment, GET, POST, Cookie, Server) et cela peut
engendrer des soucis de fonctionnement sur un site.

Ça c'est un autre problème, qui n'arrivera que si l'ordre est modifié et
que le programmeur donne un nom identique à, par exemple, un cookie et
une entrée de formulaire. Cela dit, tu as raison, si le cas arrive cela
peut engendrer des bugs (plutôt que des problèmes de sécurité, car là
encore ce n'est pas parce qu'une variable peut être envoyée via un
cookie qu'elle est plus dangereuse que transmise via un post).

Patrick Mevzek a écrit :

Voir à ce sujet les recommandations de l'OWASP (www.owasp.org).

Quelles sont celles qui interdisent l'usage de $_REQUEST ?

Waouhhh...susceptible, l'animal !
Non, rien ne l'interdit, bien sûr, il ne s'agit que de simples
recommandations.
De plus, elles restent discutables, d'où l'objet d'un forum.
Question bête, tant que j'y suis : peut-on utiliser le type REQUEST dans
les fonctions de l'extension "filter" ? ;-)

Patrick Mevzek a écrit :

S'il y a certes une différence sémantique, elle n'a pas à influer sur la
façon de récupérer les paramètres envoyés par l'utilisateur,

Pourquoi, alors que ce sont deux concepts différents ?

et
l'application peut tout à fait savoir par différents moyens si elle est
dans le cas d'un GET ou d'un POST.

Non. Parce que les deux peuvent survenir en même temps.

<form action="article.php?id" method='post'>
<p>
<input type='hidden' name='action' value='delete' />
<!-- la valeur du bouton peut dépendre de la localisation
on utilises donc un champ caché d'action -->
<input type='submit' value='Supprimer'/>
</p>
</form>

Si on considère que $_REQUEST['action'], alors il est possible pour
un attaquant de proposer le lien <article.php?id&actionÞlete> Alors
je suis d'accord que l'internaute devrait faire attention à ce qu'il
clique, mais un mécanisme minimal de sécurité est de considérer
$_POST['action']. Ensuite on peut bien sûr améliorer la sécurité avec un
système de jeton, si vraiment il faut blinder, surtout si les
utilisateurs utilisent un navigateur peut sûr permettant de faire des
requêtes HTTP croisées avec un XHR (et donc de faire le POST qui va bien).

ni les implications en terme de sécurité que cela implique.

Une application dont la sécurité ne dépend que de l'usage d'une méthode
HTTP plutôt que d'une autre est une application sans réelle sécurité.

La sécurité est un ensemble de bonnes pratiques. Par exemple, pour
supprimer un article, il est souhaitable que le paramètre conduisant à
la suppression ne puisse pas être considéré s'il est un HTTP GET. Sinon,
un lien dans un courriel frauduleux, ou dans un site piégé, pourrait
conduire à des suppressions ciblées. C'est le genre de trous qui sont
souvent présents dans les panels d'administration. On considère que
puisqu'il y a un cookie, la requête est légitime, alors que non.

Absolument pas, puisque l'espace de nommage est différent : $toto vs
$_REQUEST['toto']
Aucun risque d'utiliser $_REQUEST['toto'] par inadvertance dans un bout du
code comme variable « locale » (non dépendante de l'extérieure.

J'y vais certes un peu fort. Mais utiliser des données directement
venant de n'importe où me fait toujours sortir de mes gonds.


--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Olivier Miakinen a écrit :

Là je suis d'accord qu'il y a potentiellement un problème si la commande
mail est sensible aux « buffer overflows » ou à l'envoi de caractères de
contrôle dans le corps du message : il faudrait soigneusement vérifier
chaque paramètre. Cela dit, mettre $_REQUEST['email'] dans $msg, c'est
quand même beaucoup moins risqué que de le mettre dans $mailheaders
comme le faisait Guytou77.

La difficulté n'est pas d'envoyer un HTTP GET ou un HTTP POST, mais
de faire en sorte qu'un internaute envoie une requête à l'aide de ces
droits d'accès.



--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Le Mon, 22 Sep 2008 15:24:30 +0000, CrazyCat a écrit:

Pour ma part, je considère que c'est une énorme faille que de passer par
$_REQUEST, essentiellement lorsqu'il s'agit de données provenant d'un
formulaire utilisateur.

Si la sécurité d'une application est uniquement basée sur le fait que
c'est un GET plutôt qu'un POST ou le contraire, alors cette application
n'a aucune réelle mesure de sécurité.

Je cherche le mot "uniquement" dans ma réponse. Il s'agit d'un simple
premier pas vers un peu plus de sécurité,

C'est (presque) pire alors. Croire qu'un tel pas augmente la sécurité
prouve qu'on ne fait pas(!) des pas dans la bonne direction, et il est donc
probable que les suivants soient du même (mauvais) tonneau. En
investissant de l'énergie aux mauvais endroits, a priori, on ne le fait
pas aux bons.

C'est ne pas comprendre le coeur du problème (certes pas trivial), à
savoir le changement de contexte, et que ce n'est pas comment ce
changement intervient qui importe (le transport du contenu) mais sa seule
survenue.

Bref, c'est ne pas avoir, selon moi, le bon état d'esprit pour analyser
les problèmes de sécurité, en particulier sur le web.

et je ne parle pas forcément de protection contre une attaque quelconque.

« énorme faille » se rapporte à quoi alors ?

En utilisant $_REQUEST, on dépend de l'ordre défini dans variables_order
(par défaut Environment, GET, POST, Cookie, Server) et cela peut
engendrer des soucis de fonctionnement sur un site.

Sauf que dans $_REQUEST, il n'y a que GET, POST, et COOKIE, déjà.
De ce point de vue là au moins c'est homogène, on sait que *tout* ce qu'il
y a la-dedans est dangereux, sans exception, et
si on filtre on est sûr de filtrer quel que soit le mécanisme. Alors que
si on décide de ne filtrer que GET ou que POST ou que COOKIE eh bien on
oublie la « big picture » et on se fera avoir un jour au l'autre par une
faille (de sécurité)

Si il y a mélange entre les trois, on a affaire à un problème de sécurité
bien plus grand je pense, juste d'une application mal développée dès le
départ (si elle se prend les pieds avec le nommage de ses variables,
internes ou externes, je pense que ca s'en ressentira rapidement sur les
fonctionnalités et le nombre de bugs). Même si cela peut arriver, je trouve
ce problème bien moindre que de croire que vérifier que REQUEST_METHOD POST solutionne tout (à voir comment un post qui dit le contraire déchaine
les passions avec 3 réponses unanimes dans les 2 heures).
D'autre part on risque de s'en apercevoir (« ca ne marche pas») alors
qu'on croira dormir sur ses 2 oreilles avec son test bidon sur la méthode,
sans penser un seul instant qu'on ne solutionne en réalité pas grand chose.

Tous les gens qui croient corriger un problème de sécurité en changeant
un GET par un POST ne comprennent en général pas grand chose au réel
problème de sécurité sous-jacent.

Je recherche aussi le mot "corriger" dans ma réponse.

Vous vous sentiez visé explicitement par ma phrase alors :-) ?
Ce n'était pourtant pas le but.

Je faisais juste état des fausses bonnes réponses qu'on lit à longueur de
forum ou de pages web...

De nombreux autres frameworks ne font pas de différence entre GET et
POST (à juste raison). Ce qui me gêne davantage c'est la présence de
$_COOKIE dans $_REQUEST, et c'est marrant personne ne le mentionne :-)

Si la majorité avait raison, ça se saurait.

Je cherche le mot « majorité » dans ma réponse.

Mais donc sinon merci de confirmer que la majorité (notamment ici) qui
croit que POST/GET c'est mieux que REQUEST, n'a pas raison :-)

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>

Le Mon, 22 Sep 2008 16:26:10 +0000, Mickael Wolff a écrit:

Patrick Mevzek a écrit :

S'il y a certes une différence sémantique, elle n'a pas à influer sur la
façon de récupérer les paramètres envoyés par l'utilisateur,

Pourquoi, alors que ce sont deux concepts différents ?

Il ne vous aura pas échappé qu'à l'endroit où ces méthodes sont définies,
à savoir dans le RFC du protocole HTTP, protocole qui est un protocole de
*transport* d'information (comme le signifie le deuxième T), il n'y a pas
lieu de s'occuper de comment cela est géré côté serveur, parce que ce sont
(le transport vers le serveur, et la gestion interne du serveur et des
applications subordonnées) deux choses complétement décorrelées.

Si ce sont deux concepts différents, on peut s'amuser à tester
$_SERVER['REQUEST_METHOD']. Après quoi, je ne vois pas pourquoi dans le
code il faudrait un cas spécifique à une méthode et un cas spécifique à
une autre. Avoir une seule API et une abstraction simplifie souvent les
choses (tant qu'on comprend bien ce qui se passe « en-dessous »)

et
l'application peut tout à fait savoir par différents moyens si elle est
dans le cas d'un GET ou d'un POST.

Non. Parce que les deux peuvent survenir en même temps.

<form action="article.php?id" method='post'>

^^^^^^^^^^^^^

Non, pas en même temps, la preuve vous faites un POST là. Pas un GET.
Lancez un sniffeur, vous verrez bien votre navigateur faire un POST ou
serveur. Pas un POST et un GET en même temps, non juste un POST. Donc la
méthode ici est POST, point final.

Maintenant, si l'application est concue n'importe comment, c'est un autre
problème.

C'est peut-être un point non/mal spécifié dans la norme, mais c'est
clairement quelque chose qui n'a pas lieu d'être (on ne gagne rien à
?id vs input type=hidden name=id value si ce n'est quelques
caractères, si on est radin on pourrait même exploiter quelque chose
d'assez peu connu, le PATH_INFO, et faire action="article.php/id"). Je
ne vois pas pourquoi, sous prétexte d'applications mal concues, il
faudrait bâtardiser l'API pour le reste du monde...

À noter que je connais au moins une API (que je trouve sensée) qui, dans
le cas que vous donnez, ne prendrez pas du tout en compte le ?id qui ne
serait pas visible du programme (sauf à bidouiller explicatement dans la
variable d'environnement QUERY_STRING évidemment). On en revient alors à
ce que je disais dans un autre message : le développeur s'apercevrait
immédiatement que cela ne marche pas (le id étant perdu dans la bagarre)
et changerait donc son code pour faire quelque chose qui marche (mettre le
id en champ caché).

Il est clair que sinon effectivement à faire de baisser la barrière
d'entrée et d'accepter tout et n'importe quoi au simple motif de faciliter
la vie des gens qui ne veulent surtout pas réfléchir mais juste que « ca
marche » eh bien on en arrive à des catastrophes (merci register_global et
autres bourdes du même tonneau)

<p>
<input type='hidden' name='action' value='delete' /> <!-- la
valeur du bouton peut dépendre de la localisation
on utilises donc un champ caché d'action -->
<input type='submit' value='Supprimer'/>
</p>
</form>

Si on considère que $_REQUEST['action'], alors il est possible pour
un attaquant de proposer le lien <article.php?id&actionÞlete>

Et alors ?
Si vous utilisez $_POST['action'], l'attaquant peut tout aussi bien
bidouiller le formulaire et ajouter un champ caché. Donc même résultat.
Ce n'est pas utiliser $_POST['action'] à la place de $_REQUEST['action']
qui va bloquer un attaquant...

Alors
je suis d'accord que l'internaute devrait faire attention à ce qu'il
clique, mais un mécanisme minimal de sécurité est de considérer
$_POST['action'].

Non, cela n'apporte AUCUNE sécurité.

Ensuite on peut bien sûr améliorer la sécurité avec un
système de jeton, si vraiment il faut blinder, surtout si les

On ne met pas de pansements sur des jambes de bois...

ni les implications en terme de sécurité que cela implique.

Une application dont la sécurité ne dépend que de l'usage d'une méthode
HTTP plutôt que d'une autre est une application sans réelle sécurité.

La sécurité est un ensemble de bonnes pratiques.

C'est aussi celle de l'élément le plus faible du chaînon. Si c'est dernier
tient en la croyance que $_REQUEST c'est mal et qu'en prenant $_POST je
suis sauf, alors la sécurité globale est bien faible...
Elle est même « négative » selon moi dans le sens où avoir l'impression de
sécurité est encore pire que pas de sécurité du tout.

Par exemple, pour
supprimer un article, il est souhaitable que le paramètre conduisant à
la suppression ne puisse pas être considéré s'il est un HTTP GET.

Ce n'est pas la façon dont une variable est transportée qui doit
déterminer une mesure de sécurité.
Ca serait comme dire : si je recois un courrier via Chronopost je ne le
lis pas de la même façon que si je le reçois par la poste normale. Bah
non, le *contenu* de la lettre peut être le même, dangereux ou pas,
quelque soit l'enveloppe et la façon de l'acheminer.

Après vous mélangez la-dedans de la sémantique, qui est encore un autre
problème.

Sinon,
un lien dans un courriel frauduleux, ou dans un site piégé, pourrait
conduire à des suppressions ciblées.

Idem avec un POST (dans un site piégé, voire dans un email si on a le
droit au javascript ou aux formulaires)

C'est le genre de trous qui sont
souvent présents dans les panels d'administration.

Je doute que ce soit des modèles de sécurité...

Absolument pas, puisque l'espace de nommage est différent : $toto vs
$_REQUEST['toto']
Aucun risque d'utiliser $_REQUEST['toto'] par inadvertance dans un bout
du code comme variable « locale » (non dépendante de l'extérieure.

J'y vais certes un peu fort. Mais utiliser des données directement
venant de n'importe où me fait toujours sortir de mes gonds.

Certes, et sur ce point nous sommes d'accord. Mais cela n'a donc rien à
voir avec *comment* on accède à ces données, que ce soit un tableau appelé
POST ou un tableau appelé GET (les données viennent de « n'importe où »
dans les deux cas).


--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>

Le 22 Sep 2008 14:53:06 GMT, Olivier écrivait:

Le 22/09/2008 16:05, Mickaël Wolff répondait à Freddy DISSAUX :

Personnellement, je recommande chaudement l'utilisation de $_REQUEST
pour éviter les mélimélo $_GET/$_POST.

C'est que tu n'as pas compris la différence sémantique entre HTTP GET
et HTTP POST, ni les implications en terme de sécurité que cela implique.

Tiens, un marronnier...

Oui, je sais, j'ai marché dedans :)

Le but premier de mon post était d'évoquer l'utilisation de filter +
heredoc + simplification avec $_REQUEST. C'est vrai qu'à la relecture ce
n'est pas évident.

Mais je trouve que:
- filter n'est vraiment pas assez utilisé
- les heredoc ne sont pas assez utilisés (quelle plaie ces interminables
concaténation !)
- on se simplifie un peu le debug avec $_REQUEST (et le premier qui n'a
jamais tripoté une url dans son navigateur me jette la première pierre
:)

--
freddy <point> dsx <arobase> free <point> fr