Ich habe in letzter Zeit einige beliebte PHP-bezogene Antworten gefunden, die die Verwendung des superglobalen @ vorgeschlagen habe$_REQUEST, das ich als Code-Geruch betrachte, weil es mich an @ erinneregister_globals.

Kannst du eine gute Erklärung / einen Beweis dafür liefern, warum$_REQUEST ist schlechte Praxis? Ich werde ein paar Beispiele herausbringen, die ich ausgegraben habe, und würde gerne mehr Informationen / Perspektiven sowohl zu theoretischen Angriffsvektoren als auch zu realen Exploits sowie Vorschläge vernünftiger Schritte des Sysadmins zur Risikominimierung (kurz: Umschreiben der App ... oder machen wirbrauche, um zum Management zu gehen und auf einem Umschreiben zu bestehen?).

Beispiel für Sicherheitslücken: StandardGPC array merge-order bedeutet, dass COOKIE-Werte GET und POST überschreiben, also$_REQUEST kann für XSS- und HTTP-Angriffe verwendet werden. Mit PHP können Cookie-Variablen die superglobalen Arrays überschreiben. Die ersten 10 Folien vondieses Gespräch gib Beispiele (ganze Rede ist toll).phpMyAdmin exploit Beispiel für einen CSRF-Angriff.

Beispiel für Gegenmaßnahmen: Neu konfigurieren$_REQUEST Array Merge-Reihenfolge vonGPC zuCGP so GET / POST COOKIE überschreiben, nicht umgekehrt. Verwenden Suhosin, um das Überschreiben von Superglobalen zu blockieren.

(Ich würde auch nicht fragen, ob ich dachte, meine Frage wäre ein Betrüger, aber zum Glück die überwältigende SO Antwort auf "Wann und warum sollte $ _REQUEST anstelle von $ _GET / $ _POST / $ _COOKIE verwendet werden?" war nie."