Was ist falsch an der Verwendung von $ _REQUEST []?

Ich habe hier eine Reihe von Beiträgen gesehen, in denen gesagt wurde, die $_REQUESTVariable nicht zu verwenden . Normalerweise nicht, aber manchmal ist es praktisch. Was stimmt damit nicht?

Es ist absolut nichts Falsches daran, Eingaben von beiden $_GETund $_POSTauf kombinierte Weise zu erhalten. Genau das möchten Sie fast immer tun:

• Bei einer einfachen idempotenten Anfrage, die normalerweise über GET gesendet wird, besteht die Möglichkeit, dass die gewünschte Datenmenge nicht in eine URL passt, sodass sie aus praktischen Gründen stattdessen zu einer POST-Anfrage mutiert wurde.

• Für eine Anfrage, die einen echten Effekt hat, müssen Sie überprüfen, ob sie von der POST-Methode gesendet wurde. Der Weg, dies zu tun, besteht darin, $_SERVER['REQUEST_METHOD']explizit zu überprüfen und sich nicht darauf zu verlassen $_POST, dass ein GET leer ist. Wenn dies der POSTFall ist , möchten Sie möglicherweise dennoch einige Abfrageparameter aus der URL entfernen.

Nein, das Problem mit $_REQUESThat nichts mit dem Zusammenführen von GET- und POST-Parametern zu tun. Es ist so, dass es standardmäßig auch enthält$_COOKIE . Und Cookies sind wirklich überhaupt keine Parameter für die Formularübermittlung: Sie möchten sie fast nie als dasselbe behandeln.

Wenn auf Ihrer Site versehentlich ein Cookie mit demselben Namen wie einer Ihrer Formularparameter gesetzt wird, funktionieren die Formulare, die auf diesem Parameter basieren, auf mysteriöse Weise nicht mehr ordnungsgemäß, da die Cookie-Werte die erwarteten Parameter überschreiben. Dies ist sehr einfach, wenn Sie mehrere Apps auf derselben Site haben, und kann sehr schwer zu debuggen sein, wenn Sie nur ein paar Benutzer mit alten Cookies haben, die Sie nicht mehr verwenden, um herumzuhängen und die Formulare auf eine Weise zu brechen, nein -eine andere kann reproduzieren.

Sie können dieses Verhalten mit der request_order- Konfiguration in PHP 5.3 in eine viel sinnvollere GP(keine C) Reihenfolge ändern . Wo dies nicht möglich ist, würde ich persönlich vermeiden $_REQUESTund, wenn ich ein kombiniertes GET + POST-Array benötige, es manuell erstellen.

Ich habe einige Newsgroup-Beiträge zu PHP Internals durchgesehen und eine interessante Diskussion zu diesem Thema gefunden. Der erste Thread handelte von etwas anderem, aber einer Bemerkung von Stefan Esser, einem (wenn nicht dem ) Sicherheitsexperten in der PHP-Welt, lenkte die Diskussion auf die Sicherheitsauswirkungen der Verwendung von $ _REQUEST für einige Posts.

Unter Berufung auf Stefan Esser über PHP Internals

$ _REQUEST ist eine der größten Designschwächen in PHP. Jede Anwendung, die $ _REQUEST verwendet, ist höchstwahrscheinlich anfällig für Probleme mit verzögerten Cross Site Request Forgery. (Dies bedeutet im Grunde, dass wenn beispielsweise ein Cookie mit dem Namen (Alter) vorhanden ist, der GET / POST-Inhalt immer überschrieben wird und daher unerwünschte Anforderungen ausgeführt werden.)

und in einer späteren Antwort auf den gleichen Thread

Es geht nicht darum, dass jemand GET, POST fälschen kann; COOKIE-Variablen. Es geht um die Tatsache, dass COOKIEs GET- und POST-Daten in REQUEST überschreiben.

