Quel est le problème avec l'utilisation de $ _REQUEST []?

J'ai vu un certain nombre de messages ici disant de ne pas utiliser la $_REQUESTvariable. Habituellement, je ne le fais pas, mais parfois c'est pratique. Qu'est ce qui ne va pas avec ça?

Il n'y a absolument rien de mal à accepter les contributions des deux $_GETet $_POSTde manière combinée. En fait, c'est ce que vous voulez presque toujours faire:

• pour une simple requête idempotente généralement soumise via GET, il est possible que la quantité de données que vous souhaitez ne tienne pas dans une URL, elle a donc été mutée en requête POST à ​​la place pour une question pratique.

• pour une requête qui a un réel effet, vous devez vérifier qu'elle est soumise par la méthode POST. Mais le moyen de le faire est de vérifier $_SERVER['REQUEST_METHOD']explicitement, de ne pas compter sur le fait d' $_POSTêtre vide pour un GET. Et de toute façon, si la méthode l'est POST, vous voudrez peut-être toujours supprimer certains paramètres de requête de l'URL.

Non, le problème avec $_REQUESTn'a rien à voir avec la fusion des paramètres GET et POST. C'est qu'il inclut aussi, par défaut,$_COOKIE . Et les cookies ne sont pas du tout des paramètres de soumission de formulaires: vous ne voulez presque jamais les traiter comme la même chose.

Si vous obtenez accidentellement un cookie sur votre site avec le même nom que l'un de vos paramètres de formulaire, les formulaires qui reposent sur ce paramètre cesseront mystérieusement de fonctionner correctement en raison des valeurs de cookie remplaçant les paramètres attendus. C'est très facile à faire si vous avez plusieurs applications sur le même site, et peut être très difficile à déboguer lorsque vous n'avez que quelques utilisateurs avec d'anciens cookies que vous n'utilisez plus en train de traîner et de casser les formulaires de manière non -un autre peut se reproduire.

Vous pouvez changer ce comportement en ordre beaucoup plus raisonnable GP(non C) avec la configuration request_order en PHP 5.3. Là où ce n'est pas possible, j'éviterais personnellement $_REQUESTet, si j'avais besoin d'un tableau combiné GET + POST, je le créerais manuellement.

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.

$_REQUESTfait référence à toutes sortes de requêtes (GET, POST etc.). Ceci est parfois utile, mais il est généralement préférable de spécifier la méthode exacte ($ _GET, $ _POST, etc.).

$_REQUEST est généralement considérée comme nuisible pour la même raison que les transformations de données de complexité simple à moyenne sont souvent effectuées dans le code de l'application au lieu d'être déclarées en SQL: certains programmeurs craignent.

En tant que tel, si l'on a tendance à utiliser $_REQUESTpartout, je peux faire n'importe quoi via GET que je pourrais via POST, ce qui signifie mettre en place des <img>balises sur mon site (malveillant) qui poussent les utilisateurs connectés à votre module e-commerce à acheter des produits en silence, ou je peut les amener à cliquer sur des liens qui entraîneront des actions dangereuses ou la révélation d'informations sensibles (probablement pour moi).

Cependant, cela est dû au fait qu'un programmeur PHP novice, ou du moins inexpérimenté, commet de simples erreurs. Tout d'abord, sachez quand les données de quel type sont appropriées. Par exemple, j'ai un service Web qui peut renvoyer des réponses en URLEncoding, XML ou JSON. L'application décide comment formater la réponse en vérifiant l'en-tête HTTP_ACCEPT, mais peut être forcée en un spécifiquement en envoyant le formatparamètre.

Lors de la vérification du contenu du paramètre de format, il peut être envoyé via une chaîne de requête ou une postdata, en fonction d'une multitude de facteurs, dont le moindre n'est pas le fait que les applications appelantes souhaitent ou non "& format = json" mélangé à sa requête. Dans ce cas, $_REQUESTc'est très pratique car cela m'évite d'avoir à taper quelque chose comme ceci:

$format = isset($_POST['format']) ? $_POST['format'] 
    : (isset($_GET['format']) ? $_GET['format'] : null);

