$ _REQUEST []の何が問題になっていますか？

$_REQUEST変数を使用しないように言っている多くの投稿をここで見ました。私は通常はしませんが、時には便利です。どうしたの？

両方から、$_GETおよび$_POST組み合わせた方法で入力を取得することにまったく問題はありません。実際、それはあなたがほとんどいつもやりたいことです：

• 通常GETを介して送信される単純なべき等の要求の場合、必要なデータの量がURLに収まらない可能性があるため、実際にはPOST要求に変換されます。

• 実際の効果があるリクエストの場合は、POSTメソッドによって送信されたことを確認する必要があります。しかし、それを行う方法は、GETで空であることに$_SERVER['REQUEST_METHOD']依存するのではなく、明示的にチェックすることです$_POST。とにかく、メソッドがのPOST場合でも、URLからいくつかのクエリパラメータを取得する必要がある場合があります。

いいえ、問題$_REQUESTはGETパラメータとPOSTパラメータの組み合わせとは関係ありません。また、デフォルトでが含まれています$_COOKIE。また、Cookieは実際にはフォーム送信パラメーターとはまったく異なります。つまり、Cookieを同じものとして扱いたいとは思わないでしょう。

フォームパラメーターの1つと同じ名前のcookieがサイトに誤って設定された場合、そのパラメーターに依存するフォームは、予期されるパラメーターをオーバーライドするcookie値のために、不思議なことに正しく機能しなくなります。これは、同じサイトに複数のアプリがある場合は非常に簡単です。古いCookieを使用しているユーザーが2、3人いるだけで、これ以上使用せずにフォームを壊す必要がない場合は、デバッグが非常に難しくなります。 -他の1人が再現できます。

PHP 5.3のrequest_order設定を使用して、この動作をより適切なGP（no C）順序に変更できます。これが不可能な場合、私は個人的には避け、組み合わせたGET + POST配列が必要な場合は手動で作成します。$_REQUEST

私はPHP Internalsに関するいくつかのニュースグループの投稿を掘り下げて調べており、このトピックに関する興味深い議論を見つけました。最初のスレッドは何か他のものに関するものでしたが、PHPの世界の（そうでないとしても）セキュリティの専門家であるStefan Esserによる発言は、いくつかの投稿で$ _REQUESTを使用することのセキュリティへの影響に向けて議論を向けました。

PHP内部でのStefan Esserの引用

$ _REQUESTは、PHPの最大の設計上の弱点の1つです。$ _REQUESTを使用するすべてのアプリケーションは、おそらくクロスサイトリクエストフォージェリの遅延の問題に対して脆弱です。（これは基本的に、たとえば（age​​）という名前のCookieが存在する場合、常にGET / POSTコンテンツを上書きするため、不要なリクエストが実行されることを意味します）

そして、で、後で同じスレッドに返信

誰かがGET、POSTを偽造できるということではありません。COOKIE変数。これは、COOKIEがREQUESTのGETおよびPOSTデータを上書きするという事実についてです。

したがって、たとえばaction = logoutと表示されるcookieをブラウザに感染させると、REQUEST [action]が永久にログアウトされるため（手動でcookieを削除するまで）、その日以降はアプリケーションを使用できなくなります。

COOKIEに感染させるのはとても簡単です...
a）サブドメインの任意のアプリケーションでXSS脆弱性を使用できます
b）所有しているときに* .co.ukまたは* .co.krにCookieを設定してみましたそこに単一のドメイン？
c）その他のクロスドメインはどのような方法でも...

これが問題ではないと思われる場合は、* * .co.kr cookieを設定して、いくつかのPHPバージョンがホワイトページを返すだけの単純な可能性があることをお伝えします。想像してみてください。*。co.kr内のすべてのPHPページを削除するための単一のCookie

そして、呼ばれる変数で* .co.krのための有効なクッキーに不正なセッションIDを設定することにより、+ PHPSESSID = 違法ことができますまだDOS PHPのセッションを使用して、韓国内のすべてのPHPアプリケーション...

ディスカッションはさらにいくつかの投稿で続けられており、読むのは興味深いものです。

ご覧のとおり、$ _ REQUESTの主な問題は、$ _ GETおよび$ _POSTからのデータだけでなく、$ _ COOKIEからのデータもあることです。リストの他の何人かは、最初に$ _COOKIEで埋めるなど、$ _ REQUESTが埋められる順序を変更することを提案しましたが、これにより、セッション処理など、他の多くの潜在的な問題が発生する可能性があります。