Daher könnte ich Ihren Browser mit einem Cookie infizieren, das zB action = logout lautet, und von diesem Tag an können Sie die Anwendung nicht mehr verwenden, da REQUEST [action] für immer abgemeldet ist (bis Sie das Cookie manuell löschen).

Und Sie mit einem COOKIE zu infizieren ist so einfach ...
a) Ich könnte eine XSS-Vuln in jeder Anwendung auf einer Subdomain verwenden.
B ) Ich habe jemals versucht, ein Cookie für * .co.uk oder * .co.kr zu setzen, wenn Sie ein besitzen Single Domain da?
c) Andere domänenübergreifende Möglichkeiten ...

Und wenn Sie glauben, dass dies kein Problem ist, kann ich Ihnen sagen, dass es eine einfache Möglichkeit gibt, z. B. ein * .co.kr-Cookie zu setzen, das dazu führt, dass mehrere PHP-Versionen nur weiße Seiten zurückgeben. Stellen Sie sich vor: Nur ein einziges Cookie, um alle PHP-Seiten in * .co.kr zu beenden

Und indem Sie eine illegale Sitzungs-ID in einem für * .co.kr gültigen Cookie in einer Variablen namens + PHPSESSID = illegal festlegen , können Sie weiterhin jede PHP-Anwendung in Korea mit PHP-Sitzungen DOSEN ...

Die Diskussion wird für einige weitere Beiträge fortgesetzt und ist interessant zu lesen.

Wie Sie sehen können, besteht das Hauptproblem bei $ _REQUEST nicht darin, dass es Daten von $ _GET und $ _POST enthält, sondern auch von $ _COOKIE. Einige andere Leute auf der Liste schlugen vor, die Reihenfolge zu ändern, in der $ _REQUEST gefüllt wird, z. B. zuerst $ _COOKIE, aber dies könnte zu zahlreichen anderen potenziellen Problemen führen, beispielsweise bei der Sitzungsbehandlung .

