J'ai fouillé dans certains articles de groupes de discussion sur PHP Internals et j'ai trouvé une discussion intéressante sur le sujet. Le fil de discussion initial portait sur autre chose, mais une remarque de Stefan Esser, un (sinon le ) expert en sécurité dans le monde PHP a orienté la discussion vers les implications de sécurité de l'utilisation de $ _REQUEST pour quelques articles.
Citant Stefan Esser à propos des internes PHP
$ _REQUEST est l'une des plus grandes faiblesses de conception de PHP. Chaque application utilisant $ _REQUEST est très probablement vulnérable aux problèmes de falsification de demandes intersites différées. (Cela signifie essentiellement que si, par exemple, un cookie nommé (age) existe, il écrasera toujours le contenu GET / POST et donc les requêtes indésirables seront effectuées)
et dans une réponse ultérieure au même fil
Il ne s'agit pas du fait que quelqu'un puisse forger GET, POST; Variables COOKIE. Il s'agit du fait que les COOKIE écraseront les données GET et POST dans REQUEST.
Par conséquent, je pourrais infecter votre navigateur avec un cookie qui dit par exemple action = déconnexion et à partir de ce jour, vous ne pouvez plus utiliser l'application car REQUEST [action] sera déconnectée pour toujours (jusqu'à ce que vous supprimiez manuellement le cookie).
Et vous infecter avec un COOKIE est si simple ...
a) Je pourrais utiliser un vuln XSS dans n'importe quelle application sur un sous-domaine
b) Vous avez déjà essayé de définir un cookie pour * .co.uk ou * .co.kr lorsque vous possédez un domaine unique là-bas?
c) Autres domaines transversaux de toutes manières ...
Et si vous pensez que ce n'est pas un problème, je peux vous dire qu'il existe une possibilité simple de définir un cookie * .co.kr qui se traduit par plusieurs versions de PHP qui ne renvoient que des pages blanches. Imaginez: un seul cookie pour tuer toutes les pages PHP dans * .co.kr
Et en définissant un identifiant de session illégal dans un cookie valide pour * .co.kr dans une variable appelée + PHPSESSID = illégal, vous pouvez toujours DOS toutes les applications PHP en Corée en utilisant des sessions PHP ...
La discussion se poursuit pour quelques autres articles et est intéressante à lire.
Comme vous pouvez le voir, le principal problème avec $ _REQUEST n'est pas tant qu'il contient des données de $ _GET et $ _POST, mais aussi de $ _COOKIE. Certains autres gars de la liste ont suggéré de changer l'ordre dans lequel $ _REQUEST est rempli, par exemple en le remplissant d'abord avec $ _COOKIE, mais cela pourrait conduire à de nombreux autres problèmes potentiels, par exemple avec la gestion des sessions .
Cependant, vous pouvez complètement omettre $ _COOKIES du global $ _REQUEST, afin qu'il ne soit écrasé par aucun des autres tableaux (en fait, vous pouvez le limiter à n'importe quelle combinaison de son contenu standard, comme le manuel PHP sur le paramètre variable_order ini. nous dit:
variable_order Définit l'ordre de l'analyse des variables EGPCS (Environment, Get, Post, Cookie et Server). Par exemple, si variables_order est défini sur "SP", PHP créera les superglobales $ _SERVER et $ _POST, mais ne créera pas $ _ENV, $ _GET et $ _COOKIE. Le réglage sur "" signifie qu'aucune superglobale ne sera définie.
Mais là encore, vous pouvez également envisager de ne pas utiliser complètement $ _REQUEST, simplement parce qu'en PHP, vous pouvez accéder à Environment, Get, Post, Cookie et Server dans leurs propres globaux et avoir un vecteur d'attaque en moins. Vous devez toujours nettoyer ces données, mais c'est une chose de moins à craindre.
Maintenant, vous pourriez vous demander pourquoi $ _REQUEST existe après tout et pourquoi il n'est pas supprimé. Cela a également été demandé sur PHP Internals. Citant Rasmus Lerdorf sur Pourquoi $ _REQUEST existe-t-il? sur PHP Internals
Plus nous supprimons de choses comme celle-ci, plus il devient difficile pour les gens de passer rapidement à des versions plus récentes, plus rapides et plus sécurisées de PHP. Cela cause beaucoup plus de frustration pour tout le monde que quelques fonctionnalités héritées "laides". S'il y a une raison technique, des performances ou une sécurité décentes, nous devons l'examiner attentivement. Dans ce cas, la chose que nous devrions examiner n'est pas de savoir si nous devons supprimer $ _REQUEST mais si nous devons en supprimer les données de cookie. De nombreuses configurations le font déjà, y compris toutes les miennes, et il existe une bonne raison de sécurité valable pour ne pas inclure les cookies dans $ _REQUEST. La plupart des gens utilisent $ _REQUEST pour signifier GET ou POST, sans se rendre compte qu'il pourrait également contenir des cookies et que de tels méchants pourraient potentiellement faire des astuces d'injection de cookies et casser des applications naïves.
Quoi qu'il en soit, j'espère que cela vous éclairera.