ただし、$ _ REQUESTグローバルから$ _COOKIESを完全に省略して、他の配列で上書きされないようにすることもできます（実際には、variable_order ini設定に関するPHPマニュアルのように、標準コンテンツの任意の組み合わせに制限できます。教えてくれ：

variable_order EGPCS（環境、取得、投稿、Cookie、およびサーバー）変数解析の順序を設定します。たとえば、variables_orderが "SP"に設定されている場合、PHPはスーパーグローバル$ _SERVERおよび$ _POSTを作成しますが、$ _ ENV、$ _ GET、および$ _COOKIEは作成しません。""に設定すると、スーパーグローバルは設定されません。

しかし、繰り返しになりますが、単純にPHPでは環境、取得、投稿、Cookie、およびサーバーに独自のグローバルでアクセスでき、攻撃ベクトルが1つ少ないため、$ _ REQUESTを完全に使用しないことも検討できます。このデータはまだサニタイズする必要がありますが、心配する必要はもう1つありません。

なぜ$ _REQUESTが存在するのか、なぜ削除されないのか疑問に思われるかもしれません。これはPHPの内部についても尋ねられました。なぜ Rasmus Lerdorfを引用して$ _REQUESTが存在するのですか？PHP内部

このようなものを削除するほど、新しい、より高速で安全なバージョンのPHPにすばやく移行することが難しくなります。これは、いくつかの「醜い」レガシー機能よりもはるかに多くのフラストレーションを引き起こします。適切な技術的な理由、パフォーマンス、またはセキュリティがある場合、私たちはそれをしっかりと検討する必要があります。この場合、$ _ REQUESTを削除する必要があるかどうかではなく、Cookieデータを削除する必要があるかどうかを確認する必要があります。私のすべてのものを含む多くの構成がすでにそれを行っており、$ _ REQUESTにCookieを含めないことには強力な有効なセキュリティ上の理由があります。ほとんどの人は$ _REQUESTを使用してGETまたはPOSTを意味し、Cookieが含まれている可能性があることを認識していません。

とにかく、いくつかの光を当てることを願っています。

$_REQUESTあらゆる種類のリクエスト（GET、POSTなど）を指します。これは便利な場合もありますが、通常は正確なメソッド（$ _GET、$ _ POSTなど）を指定する方が適切です。

$_REQUEST SQLで宣言するのではなく、アプリケーションコードで単純から中複雑度のデータ変換を実行することが多いのと同じ理由で、一般的に有害であると考えられています。

そのため、$_REQUESTどこでも使用する傾向がある場合、GETを介してPOSTを介して実行できるすべてのことを実行できます。つまり<img>、（悪意のある）サイトにタグを設定して、eコマースモジュールにログインしたユーザーに製品をサイレントで購入させるか、または危険な行動や機密情報の暴露につながるリンクをクリックする可能性があります（おそらく私にとって）。

ただし、これは、初心者、または少なくとも経験の浅いPHPプログラマが単純な間違いを犯しているためです。まず、どのタイプのデータが適切かを確認します。たとえば、URLEncoding、XML、またはJSONで応答を返すことができるWebサービスがあります。アプリケーションは、HTTP_ACCEPTヘッダーをチェックすることで応答のフォーマット方法を決定しますが、formatパラメーターを送信することにより、特に1つに強制変換できます。

formatパラメータの内容を確認する場合、さまざまな要因に応じて、クエリ文字列またはpostdataを介して送信できます。少なくとも、呼び出し元のアプリケーションがリクエストに「＆format = json」を混在させることを望んでいるかどうかは関係ありません。この場合、$_REQUESTは次のように入力する手間を省くので非常に便利です。

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

これ以上詳しく説明するつもりはありませんが、$_REQUEST使用は本質的に危険であるため、使用を中止しないでください。これは、それらの影響を理解しているかどうかにかかわらず、要求された内容を正確に実行する別のツールです-それはこの問題を引き起こす貧しい、怠惰な、または経験の浅いプログラマーの貧しい、怠惰な、または知識のない決定。

$_REQUEST安全に使用する方法