Sie können jedoch $ _COOKIES in der globalen $ _REQUEST-Liste vollständig weglassen, damit es von keinem der anderen Arrays überschrieben wird (Sie können es sogar auf eine beliebige Kombination seiner Standardinhalte beschränken, wie das PHP-Handbuch in der Einstellung variable_order ini sagt uns:

variable_order Legt die Reihenfolge der Analyse der EGPCS-Variablen (Environment, Get, Post, Cookie und Server) fest. Wenn beispielsweise variables_order auf "SP" gesetzt ist, erstellt PHP die Superglobalen $ _SERVER und $ _POST, jedoch nicht $ _ENV, $ _GET und $ _COOKIE. Die Einstellung auf "" bedeutet, dass keine Superglobalen gesetzt werden.

Andererseits könnten Sie auch in Betracht ziehen, $ _REQUEST nicht vollständig zu verwenden, einfach weil Sie in PHP auf Umgebung, Get, Post, Cookie und Server in ihren eigenen Globals zugreifen können und einen Angriffsvektor weniger haben. Sie müssen diese Daten noch bereinigen, aber Sie müssen sich weniger Sorgen machen.

Nun fragen Sie sich vielleicht, warum $ _REQUEST überhaupt existiert und warum es nicht entfernt wird. Dies wurde auch bei PHP Internals gefragt. Unter Berufung auf Rasmus Lerdorf über Warum gibt es $ _REQUEST? auf PHP Internals

Je mehr solche Dinge wir entfernen, desto schwieriger wird es für die Leute, schnell auf neuere, schnellere und sicherere Versionen von PHP umzusteigen. Das ist für alle weitaus frustrierender als ein paar "hässliche" Legacy-Funktionen. Wenn es einen anständigen technischen Grund, Leistung oder Sicherheit gibt, müssen wir uns das genau ansehen. In diesem Fall sollten wir uns nicht ansehen, ob wir $ _REQUEST entfernen sollen, sondern ob wir Cookie-Daten daraus entfernen sollen. Viele Konfigurationen tun dies bereits, einschließlich meiner eigenen, und es gibt einen starken gültigen Sicherheitsgrund dafür, dass Cookies nicht in $ _REQUEST enthalten sind. Die meisten Leute verwenden $ _REQUEST, um GET oder POST zu bezeichnen, ohne zu wissen, dass es auch Cookies enthalten könnte, und als solche könnten Bösewichte möglicherweise einige Tricks zur Cookie-Injektion ausführen und naive Anwendungen brechen.

Wie auch immer, hoffe, das bringt etwas Licht.

$_REQUESTbezieht sich auf alle Arten von Anfragen (GET, POST usw.). Dies ist manchmal nützlich, aber normalerweise ist es besser, die genaue Methode anzugeben ($ _GET, $ _POST usw.).

$_REQUEST wird im Allgemeinen aus dem gleichen Grund als schädlich angesehen, aus dem Datentransformationen mit einfacher bis mittlerer Komplexität häufig im Anwendungscode ausgeführt werden, anstatt in SQL deklariert zu werden: Einige Programmierer saugen.

Wenn man also dazu neigt, $_REQUESTüberall zu verwenden , kann ich über GET alles tun, was ich über POST tun könnte. Dies bedeutet, dass <img>auf meiner (böswilligen) Website Tags eingerichtet werden, die dazu führen, dass Benutzer, die in Ihrem E-Commerce-Modul angemeldet sind, stillschweigend Produkte kaufen, oder ich kann dazu führen, dass sie auf Links klicken, die zu gefährlichen Handlungen oder zur Offenlegung sensibler Informationen führen (wahrscheinlich für mich).

Dies liegt jedoch daran, dass ein unerfahrener oder zumindest unerfahrener PHP-Programmierer einfache Fehler macht. Stellen Sie zunächst fest, wann Daten von welchem ​​Typ geeignet sind. Zum Beispiel habe ich einen Webdienst, der Antworten in URLEncoding, XML oder JSON zurückgeben kann. Die Anwendung entscheidet, wie die Antwort formatiert werden soll, indem der HTTP_ACCEPT-Header überprüft wird. Sie kann jedoch durch Senden des formatParameters zu einem bestimmten Header gezwungen werden.

Bei der Überprüfung des Inhalts des Formatparameters kann dieser abhängig von einer Vielzahl von Faktoren über Querystring oder Postdata gesendet werden, nicht zuletzt, ob die aufrufenden Anwendungen "& format = json" mit ihrer Anforderung mischen möchten oder nicht. In diesem Fall $_REQUESTist dies sehr praktisch, da ich so etwas nicht eingeben muss:

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

Ich werde nicht viel weiter streifen, aber es genügt zu sagen, dass die $_REQUESTVerwendung nicht davon abgeraten wird, weil sie von Natur aus gefährlich ist - es ist nur ein weiteres Werkzeug, das genau das tut, was von ihm verlangt wird, ob Sie diese Implikationen verstehen oder nicht - es ist das schlechte, faule oder nicht informierte Entscheidung eines armen, faulen oder unerfahrenen Programmierers, die dieses Problem verursacht.

Wie man $_REQUESTsicher benutzt

1. Kennen Sie Ihre Daten : Sie sollten eine gewisse Erwartung haben, welche Art von Daten Sie erhalten, also bereinigen Sie sie entsprechend. Daten für eine Datenbank? addslashes()oder *_escape_string(). Wirst du es dem Benutzer wieder zeigen? htmlentities()oder htmlspecialchars(). Erwarten Sie numerische Daten? is_numeric()oder ctype_digit(). Tatsächlich dienen filter_input()die zugehörigen Funktionen lediglich dazu, Daten zu überprüfen und zu bereinigen. Verwenden Sie diese Werkzeuge immer.
2. Greifen Sie nicht direkt auf vom Benutzer bereitgestellte Superglobaldaten zu . Machen Sie es sich zur Gewohnheit, Ihre Daten jedes Mal zu bereinigen, und verschieben Sie Ihre Daten in saubere Variablen, auch wenn dies nur der Fall ist $post_clean. Alternativ können Sie auch direkt in den Superglobalen bereinigen. Ich befürworte jedoch die Verwendung einer separaten Variablen, da dies das Erkennen von Schwachstellen im Code erleichtert, da alles, was direkt auf eine Superglobale und nicht auf deren bereinigtes Äquivalent verweist, als gefährlicher Fehler angesehen wird .
3. Wissen Sie, woher Ihre Daten stammen sollen. Unter Bezugnahme auf mein Beispiel von oben ist es durchaus sinnvoll, die Antwortformatvariable über GET oder POST senden zu lassen. Ich erlaube auch, dass die Variable "action" über eine der beiden Methoden gesendet wird. Die Aktionen selbst haben jedoch sehr spezifische Anforderungen, welches HTTP-Verb akzeptabel ist . Funktionen, die beispielsweise Änderungen an den vom Dienst verwendeten Daten vornehmen, dürfen nur per POST gesendet werden. Anforderungen für bestimmte Arten von Daten ohne oder mit geringen Berechtigungen (z. B. dynamisch generierte Kartenbilder) können als Antwort auf Anforderungen von beiden Methoden zugestellt werden.

Denken Sie abschließend an diese einfache Regel:

SICHERHEIT IST, WAS SIE MACHEN, MENSCHEN!

BEARBEITEN:

Ich stark bobince Rat empfehlen: wenn Sie können, den eingestellten request_orderParameter in php.ini auf „GP“; Das heißt, keine Cookie-Komponente. In über 98% der Fälle gibt es dafür fast keine vernünftigen Gründe, da Cookie-Daten fast nie als mit dem Querystring oder den Postdaten vergleichbar angesehen werden sollten.

PS, Anekdote!

Ich kannte einen Programmierer, der an $_REQUESTeinen Ort dachte, an dem einfach Daten gespeichert werden konnten, auf die superglobal zugegriffen werden konnte. Wichtige Benutzernamen und Passwörter, Pfade zu Dateien, Sie benennen es und es wurde in gespeichert $_REQUEST. Er war ein bisschen überrascht (wenn auch leider nicht komisch), als ich ihm erzählte, wie sich diese Variable verhält. Unnötig zu erwähnen, dass diese Praxis abgesetzt wurde.

GET-Anforderungen sollten idempotent sein und POST-Anforderungen im Allgemeinen nicht. Dies bedeutet, dass Daten in $_GETund $_POSTim Allgemeinen auf unterschiedliche Weise verwendet werden sollten.

Wenn Ihre Anwendung Daten von verwendet $_REQUEST, verhält sie sich für GET- und POST-Anforderungen gleich, was die Idempotenz von GET verletzt.

Es ist vage. Sie wissen nicht wirklich , wie die Daten zu Ihnen gelangt sind, da sie Post-, Get- und Cookie-Daten enthalten. Ich denke nicht unbedingt, dass dies immer eine schlechte Sache ist, es sei denn, Sie müssen die Versandart kennen oder einschränken.

Ich benutze es eigentlich gerne. Es gibt Ihnen die Flexibilität, GET oder POST zu verwenden, was sich für Suchformulare als nützlich erweisen kann, bei denen die meisten Zeitdaten POST-fähig sind. Manchmal möchten Sie jedoch einen Link zu einer bestimmten Suche angeben, sodass Sie stattdessen GET-Parameter verwenden können .

Wenn Sie sich viele andere Sprachen ansehen (z. B. ASP.NET), unterscheiden sie überhaupt nicht zwischen GET- und POST-Variablen.

ETA :

Ich habe REQUEST noch nie verwendet, um COOKIE-Werte zu erhalten, aber ich denke, Kyle Butt macht in den Kommentaren zu diesem Beitrag einen großen Punkt darüber. Es ist keine gute Idee, REQUEST zu verwenden, um COOKIE-Werte zu erhalten. Ich glaube, er hat Recht, dass es ein echtes Potenzial für die Fälschung von standortübergreifenden Anfragen gibt, wenn Sie dies tun.

Außerdem wird die Reihenfolge, in der Inhalte in REQUEST geladen werden, durch Konfigurationsparameter in der php.ini (variables_order und request_order) gesteuert. Wenn Sie also dieselbe Variable über POST und GET übergeben haben, hängt es tatsächlich von diesen INI-Einstellungen ab, welche tatsächlich in REQUEST eingeht. Dies kann die Portabilität beeinträchtigen, wenn Sie von einer bestimmten Reihenfolge abhängig sind und diese Einstellungen anders konfiguriert sind, als Sie es erwarten.

Es ist wichtig zu verstehen, wann POST verwendet wird, wann GET verwendet wird und wann ein Cookie verwendet wird. Mit $ _REQUEST könnte der Wert, den Sie betrachten, von einem von ihnen stammen. Wenn Sie erwarten, den Wert von einem POST oder einem GET oder von einem COOKIE zu erhalten, ist es für jemanden, der Ihren Code liest, informativer, die spezifische Variable anstelle von $ _REQUEST zu verwenden.

Jemand anderes wies auch darauf hin, dass Sie nicht möchten, dass alle POSTs oder Cookies von GETs überschrieben werden, da für alle unterschiedliche standortübergreifende Regeln gelten. Wenn Sie beispielsweise Ajax-Daten zurückgeben, während Sie $ _REQUEST verwenden, sind Sie anfällig zu einem Cross-Site-Skript-Angriff.

Die einzige Verwendung $_REQUESTist keine schlechte Idee, wenn Sie GET verwenden.

• Wenn Sie damit POST-Werte laden, riskieren Sie Fälschungen von standortübergreifenden Anforderungen
• Wenn Sie damit Cookie-Werte laden, riskieren Sie erneut Fälschungen von standortübergreifenden Anforderungen

Und selbst mit GET $_GETist die Eingabe kürzer als $_REQUEST;)

