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


116

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?


2
Voir les questions et réponses associées: stackoverflow.com/questions/1149118/…
Gordon

2
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 présentes $_REQUESTet en me demandant pourquoi cela ne fonctionnait pas! Donc, la principale raison d'éviter d'utiliser $ _REQUEST est maintenant que votre script ne peut pas se définir request_orderlui-même (c'est le cas PHP_INI_PERDIR), donc un changement de php.ini peut facilement casser les hypothèses sur lesquelles votre script est construit. Mieux vaut mettre ces hypothèses directement dans votre script.
Darren Cook

Réponses:


184

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.


2
Ces situations (données trop longues pour être soumises via GET) sont une exception, pas une règle
Ben James

1
Bonne réponse. J'ai également remarqué qu'avec des frameworks tels que Zend Framework GET et POST, les paramètres sont combinés en 1 objet de requête. Cela ne m'a jamais frappé avant d'avoir lu votre message.
Jay Sidri

Par défaut, la configuration request_order est définie sur "GP" dans php.ini à partir de PHP 5.4+ donc je dirais allez-y ... mais comme toujours, procédez avec prudence.
bcmoney

si $ _POST est a="foo"et $ _COOKIE a="bar", alors y aura-t-il des remplacements / conflits ici?
Rust

75

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.


1
+1 bon de voir une discussion à ce sujet ... Je pensais que je devenais fou!
bobince

2
Je pense que cette discussion était un peu trop généralisée. Le problème réel est la méconnaissance du développeur, pas l'existence de cookies dans $ _REQUEST en soi. Le PHPSESSID corrigé par exemple va de toute façon être réinitialisé avec un cookie par domaine avec un code de gestion de session contemporain. Et pour certaines applications, un cookie remplaçant la requête vars peut être vraiment souhaitable (par exemple, sort_order = ASC remplace un formulaire de recherche GET var). Bien que coder explicitement dans un tel comportement soit plus judicieux.
mario

1
Post très complet, cela devrait être la réponse. Peut-être que les gens craignent un long post;)
Dzung Nguyen

Malheureusement, Rasmus a commenté cela en 2009, et pourtant $ _REQUEST est essentiellement le même maintenant, en 2015.
Kzqai

10

$_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.).


19
Cette réponse décrit ce qu'est $ _REQUEST, mais ne répond pas à la question.
zombat le

1
Il dit que c'est simplement une meilleure pratique de savoir quel type de demande serait entrante et de coder à cette demande spécifique.
Polaris878 du

8

$_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.


8

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.


1
mais cela ne dépend-il pas de la mise en œuvre? «Indempotent» est un nouveau mot pour moi, mais si je le comprends bien, il serait facile d'imaginer mettre en place une situation GET qui ne soit pas indempotente. Par exemple, les compteurs de pages augmentent généralement chaque fois que vous demandez une URL donnée.
sprugman

1
@sprugman - vous pouvez également avoir des situations dans lesquelles vous avez à la fois des données GET et des données POST dans la même requête, auquel cas la méthode de requête n'a pratiquement aucun sens lorsqu'elle est contextualisée avec les données de la requête.
zombat le

sprugman, évidemment toute demande GET modifie quelque chose car elle est enregistrée par le serveur Web. Il peut encore être indempotent dans le domaine de l'application, où ces métadonnées n'ont pas vraiment d'importance.
Ben James

@sprugman - l'idée générale ici est que vous ne devriez pas avoir de requête GET qui modifie les données. Un exemple typique de pourquoi c'est mauvais serait une araignée Web qui explore votre site et suit des liens qui modifient involontairement les données. Par exemple, le lien «drapeau» sur une publication SO.
Eric Petroelje

C'était un exemple trivial. Et si j'utilise GET via ajax car c'est plus rapide (comme suggéré dans cet article sur carsonified carsonified.com/blog/dev/the-definitive-guide-to-get-vs-post ).
sprugman

7

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.


3

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.


c'est une terrible erreur. Comment garantir que des actions non idempotentes ont été effectuées sur un POST?
Kyle Butt

1
@Kyle - en ne l'utilisant pas pour des actions non idempotentes. Je ne l'utiliserais certainement pas pour tout, soulignant simplement que c'est utile, comme pour les recherches comme je l'ai mentionné dans mon exemple.
Eric Petroelje