1. データを知る：取得するデータの種類についてある程度の期待が必要なので、それに応じてサニタイズします。データベースのデータ？ addslashes()または*_escape_string()。それをユーザーに表示するつもりですか？htmlentities()またはhtmlspecialchars()。数値データを期待していますか？ is_numeric()またはctype_digit()。実際、filter_input()その関連機能は、データのチェックとサニタイズのみを行うように設計されています。常にこれらのツールを使用してください。
2. ユーザーが提供するスーパーグローバルデータに直接アクセスしないでください。毎回データをサニタイズする習慣をつけて、データが正しい場合でも、データをクリーンな変数に移動します$post_clean。また、あなただけのスーパーグローバルに直接きれいにすることができる、しかしとしてそうすることが、それは簡単なコードの脆弱性を発見することができますので、私は別の変数を使用して提唱する理由は何もその消毒同等のスーパーグローバルではなく直接指しては危険なエラーと考えられています。
3. データの送信元を把握します。上記の私の例を参照すると、GETまたはPOSTを介して応答フォーマット変数を送信できるようにすることは完全に合理的です。「action」変数をどちらの方法でも送信できるようにしています。ただし、アクション自体には、どのHTTP動詞が受け入れられるかに関して非常に特定の要件があります。たとえば、サービスが使用するデータを変更する関数は、POST経由でのみ送信できます。特定のタイプの非特権データまたは低特権データ（動的に生成されたマップ画像など）に対する要求は、いずれかのメソッドからの要求に応じて処理されます。

結論として、この単純なルールを覚えておいてください：

セキュリティはあなたがそれを作るものです、人々！

編集：

ボビンスのアドバイスを強くお勧めします。可能であればrequest_order、php.ini のパラメーターを "GP" に設定してください。つまり、Cookieコンポーネントはありません。cookieデータがクエリ文字列やpostdataと同等であると見なされることはほとんどないので、98％以上のケースでは、これに対する合理的な理由はほとんどありません。

PS、逸話！

$_REQUESTスーパーグローバルな方法でアクセスできるデータを単純に保存する場所を考えているプログラマーを知っていました。重要なユーザー名とパスワード、ファイルへのパス、名前を付けると、に保存されました$_REQUEST。その変数がどのように動作するかを私が彼に言ったとき、彼は少しびっくりしました（ただし、滑稽ではありませんでしたが）。言うまでもなく、その慣行は廃止されました。

GETリクエストはべき等である必要があり、POSTリクエストは通常​​べき等ではありません。内のデータというこの手段$_GETとは$_POST、一般的に異なる方法で使用する必要があります。

アプリケーションがからのデータを使用している場合、$_REQUESTGET要求とPOST要求の両方で同じように動作し、GETのべき等に違反します。

あいまいです。データにはpost、get、cookieデータが含まれているため、データがどのように取得されたかは実際にはわかりません。あなたが配達の方法を知っているか、制限する必要がない限り、私は必ずしもそれが必ずしも悪いことだとは思いません。

私は実際にそれを使うのが好きです。ほとんどの場合データがPOSTされる検索フォームなどに便利なGETまたはPOSTを使用する柔軟性を提供しますが、特定の検索へのリンクを言いたい場合があるため、代わりにGETパラメータを使用できます。

また、他の多くの言語（ASP.NETなど）を見ると、GET変数とPOST変数はまったく区別されていません。

ETA：

COOKIEの値を取得するためにREQUESTを使用したことはありませんが、Kyle Buttは、この投稿についてのコメントで大きな指摘をしていると思います。COOKIE値を取得するためにREQUESTを使用することはお勧めできません。そうした場合、クロスサイトリクエストフォージェリの潜在的な可能性があるというのは彼の言う通りだと思います。

また、ものがREQUESTに読み込まれる順序は、php.iniの構成パラメーター（variables_orderおよびrequest_order）によって制御されます。したがって、POSTとGETの両方を介して渡された同じ変数がある場合、実際にREQUESTに入るのはそれらのini設定によって異なります。特定の順序に依存していて、それらの設定が予想とは異なる構成になっている場合、これは移植性に影響を与える可能性があります。

POSTを使用する場合、GETを使用する場合、およびCookieを使用する場合を理解することが重要です。$ _REQUESTを使用すると、あなたが見ている値はそれらのどれからでも得られる可能性があります。POSTまたはGETから、あるいはCOOKIEから値を取得すると予想される場合、コードを読んでいる誰かが$ _REQUESTの代わりに特定の変数を使用するほうが有益です。

他の誰かが、すべてのPOSTまたはCookieがGETによって上書きされることを望まないことも指摘しました。たとえば、それらすべてに異なるクロスサイトルールがあるため、$ _ REQUESTを使用しているときにajaxデータを返すと、脆弱になりますクロスサイトスクリプト攻撃へ。

$_REQUESTGET を使用するのは悪い考えではありません。

• これを使用してPOST値をロードすると、クロスサイトリクエストフォージェリが発生する危険性があります。
• これを使用してCookie値をロードすると、クロスサイトリクエストフォージェリのリスクが再び発生します。