Ich werde möglicherweise nur verwendet, wenn Sie die aktuelle URL oder den aktuellen Hostnamen abrufen möchten, aber zum tatsächlichen Parsen von Daten von dieser URL, z. B. Parmetern mit dem Symbol &, ist dies wahrscheinlich keine gute Idee. Im Allgemeinen möchten Sie keine vage Beschreibung dessen verwenden, was Sie versuchen zu tun. Wenn Sie spezifisch sein müssen, ist $ _REQUEST schlecht. Wenn Sie nicht spezifisch sein müssen, können Sie es gerne verwenden. Ich würde denken.

Wenn Sie wissen, welche Daten Sie möchten, sollten Sie explizit danach fragen. IMO, GET und POST sind zwei verschiedene Tiere, und ich kann mir keinen guten Grund vorstellen, warum Sie jemals Post-Daten und Abfragezeichenfolgen mischen müssten. Wenn jemand einen hat, wäre ich interessiert.

Es kann praktisch sein, $ _REQUEST zu verwenden, wenn Ihre Skripte auf dieselbe Weise auf GET oder POST reagieren. Ich würde jedoch argumentieren, dass dies ein äußerst seltener Fall sein sollte, und in den meisten Fällen werden zwei separate Funktionen bevorzugt, um zwei separate Konzepte zu handhaben oder zumindest die Methode zu überprüfen und die richtigen Variablen auszuwählen. Der Programmablauf ist normalerweise viel einfacher zu verfolgen, wenn kein Querverweis erforderlich ist, woher die Variablen stammen könnten. Seien Sie freundlich zu der Person, die Ihren Code in 6 Monaten pflegen muss. Es könntest du sein.

