Post by Mickael WolffPost by Patrick MevzekS'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 »)
Post by Mickael WolffPost by Patrick Mevzeket
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=12" 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=12 vs input type=hidden name=id value=12 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=12"). 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=12 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)
Post by Mickael Wolff<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=12&action=delete>
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...
Post by Mickael WolffAlors
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é.
Post by Mickael WolffEnsuite 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...
Post by Mickael WolffPost by Patrick MevzekPost by Mickaël Wolffni 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.
Post by Mickael WolffPar 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.
Post by Mickael WolffSinon,
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)
Post by Mickael WolffC'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é...
Post by Mickael WolffPost by Patrick MevzekAbsolument 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/>