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

J'ai été fouiller dans certains messages du forum sur PHP Internals et trouvé une discussion intéressante sur le sujet. Le thread initial était quelque chose d'autre, mais une remarque par Stefan Esser, un (si ce n'est la) spécialiste de la sécurité dans le monde PHP tourné la discussion vers les implications sur la sécurité de l'utilisation de $_REQUEST pour quelques postes.

Citant Stefan Esser PHP Internals

$_REQUEST est l'une des plus grandes faiblesses de la conception en PHP. Chaque application utilisant
$_REQUEST est probablement vulnérable à un Retard de Cross Site Request
Faux problèmes. (En fait cela signifie que si par exemple, un cookie nommé (âge)
existe il va toujours remplacer le GET/POST contenu, et par conséquent
indésirables les demandes seront effectuées)

et dans un plus tard, de répondre à la même thread

Il n'est pas sur le fait que quelqu'un peut forge GET, POST, COOKIE variables.
C'est sur le fait que les Témoins écraser les données GET et POST dans
DEMANDE.

Donc je pourrait infecter votre navigateur un cookie qui dit par exemple
action=logout et à partir de ce jour, vous ne pouvez pas utiliser l'application
de plus, parce que la DEMANDE[de l'action] sera de déconnexion pour toujours (jusqu'à ce que vous
supprimer manuellement les cookies).

Et de vous infecter avec un COOKIE est si simple...

a) je pourrais utiliser un XSS vuln dans n'importe quelle application sur un sous-domaine

b) Jamais essayé définition d'un cookie pour *.co.royaume-uni ou *.co.kr lorsque vous possédez un
seul domaine là?

c) d'Autres croix domaine de toutes les façons...

Et si vous croyez que ce n'est pas un problème, alors je peux vous dire que
il y a une solution simple pour régler f.e. un *.co.kr cookie résultats
dans plusieurs versions de PHP antérieures à juste retour des pages blanches.
Imaginez: un seul témoin pour tuer toutes les pages PHP dans *.co.kr

Et par la mise illégale d'un ID de session dans un cookie valable pour *.co.kr dans un
variable +PHPSESSID=illégale vous pouvez toujours DOS à chaque PHP
application en corée à l'aide de sessions PHP...

La discussion se poursuit pendant un peu plus d'affichages, et est intéressant à lire.

---

Comme vous pouvez le voir, le principal problème avec $_REQUEST n'est pas tellement qu'il a données à partir de $_GET et $_POST, mais aussi à partir de $_COOKIE. Certains autres gars sur la liste proposé de modifier l'ordre dans lequel $_REQUEST est rempli, par exemple, remplir avec de l' $_COOKIE premier, mais cela pourrait conduire à de nombreux autres problèmes potentiels, par exemple avec le gestionnaire de Session.