Überlegen Sie zusätzlich zu den Sicherheitsproblemen und WTFs, die durch Cookies und Umgebungsvariablen in der REQUEST-Variablen verursacht werden (lassen Sie mich nicht mit GLOBAL beginnen), was in Zukunft passieren könnte, wenn PHP andere Methoden wie PUT und DELETE nativ unterstützt. Obwohl es äußerst unwahrscheinlich ist, dass diese in die Superglobale REQUEST integriert werden, ist es möglich, dass sie als Option in die Einstellung variable_order aufgenommen werden. Sie haben also wirklich keine Ahnung, was REQUEST enthält und was Vorrang hat, insbesondere wenn Ihr Code auf einem Server eines Drittanbieters bereitgestellt wird.

Ist POST sicherer als GET? Nicht wirklich. Es ist besser, GET zu verwenden, wenn dies praktisch ist, da Sie in Ihren Protokollen leichter sehen können, wie Ihre Anwendung ausgenutzt wird, wenn sie angegriffen wird. POST ist besser für Vorgänge geeignet, die sich auf den Domänenstatus auswirken, da Spider ihnen im Allgemeinen nicht folgen und vorausschauende Abrufmechanismen nicht alle Ihre Inhalte löschen, wenn Sie sich bei Ihrem CMS anmelden. Bei der Frage ging es jedoch nicht um die Vorzüge von GET gegenüber POST, sondern darum, wie der Empfänger die eingehenden Daten behandeln sollte und warum es schlecht ist, sie zusammenzuführen. Dies ist also wirklich nur eine BTW.