Je ne vais pas parler beaucoup plus loin, mais il suffit de dire que l' $_REQUESTutilisation n'est pas dissuadée car elle est intrinsèquement dangereuse - c'est juste un autre outil qui fait exactement ce qui lui est demandé, que vous compreniez ces implications ou non - c'est le décision médiocre, paresseuse ou non informée d'un programmeur pauvre, paresseux ou inexpérimenté qui cause ce problème.

Comment utiliser en $_REQUESTtoute sécurité

1. Connaissez vos données : vous devriez avoir des attentes quant au type de données que vous obtiendrez, alors nettoyez-les en conséquence. Données pour une base de données? addslashes()ou *_escape_string(). Vous allez le montrer à l'utilisateur? htmlentities()ou htmlspecialchars(). Vous attendez des données numériques? is_numeric()ou ctype_digit(). En fait, filter_input()et ses fonctions associées sont conçues pour ne rien faire d'autre que vérifier et nettoyer les données. Utilisez ces outils, toujours.
2. N'accédez pas directement aux données superglobales fournies par l'utilisateur . Prenez l'habitude de nettoyer vos données, à chaque fois, et de déplacer vos données vers des variables propres, même si c'est juste $post_clean. Alternativement, vous pouvez simplement nettoyer directement dans les superglobales, mais la raison pour laquelle je préconise d'utiliser une variable séparée est que cela permet de repérer facilement les vulnérabilités dans le code, car tout ce qui pointe directement vers un superglobale et non son équivalent nettoyé est considéré comme une erreur dangereuse .
3. Sachez d'où doivent provenir vos données. En référence à mon exemple ci-dessus, il est parfaitement raisonnable d'autoriser l'envoi de la variable de format de réponse via GET ou POST. J'autorise également l'envoi de la variable "action" via l'une ou l'autre méthode. Cependant, les actions elles-mêmes ont des exigences très spécifiques quant au verbe HTTP acceptable . Les fonctions, par exemple, qui modifient les données utilisées par le service ne peuvent être envoyées que via POST. Des demandes pour certains types de données sans privilège ou à faible privilège (telles que des images cartographiques générées dynamiquement) peuvent être servies en réponse aux demandes de l'une ou l'autre méthode.

En conclusion, rappelez-vous cette règle simple:

LA SÉCURITÉ C'EST CE QUE VOUS FAITES, LES GENS!

ÉDITER:

Je recommande fortement le conseil de bobince: si vous le pouvez, définissez le request_orderparamètre dans php.ini sur "GP"; c'est-à-dire pas de composant cookie. Il n'y a presque aucun raisonnement rationnel à cela dans 98% + des cas, car les données des cookies ne devraient presque jamais être considérées comme comparables à la chaîne de requête ou aux données postérieures.

PS, anecdote!

Je connaissais un programmeur qui pensait à $_REQUESTun endroit pour stocker simplement des données qui était accessible de manière super globale. Noms d'utilisateur et mots de passe importants, chemins d'accès aux fichiers, nommez-le et il a été stocké dans $_REQUEST. Il a été un peu surpris (mais pas comique, malheureusement) quand je lui ai dit comment cette variable se comporte. Inutile de dire que cette pratique a été abandonnée.

Les requêtes GET doivent être idempotentes et les requêtes POST ne le sont généralement pas. Cela signifie que les données dans$_GET et $_POSTdevraient généralement être utilisés de différentes manières.

Si votre application utilise des données de $_REQUEST, elle se comportera de la même manière pour les requêtes GET et POST, ce qui viole l'idempotence de GET.

C'est vague. Vous ne savez pas vraiment comment les données vous sont parvenues, car elles contiennent des données de publication, d'obtention et de cookies. Je ne pense pas nécessairement que ce soit toujours une mauvaise chose, à moins que vous n'ayez besoin de connaître ou de restreindre la méthode de livraison.

J'aime vraiment l'utiliser. Cela vous donne la possibilité d'utiliser GET ou POST, ce qui peut être utile pour des choses comme les formulaires de recherche où la plupart du temps les données sont POSTÉES, mais parfois vous voudrez dire un lien vers une recherche particulière, afin que vous puissiez utiliser les paramètres GET à la place. .

