downloads | documentation | faq | getting help | mailing lists | licenses | wiki | reporting bugs | php.net sites | links | conferences | my php.net

search for in the

ケース 1: 配布制限がないファイルのみを配布> <CGI バイナリとしてインストール
[edit] Last updated: Fri, 10 Feb 2012

view this page in

受ける可能性がある攻撃

PHP を CGI バイナリとして使用するのは、PHP を モジュールとして(Apache のような)サーバーソフトウエアに組み込み たくない何らかの理由がある場合や安全な chroot と setuid 環境をス クリプトに提供する他の CGI ラッパーと組み合わせて PHP を使用する 場合の設定オプションです。セットアップ時には、通常、PHP 実行バイ ナリを Web サーバーの cgi-bin ディレクトリにインストールします。 CERT 勧告 » CA-96.11は、いかなるイ ンタプリタを cgi-bin に置くことにも反対しています。 PHP バイナリをスタンドアロンのインタプリタとして使用することが できる場合でも、PHP は、セットアップにより生じる可能性がある 次のような攻撃を防ぐように設計されています。

  • システムファイルへのアクセス: http://my.host/cgi-bin/php?/etc/passwd URL において疑問符 (?) の後のクエリー情報は、CGI インターフェー スにより、インタプリタにコマンドライン引数として渡されます。通 常、インタプリタは、コマンドライン上の最初の引数に指定されたファ イルを開き、実行します。 CGI バイナリとして実行された場合、PHP は、コマンドライン引数の 解釈を拒否します。
  • サーバー上の Web ドキュメントへのアクセス: http://my.host/cgi-bin/php/secret/doc.html URL の PHP バイナリ名の後のパス情報の部分、つまり/secret/doc.html は、 CGI プログラムによりオープンされて実行される ファイルの名前を指定するために従来より使用されています。 http://my.host/secret/script.php のようなドキュメントへの要求を PHP インタプリタにリダイレクト するために、通常、何らかの Web サーバー設定用命令(Apache では Action) が使用されます。この設定により、Web サーバーは、まずディレクトリ /secret へのアクセス権をチェックし、 リダイレクト要求 http://my.host/cgi-bin/php/secret/script.php を生成します。残念なことに、リクエストが最初からこの形式で与え られた場合、Web サーバーによるアクセスチェックは、 /secret/script.php ファイル ではなく、/cgi-bin/php ファイル に対して行われます。この手法により、/cgi-bin/php にアクセス可能なユーザーは、 Web サーバー上の全ての保護されたドキュメントにアクセスできてし まいます。 PHP では、サーバードキュメントツリーにアクセス制限付きのディレ クトリがある場合、設定ディレクティブ cgi.force_redirectdoc_root および user_dir をこの攻撃を防止す るために使用することができます。 これらを組み合わせたいくつか の手法について以下に詳細な説明を示します。


add a note add a note User Contributed Notes 受ける可能性がある攻撃
bill1 at nospam dot windhome dot com 04-Feb-2012 09:48
Under possible attacks, there are attacks on the php file themselves. Some php viruses, (injecktor and variations) scan the visible directory tree for php and/or html files, then inject code (such as spam-ware to generate fraudulent page hits) into otherwise harmless and useful .php scripts. One way to block this is by using open_basedir to restrict the visible file system directories to directory tree(s) which do NOT contain any .php scripts. (see doc page "Description of core php.ini directives" Note under open_basedir to tighten open_basedir scope from /www/ which would contain .php scripts to /www/tmp/ which would protect any scripts in /www/ from modification.) If the php.ini is outside the open_basedir tree, than a malware php script has no way to alter the core web site files, even if it were succesfully uploaded via ftp or other mechanism. The damage done by the spam-ware may seem trivial, but as browsers and virus programs eventually recognize the spam-ware the web site becomes effectively completely blocked and un-browsable.

 
show source | credits | stats | sitemap | contact | advertising | mirror sites