Ich denke, es gibt kein Problem damit $_REQUEST, aber wir müssen vorsichtig sein, wenn wir es verwenden, da es eine Sammlung von Variablen aus 3 Quellen (GPC) ist.

Ich denke, es $_REQUESTist immer noch verfügbar, um alte Programme mit neuen PHP-Versionen kompatibel zu machen, aber wenn wir neue Projekte (einschließlich neuer Bibliotheken) starten, sollten wir sie meiner Meinung nach nicht $_REQUESTmehr verwenden, um die Programme klarer zu machen. Wir sollten sogar in Betracht ziehen, Verwendungen zu löschen $_REQUESTund durch eine Wrapper-Funktion zu ersetzen, um das Programm leichter zu machen, insbesondere bei der Verarbeitung großer übermittelter Textdaten, da es $_REQUESTKopien von enthält $_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 Koch: „Seit PHP 5.3 der Standard php.ini sagt nur GET und POST - Daten setzen in $_REQUESTSee. Php.net/request_order Ich stolperte auf dieser Abwärtskompatibilität Pause , wenn Cookie - Daten erwartet in sein $_REQUESTund sich fragen , warum es wasn‘ funktioniert nicht! "

Wow ... einige meiner Skripte funktionierten aufgrund eines Upgrades auf PHP 5.3 nicht mehr . Haben Sie dasselbe getan: Nehmen Sie an, dass bei Verwendung der $_REQUESTVariablen Cookies gesetzt werden . Mit dem Upgrade funktionierte genau das nicht mehr.

Ich rufe Cookie-Werte jetzt separat mit $_COOKIE["Cookie_name"]...

Das zentrale Problem ist, dass es Cookies enthält, wie andere gesagt haben.

In PHP 7 können Sie dies tun:

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

Dies vermeidet das Cookie-Problem und gibt Ihnen im schlimmsten Fall ein leeres Array und bestenfalls eine Fusion von $ _GET und $ _POST, wobei letzteres Vorrang hat. Wenn Sie nicht zu sehr damit beschäftigt sind, die URL-Injektion von Parametern über die Abfragezeichenfolge zuzulassen, ist dies sehr praktisch.

Es ist sehr unsicher. Es ist auch umständlich, da Sie nicht wissen, ob Sie einen POST oder einen GET oder eine andere Anfrage erhalten. Sie sollten den Unterschied zwischen ihnen beim Entwerfen Ihrer Anwendungen wirklich kennen. GET ist sehr unsicher, da es in der URL übergeben wird und für fast nichts anderes als die Seitennavigation geeignet ist. POST ist zwar selbst nicht sicher, bietet jedoch eine Sicherheitsstufe.