1
Cette idée magique que _POST est sécurisé et _GET ne l'est pas doit disparaître. Si je n'utilise pas correctement votre logiciel, il y a très peu de différence (voire aucune) entre l'envoi d'une requête POST et une requête GET. La sécurité réside dans ce que vous faites des données et non dans leur origine. En ce qui concerne les exploits XSS / Request simples, il est tout à fait possible qu'il n'utilise _REQUEST que pour les valeurs qui seraient valides avec POST ou GET, et n'utilise _POST que pour les choses qui devraient être POSTÉES. Du bon sens, pas une utilisation super-mondiale magique.
Publié le

1
@Kyle - Je ne vois toujours pas comment vous ne pourriez pas faire ce que vous mentionnez aussi facilement en utilisant quelque chose comme curl () ou un post ajax pour transmettre ces mêmes données via POST et COOKIE. Que vous utilisiez REQUEST, GET, POST ou COOKIE, toutes les données proviennent finalement du client et peuvent toujours être truquées.
Eric Petroelje

1
@zombat: La requête curl que vous formulez ne sera pas connectée en tant qu'utilisateur vulnérable. Le lien que vous créez et placez sur votre site le sera. @Dereleased: Ce n'est pas une pensée magique, et il y a encore de nombreuses vulnérabilités avec GET. mais il est plus sûr de faire confiance à un POST d'un utilisateur connecté qu'à un GET d'un utilisateur connecté.
Kyle Butt

2

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.


2

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;)


Bien que je sois d'accord avec vous, je pense qu'il est important de noter pourquoi cela est vrai et / ou dangereux: il faut l'utiliser $_POSTlorsqu'il est important que les données soient POSTDATA. Il faut l'utiliser $_REQUESTlorsque les données sont indépendantes du verbe HTTP utilisé. Il faut dans tous ces cas nettoyer soigneusement toutes les données d'entrée.
Publié le

1
Je ne vois pas comment la source des données se rapporte à la probabilité de falsification des demandes intersites. Un attaquant peut parfaitement définir un paramètre POST en fournissant à l'utilisateur un formulaire POST pointé sur votre site; vous allez avoir besoin des mêmes mesures de protection anti-XSRF, que la soumission provienne de GET ou POST.
bobince le

Il est beaucoup plus facile d'abuser de GET pour falsifier. Par exemple, vous pouvez simplement avoir une balise img avec son src défini avec les paramètres que vous voulez. Cela fonctionnera sans que l'utilisateur ne sache jamais qu'il était là.
Jani Hartikainen

0

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.


Qu'est-ce que tu essayes de dire? Êtes-vous confus $_REQUESTavec $_SERVER['QUERY_STRING']?
Publié le

0

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.


0

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; 
    } 
  }
}

0

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"]...


-1

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.


Ceux qui choisissent de voter contre, veuillez expliquer pour mon édification.
amh15

-2

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é.


4
Il n'y a aucune différence de sécurité entre $ _POST et $ _GET, à part que vous ne pouvez pas taper une requête POST dans la barre d'URL d'un navigateur. Cependant, cela ne prend que 5 secondes pour lancer une requête cURL en ligne de commande en utilisant POST.
zombat le

3
@Zombat: Nous devons lancer une sorte de campagne pour convaincre les gens que POST n'est pas intrinsèquement sûr, ni même plus sûr, que GET. La sécurité réside dans la manière dont vous traitez les données et non dans le verbe HTTP utilisé pour y parvenir.
Publié le

@Dereleased - Je propose une image en duo emblématique d'un nuage avec des éclairs pour représenter Internet, avec le mot "CHANGE" en dessous.
zombat le

1
@GuyT: C'est une vision très étroite. Il ne s'agit pas seulement de savoir à quel point il est «sécurisé», mais à quel point il est confidentiel. Les paramètres GET peuvent apparaître sous forme de saisie semi-automatique dans l'URL du navigateur, même dans l'historique du navigateur. De plus, la sécurité ne s'arrête pas au navigateur. Par exemple, de nombreux serveurs enregistrent des URL http, de sorte que tout ce qui se trouve dans l'URL serait consigné, par exemple. L'affichage d'un nom d'utilisateur / mot de passe dans les journaux fait une différence. Par mesure de sécurité, évitez toujours de transmettre des informations sensibles en tant que paramètres GET.
stan

1
Plus précisément, les journaux d'accès Apache. Toute URL de demande sera enregistrée et TOUTES les personnes qui ont accès aux journaux peuvent voir vos informations d'identification arriver.
stan le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.