そして、GETを使用しても、$_GETタイプするのは$_REQUEST;）よりも短くなります。

現在のURLまたはホスト名を取得する場合にのみ使用できますが、＆記号を使用するパラメーターなど、そのURLから実際にデータを解析する場合は、おそらくお勧めできません。一般的に、何をしようとしているのか漠然とした説明は使いたくないでしょう。$ _REQUESTが悪い場所で具体的にする必要がある場合、具体的にする必要がない場合は、自由に使用してください。私は思います。

必要なデータがわかっている場合は、明示的に要求する必要があります。IMO、GET、およびPOSTは2つの異なる動物であり、投稿データとクエリ文字列を混在させる必要がある理由はよくわかりません。誰かが持っているなら、私は興味があります。

スクリプトが同じ方法でGETまたはPOSTに応答する可能性がある場合は、$ _ REQUESTを使用すると便利です。これは非常にまれなケースであると私は主張しますが、ほとんどの場合、2つの別々の概念を処理する2つの別々の関数、または少なくともメソッドをチェックして正しい変数を選択することが推奨されます。変数がどこから来ているのかを相互参照する必要がない場合は、通常、プログラムフローを追跡する方がはるかに簡単です。6か月後にコードを保守する必要がある人に親切にしてください。それはあなたかもしれません。

REQUEST変数のCookieと環境変数によって引き起こされるセキュリティの問題とWTF（グローバルから始めないでください）に加えて、PHPがPUTやDELETEなどの他のメソッドをネイティブでサポートし始めた場合、将来どうなるかを検討してください。これらがREQUESTスーパーグローバルにマージされる可能性は非常に低いですが、それらがvariable_order設定のオプションとして含まれる可能性があります。したがって、特にコードがサードパーティのサーバーにデプロイされている場合は、REQUESTが何を保持し、何が優先されているのかまったくわかりません。

POSTはGETより安全ですか？あんまり。攻撃を受けたときにアプリケーションがどのように悪用されているかをログで確認しやすいため、実用的な場所でGETを使用することをお勧めします。POSTは、ドメインの状態に影響を与える操作に適しています。通常、スパイダーはドメインの状態を追跡せず、CMSにログインしたときに予測フェッチメカニズムによってすべてのコンテンツが削除されるわけではありません。ただし、問題はGETとPOSTのメリットについてではなく、受信者が受信データをどのように処理するか、なぜマージするのが悪いのかということだったので、これは実際には単なるBTWです。

は問題ないと思いますが$_REQUEST、3つのソース（GPC）からの変数のコレクションなので、使用するときは注意が必要です。

$_REQUEST古いプログラムを新しいphpバージョンと互換性を保つためにまだ利用できると思いますが、新しいプロジェクト（新しいライブラリを含む）を開始する場合$_REQUEST、プログラムをより明確にするためにこれ以上使用すべきではないと思います。$_REQUEST特にの$_REQUESTコピーが含まれているため、送信された大量のテキストデータを処理する場合は、プログラムを軽量化するために、の使用を削除してラッパー関数で置き換えることも検討する必要があり$_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：「php 5.3以降、デフォルトのphp.iniはGETとPOSTのデータのみがに入れられると言っています。php.net/request_orderを$_REQUEST参照してください。cookieデータが存在すると予期していて、なぜそうなっていないのか疑問に思ったときに、後方互換性の問題に遭遇しました。$_REQUESTt動作している！」

うわぁ... PHP 5.3にアップグレードしたため、スクリプトの一部が機能しなくなっただけです。同じことを行いました：$_REQUEST変数を使用するときにCookieが設定されると想定します。アップグレードにより、機能しなくなりました。

今私はクッキーの値を別々に呼び出します$_COOKIE["Cookie_name"]...

中心的な問題は、他の人が言ったように、Cookieが含まれていることです。

PHP 7ではこれを行うことができます：

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

これにより、Cookieの問題が回避され、最悪の場合は空の配列が提供され、せいぜい$ _GETと$ _POSTがマージされ、後者が優先されます。クエリ文字列を介してパラメータのURLインジェクションを許可することにそれほど煩わされない場合は、非常に便利です。

それは非常に安全ではありません。また、POSTとGETのどちらを取得するのか、または別の要求を取得するのかわからないため、扱いにくいです。アプリケーションを設計するときは、両者の違いを本当に知っておく必要があります。GETはURLで渡されるため非常に安全ではなく、ページナビゲーション以外にはほとんど適していません。POST自体は安全ではありませんが、1レベルの安全性を提供します。