De plus, si vous regardez de nombreux autres langages (ASP.NET par exemple), ils ne font aucune distinction entre les variables GET et POST.

ETA :

Je n'ai jamais utilisé REQUEST pour obtenir les valeurs COOKIE, mais je pense que Kyle Butt fait un bon point dans les commentaires de cet article à ce sujet. Ce n'est PAS une bonne idée d'utiliser REQUEST pour obtenir les valeurs COOKIE. Je pense qu'il a raison de dire qu'il existe un réel potentiel de falsification de demandes intersites si vous faites cela.

De plus, l'ordre dans lequel les éléments sont chargés dans REQUEST est contrôlé par les paramètres de configuration dans php.ini (variables_order et request_order). Donc, si vous avez la même variable transmise via POST et GET, celle qui entre réellement dans REQUEST dépend de ces paramètres ini. Cela pourrait affecter la portabilité si vous dépendez d'une commande particulière et que ces paramètres sont configurés différemment de ce à quoi vous vous attendez.

Il est important de comprendre quand utiliser POST, quand utiliser GET et quand utiliser un cookie. Avec $ _REQUEST, la valeur que vous recherchez pourrait provenir de l'un d'entre eux. Si vous prévoyez d'obtenir la valeur d'un POST ou d'un GET ou d'un COOKIE, il est plus informatif pour quelqu'un qui lit votre code d'utiliser la variable spécifique au lieu de $ _REQUEST.

Quelqu'un d'autre a également souligné que vous ne voulez pas que tous les POST ou cookies soient remplacés par les GET car il existe différentes règles intersites pour tous, par exemple, si vous retournez des données ajax en utilisant $ _REQUEST, vous êtes vulnérable à une attaque de script intersite.

Le seul moment où l'utilisation $_REQUESTn'est pas une mauvaise idée est avec GET.

• Si vous l'utilisez pour charger des valeurs POST, vous risquez des falsifications de requêtes intersites
• Si vous l'utilisez pour charger des valeurs de cookies, vous risquez à nouveau de falsifier les demandes intersites

Et même avec GET, $_GETest plus court à taper que $_REQUEST;)

Je pourrais être utilisé uniquement si vous souhaitez récupérer l'url ou le nom d'hôte actuel, mais pour analyser réellement les données de cette URL, telles que les paramètres en utilisant le symbole &, ce n'est probablement pas une bonne idée. En général, vous ne voulez pas utiliser une description vague de ce que vous essayez de faire. Si vous avez besoin d'être précis, c'est là que $ _REQUEST est mauvais, si vous n'avez pas besoin d'être précis, n'hésitez pas à l'utiliser. Je penserais.

Si vous savez quelles données vous voulez, vous devez les demander explicitement. IMO, GET et POST sont deux animaux différents et je ne peux pas penser à une bonne raison pour laquelle vous auriez jamais besoin de mélanger les données de publication et les chaînes de requête. Si quelqu'un en a un, je serais intéressé.

Il peut être pratique d'utiliser $ _REQUEST lorsque vos scripts peuvent répondre à GET ou POST de la même manière. Je dirais cependant que cela devrait être un cas extrêmement rare, et dans la plupart des cas, deux fonctions distinctes pour gérer deux concepts distincts, ou à tout le moins vérifier la méthode et sélectionner les bonnes variables, sont préférées. Le déroulement du programme est généralement beaucoup plus facile à suivre lorsqu'il n'est pas nécessaire de croiser la provenance des variables. Soyez gentil avec la personne qui doit maintenir votre code dans 6 mois. Ça pourrait etre vous.

En plus des problèmes de sécurité et des WTF causés par les cookies et les variables d'environnement dans la variable REQUEST (ne me lancez pas sur GLOBAL), pensez à ce qui pourrait arriver à l'avenir si PHP commençait à prendre en charge nativement d'autres méthodes telles que PUT et DELETE. Bien qu'il soit extrêmement improbable que ceux-ci soient fusionnés dans le superglobal REQUEST, il est possible qu'ils puissent être inclus en option dans le paramètre variable_order. Vous n'avez donc vraiment aucune idée de ce que contient REQUEST et de ce qui prime, en particulier si votre code est déployé sur un serveur tiers.