Vous pourriez complètement omettre $_COOKIES de l' $_REQUEST mondiale, cependant, de sorte qu'il n'est pas remplacé par l'un des autres tableaux (en fait, vous pouvez le limiter à une combinaison quelconque de ses contenus standard, comme le Manuel PHP sur le variable_order paramètre ini nous dit:

variable_order Définit l'ordre de la EGPCS (Environnement, Get, Post, Cookie, et le Serveur) de la variable d'analyse. Par exemple, si variables_order est réglé sur "SP", puis PHP va créer les superglobales $_SERVER et $_POST, mais de ne pas créer de $_ENV, $_GET, $_COOKIE. Le réglage " pas de superglobales sera fixé.

Mais là encore, vous pouvez aussi envisager de ne pas utiliser $_REQUEST tout à fait, simplement parce qu'en PHP, vous pouvez accéder à l'Environnement, Get, Post, Cookie, et le Serveur dans leur propre globals et ont un vecteur d'attaque en moins. Vous avez encore de désinfecter ces données, mais il est une chose de moins à se soucier.

---

Maintenant, vous pourriez vous demander, pourquoi ne $_REQUEST existe après tout, et pourquoi il n'est pas supprimé. Cela a été demandé sur PHP Internals ainsi. Citant Rasmus Lerdorf sur Pourquoi ne $_REQUEST existent? sur PHP Internals

Le plus de choses comme cela nous retirer, plus il devient difficile pour les gens à
se déplacer rapidement plus récent, plus rapide et plus sécurisé versions de PHP. Que
les causes de la manière plus de frustration pour tout le monde qu'un peu "moche" héritage
les fonctionnalités. Si il ya une bonne raison technique, de la performance ou
de sécurité, alors nous avons besoin de prendre un coup d'oeil dur à elle. Dans ce cas, l'
chose que nous devrions être à la recherche à n'est pas de savoir si on doit supprimer $_REQUEST
mais si l'on doit supprimer les données de cookie à partir d'elle. De nombreuses configurations
déjà le faire, y compris toutes mes propre, et il y a une forte valide
la sécurité de raison de ne pas y compris les cookies dans $_REQUEST. La plupart des gens utilisent
$_REQUEST à dire GET ou POST, ne réalisant pas qu'il pourrait également contenir des
les cookies et que ces méchants peut-être de faire quelques témoin d'injection
astuces et de briser naïf applications.

De toute façon, l'espoir que de jeter un peu de lumière.

$_REQUEST est généralement considéré comme nocif pour la même raison que le simple moyen de la complexité des données-les transformations sont souvent effectuée dans le code de l'application au lieu d'déclaré dans SQL: certains programmeurs sucer.

En tant que tel, si l'on a tendance à utiliser des $_REQUEST partout, je ne peux rien faire par GET que je pourrais par la POSTE, ce qui implique la mise en place <img> tags sur mon (malveillant) site qui causent les utilisateurs connectés à votre module e-commerce pour l'achat de produits en silence, ou je peut les amener à cliquer sur les liens qui se traduiront en actions dangereuses ou la révélation d'informations sensibles (probablement pour moi).

Cependant, c'est en raison d'un novice, ou au moins inexpérimenté, programmeur PHP faisant de simples erreurs. Tout d'abord, savoir quand des données de ce type est approprié. Par exemple, j'ai un service web qui peut renvoyer des réponses dans l'Encodage, XML ou JSON. L'application décide de la façon de formater la réponse en cochant la HTTP_ACCEPT en-tête, mais peut être contraint à un particulier par l'envoi de la format paramètre.

Lors de la vérification du contenu du paramètre de format, il pourrait être envoyés par l'intermédiaire de la chaîne de recherche ou un postdata, en fonction d'une multitude de facteurs, dont le moindre n'étant de savoir si ou non les applications d'appels veut", &format=json" mélangé à sa demande. Dans ce cas, $_REQUEST est très pratique car il me permet d'économiser avoir à écrire quelque chose comme ceci:

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

Je ne vais pas radoter sur beaucoup plus loin, mais il suffit de dire que $_REQUEST utilisation n'est pas dissuadé, car il est intrinsèquement dangereux - c'est juste un autre outil qui fait exactement ce qui est demandé, si vous comprenez ces conséquences ou pas -, c'est le mauvais, paresseux ou non informés de la décision de mauvais, paresseux ou inexpérimentés programmeur qui provoque ce problème.

Comment utiliser $_REQUEST en toute sécurité

---

1. Savons que vos données: Vous devez avoir une certaine attente de ce type de données que vous obtiendrez, afin de l'assainir en conséquence. Données pour une base de données? addslashes() ou *_escape_string(). Allez le montrer à l'utilisateur? htmlentities() ou htmlspecialchars(). Attend de données numériques? is_numeric() ou ctype_digit(). En fait, filter_input() et ses fonctions sont conçues pour ne rien faire, mais de vérifier et de les désinfecter les données. L'utilisation de ces outils, toujours.
2. N'avez pas d'accès fourni par l'utilisateur superglobales données directement. Prendre l'habitude de la désinfection de vos données, à chaque fois, et déplacer vos données pour nettoyer les variables, 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, à l'aide d'une variable distincte est parce que cela les rend faciles à repérer les vulnérabilités dans le code, comme rien pointant directement vers une superglobale et pas ses épurés équivalente est considérée comme une dangereuse erreur.
3. Savoir où vous les données devraient être à venir à partir de. Le référencement de mon exemple ci-dessus, il est parfaitement raisonnable pour permettre le format de réponse variable via GET ou POST. J'ai aussi de permettre à "l'action" de la variable à être envoyés par l'intermédiaire de la méthode. Cependant, les actions elles-mêmes ont des exigences très spécifiques qui HTTP Verbe est acceptable. Fonctions, par exemple, que les modifications des données utilisées par le service ne peut être envoyé par la POSTE. Les demandes de certains types de non - ou à faible privilège de données (telles que générées dynamiquement des images cartographiques) peut être servi en réponse à la demande de la méthode.

En conclusion, n'oubliez pas cette règle simple:

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

EDIT:

Je fortement recommander bobince conseils: si vous le pouvez, régler le request_order paramètre en php.ini pour "GP"; qui est, sans aucun cookie composant. Il n'y a presque aucun raisonnement rationnel dans 98% des cas, que les données de cookie ne devrait jamais être considéré comme comparable à la chaîne de requête ou postdata.

P. S., Anecdote!

Je connaissais un programmeur qui a pensé à $_REQUEST un lieu de simplement stocker des données était accessible dans une superglobale façon. Important les noms d'utilisateur et mots de passe, les chemins d'accès aux fichiers, vous le nom et il a été stocké dans $_REQUEST. Il était un peu surpris (mais pas comique, c'est le cas, malheureusement) quand je lui ai dit comment cette variable se comporte. Inutile de dire que la pratique a été déposé.

C'est vague. Vous n'avez pas vraiment savoir comment les données pour vous car il porte post, get, et les données de cookie. Je ne pense pas nécessairement que c'est toujours une mauvaise chose, à moins que vous besoin de savoir ou de restreindre la méthode de livraison.

Il est important de comprendre quand utiliser POST, quand les utiliser et OBTENIR lors de l'utilisation d'un cookie. Avec $_REQUEST, la valeur que vous êtes à la recherche à la peut venir de l'un d'eux. Si vous prévoyez d'obtenir la valeur d'un POST ou un GET ou à partir d'un COOKIE, c'est plus instructif à quelqu'un de lire votre code pour utiliser la variable spécifique au lieu de $_REQUEST.

Quelqu'un d'autre a fait remarquer également que vous ne voulez pas tous les POSTES ou les cookies pour être remplacée par l'Obtient parce qu'il y a différentes cross-site de règles pour chacun d'eux, par exemple, si vous revenez de données ajax tout en utilisant $_REQUEST, vous êtes vulnérable à un cross site script d'attaque.

J'ai peut être utilisée que si vous souhaitez récupérer l'url ou le nom d'hôte, mais pour, en fait, l'analyse des données à partir de l'URL comme parmeters en utilisant le & symbole, il est probablement pas une bonne idée. En général, vous ne voulez pas utiliser une vague description de ce que vous essayez de faire. Si vous avez besoin d'être précis, d'où $_REQUEST est mauvais, si vous n'avez pas besoin d'être précis, alors n'hésitez pas à l'utiliser. Je ne le pense.

Je pense qu'il n'y a pas de problème avec $_REQUEST, mais il faut être prudent lors de son utilisation car il est une collection de variables à partir de 3 sources (GPC).

Je suppose que $_REQUEST est toujours disponible pour rendre les anciens programmes compatibles avec les nouvelles versions de php, mais si nous lancer de nouveaux projets (y compris les nouvelles bibliothèques) je pense que nous ne devrions pas utiliser $_REQUEST plus pour rendre les programmes plus clair. Nous devrions même envisager de supprimer les utilisations de $_REQUEST et la remplacer par une fonction wrapper pour rendre le programme plus léger, en particulier dans le traitement de grandes soumis des données de texte, depuis $_REQUEST contient 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; 
    } 
  }
}

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

En PHP 7, vous pouvez le faire:

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

Cela évite les problèmes avec les cookies et vous donne, au pire, un tableau vide et, au mieux, une fusion de $_GET et $_POST avec ce dernier qui prévaut. Si vous n'êtes pas trop ennuyé avec permettant URL injection de paramètres par le biais de la chaîne de requête, c'est assez pratique.