9

私は最近、スーパーグローバルを使用することを提案する人気のある PHP 関連の回答をいくつか見つけまし$_REQUESTregister_globals

なぜ$_REQUEST悪い慣行なのかについて、適切な説明/証拠を提供できますか? 私が掘り起こしたいくつかの例を捨てて、理論的な攻撃ベクトルと現実世界のエクスプロイトの両方に関するより多くの情報/視点、およびシステム管理者がリスクを軽減するために実行できる合理的な手順の提案を楽しみにしています (アプリを書き換える...または、管理に行って書き換えを主張する必要がありますか?)。

脆弱性の例:デフォルトGPCの配列マージ順序は、COOKIE 値が GET および POST をオーバーライドすることを意味するため$_REQUEST、XSS および HTTP 攻撃に使用される可能性があります。PHP では、Cookie 変数でスーパーグローバル配列を上書きできます。このトークの最初の 10 枚のスライドは例を示しています (トーク全体が素晴らしいです)。CSRF 攻撃のphpMyAdmin エクスプロイト例。

対策の例:$_REQUEST配列のマージ順序を から GPCに再構成してCGP、GET/POST が COOKIE を上書きするようにします。その逆ではありません。Suhosinを使用して、スーパーグローバルの上書きをブロックします。

(また、私の質問がだまされたと思うかどうかは尋ねませんが、幸いなことに、 「いつ、なぜ $_GET / $_POST / $_COOKIE の代わりに $_REQUEST を使用する必要があるのか​​?」に対する圧倒的な SO の回答は「決して」でした。 )

4

4 に答える 4

6

ユーザーからデータを取得するためのメソッドです。サニタイズして検証する必要があるのに、POST、GET、Cookie のいずれの形式で送信されたかを気にする必要はありません。それらはすべてユーザーからのものなので、「なりすましの可能性がある」と言っています。余分です。

于 2008-11-03T14:20:04.030 に答える
5

$_REQUEST は、$_GET、$_POST、および $_COOKIE と同じように悪です。$_REQUEST を使用するための有効なシナリオがあると思いますが、$_REQUEST を使用しない正当な理由が 1 つあります。

$_REQUEST を使用する主な理由は、パラメータが $_POST または $_GET で転送される可能性があるためです。$_REQUEST にアクセスすることで、値が設定されている $_GET と $_POST の両方をチェックする必要がなくなります。問題は、ini 設定gpc_orderが $_REQUEST のビルド方法を変更する可能性があることです。この設定はサーバーごとに異なる場合があり、スクリプトによって動作が変わる場合があります。

于 2008-11-03T16:00:17.493 に答える
5

$_REQUEST$_GETURL ( ) とリクエストボディ ( )の違いを無視するため、問題があります$_POST。HTTP-GET リクエストには副作用がないはずですが、HTTP-POST には副作用があり、キャッシュできない場合があります。これらのまったく異なるデータ ソースを 1 つのバケツに投げ込むと、RESTに対応していないアプリケーション、つまり悪いアプリケーションが必要になります。

于 2008-11-03T17:16:15.873 に答える
0

URLで渡されるものすべてに対して脆弱です。したがって、フォームに送信された「userid」を含む非表示フィールドがフォームに含まれている場合、理論的にはユーザーはそれを編集できませんが、十分に熱心であれば、値の変更を停止することはできません。

リクエストから値を取得したいだけの場合は問題ありませんが、なりすましの可能性があることに注意する必要があるため、それに応じて行動する必要があります。また、安全なパラメータ/値データには使用しないでください。

于 2008-11-03T14:06:57.847 に答える