POST est-il plus sûr que GET? Pas vraiment. Il est préférable d'utiliser GET lorsque cela est pratique, car il est plus facile de voir dans vos journaux comment votre application est exploitée lorsqu'elle est attaquée. POST est préférable pour les opérations qui affectent l'état du domaine, car les araignées ne les suivent généralement pas et les mécanismes de récupération prédictive ne supprimeront pas tout votre contenu lorsque vous vous connectez à votre CMS. Cependant, la question ne portait pas sur les mérites de GET vs POST, mais sur la façon dont le récepteur devrait traiter les données entrantes et pourquoi il est mauvais de les fusionner, il ne s'agit donc en réalité que d'un BTW.

Je pense qu'il n'y a pas de problème avec $_REQUEST, mais il faut être prudent lors de son utilisation car il s'agit d'un ensemble de variables provenant de 3 sources (GPC).

Je suppose qu'il $_REQUESTest toujours disponible pour rendre les anciens programmes compatibles avec les nouvelles versions de php, mais si nous commençons de nouveaux projets (y compris de nouvelles bibliothèques), je pense que nous ne devrions plus utiliser $_REQUESTpour rendre les programmes plus clairs. Nous devrions même envisager de supprimer les utilisations de $_REQUESTet de le remplacer par une fonction wrapper pour alléger le programme, en particulier dans le traitement de données texte soumises volumineuses, car $_REQUESTcontient des copies de $_POST.

// delete $_REQUEST when program execute, the program would be lighter 
// when large text submitted
unset($_REQUEST);

// wrapper function to get request var
function GetRequest($key, $default = null, $source = '') 
{
  if ($source == 'get') {
    if (isset($_GET[$key])) { 
      return $_GET[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'post') {
    if (isset($_POST[$key])) { 
      return $_POST[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'cookie') {
    if (isset($_COOKIE[$key])) { 
      return $_COOKIE[$key]; 
    } else { 
      return $default; 
    }
  } else {
    // no source specified, then find in GPC
    if (isset($_GET[$key])) {
      return $_GET[$key];     
    } else if (isset($_POST[$key])) {
      return $_POST[$key]; 
    } else if (isset($_COOKIE[$key])) {
      return $_COOKIE[$key]; 
    } else {
      return $default; 
    } 
  }
}

Darren Cook: "Depuis php 5.3, le php.ini par défaut indique que seules les données GET et POST sont insérées$_REQUEST . Voir php.net/request_order Je viens de tomber sur cette rupture de compatibilité descendante en m'attendant à ce que les données des cookies soient incluses$_REQUEST et en me demandant pourquoi cela ne l'était pas. t fonctionne! "

Wow ... certains de mes scripts ont juste cessé de fonctionner à cause d'une mise à niveau vers PHP 5.3 . J'ai fait la même chose: supposons que les cookies seraient définis lors de l'utilisation de la $_REQUESTvariable. Avec la mise à niveau exactement cela a cessé de fonctionner.

J'appelle maintenant les valeurs de cookie séparément en utilisant $_COOKIE["Cookie_name"]...

Le problème central est qu'il contient des cookies, comme d'autres l'ont dit.

En PHP 7, vous pouvez faire ceci:

$request = array_merge($_GET ?? [], $_POST ?? []);

Cela évite le problème des cookies et vous donne au pire un tableau vide et au mieux une fusion de $ _GET et $ _POST, ce dernier étant prioritaire. Si vous n'êtes pas trop dérangé par l'autorisation de l'injection d'URL de paramètres via la chaîne de requête, c'est très pratique.

C'est très peu sûr. C'est aussi gênant puisque vous ne savez pas si vous recevez un POST ou un GET, ou une autre demande. Vous devez vraiment connaître la différence entre eux lors de la conception de vos applications. GET est très peu sûr car il est passé dans l'URL et ne convient à presque rien à part la navigation de page. POST, bien que n'étant pas sûr en soi non plus, offre un niveau de sécurité.