使用はextract($_POST)
安全ではありませんか? はいの場合、これについて何ができますか?
5 に答える
はい、そうです。register_globalsと同じです。これは、誰かが「my_name」という名前の値を挿入すると、変数「my_name」が存在することを意味します。そして、それが存在する場合、どこかで変数を使用すると、スクリプトにゴミやセキュリティの問題が発生する可能性があります$my_name
phpドキュメントから:
ユーザー入力($ _GET、$ _ FILESなど)などの信頼できないデータにはextract()を使用しないでください。たとえば、register_globalsに一時的に依存する古いコードを実行する場合は、EXTR_SKIPなどの上書きされないextract_type値のいずれかを使用し、内のvariables_orderで定義されているのと同じ順序で抽出する必要があることに注意してください。 php.ini。
推奨される方法は$_POST[<varname>]
、サイトのユーザーが「安全」であるはずの変数を設定できないように、直接使用することです。
他の人が述べているように、使用extract($_POST)
は安全ではありません。安全にするために何ができるか、特に配列extract($_POST)
を常に参照しないようにするために何ができるかを尋ねました。$_POST
文字通りの答え
extract($_POST)
あなたは安全に使用することについて尋ねました。スクリプトの最初の行として、ローカル変数が定義される前に使用するか、接頭辞を付けて使用すると、ある程度安全です。ただし、どちらの場合も、その変数スコープのどこかにタイプミスによって誤ってセキュリティ ホールを導入することは決してないという危険な賭けをしています。グローバル スコープを確認するのは非常に困難です。すべてのプログラマーはタイプミスを犯し、不都合は最小限に抑えられるため、ほとんどのプログラマーは、限られた範囲や接頭辞などに関係なく、信頼できないコンテンツを絶対に使用しないことを強く推奨しています。EXTR_PREFIX_ALL
extract()
正解
$_POST
ed データは信頼できず、安全ではありません。何が含まれているか、または設定されるかどうかはわかりません。$_POST
ローカル変数に割り当てる前に「クリーニング」する必要がある「汚染された」データと考えると便利です。$_POST
その結果、ローカル変数に割り当てるときに入力を検証することで、" " の入力を最小限に抑えることができるはずです。filter_input()
PHP 5.2 以降では、およびfilter_var()
関数と検証フィルターを使用すると、これが簡単になります。
余談ですが、常に入力を検証し、出力をサニタイズする必要があります。代わりに入力をサニタイズすると、異なるコンテキストでそれらを表示する際に問題が発生する可能性があります (つまり、非 HTML ロガー、端末への出力)。出力をサニタイズしないと、XSS や SQL インジェクションなどに遭遇します。
この考え方によって推奨される経験則は、制御していない別のシステムからシステムに入るすべてのデータを「汚染された」、信頼できないものとして扱うことです。おそらく、LAN 用に開発しない限り、Web ブラウザを実行しているシステムを制御することはありません。さらに、「多層防御」は、信頼されたシステムでさえ危険にさらされる可能性があるものとして扱うことを奨励し (実際に起こります)、これはプログラマーにとって最も一般的なベスト プラクティスとなります。
はい、安全ではありません。誰でもローカル変数をオーバーライドできます (たとえば$password
、 または$access_level
)。
次のように、独自のローカル変数を宣言して割り当てることをお勧めします。
$var1 = isset($_POST['field_1'])?$_POST['field_1']:null;
$var2 = isset($_POST['field_2'])?$_POST['field_2']:null;
$var3 = isset($_POST['field_3'])?$_POST['field_3']:null;
値を変数として公開し、自分の値の一部をオーバーライドする危険を冒すのではなく、単に値を読み取っ$_POST
て何かを行う方が常に良いです...