web-dev-qa-db-ja.com

PHP Webサーバーの保護

PHPアプリケーションには、平均よりも高いセキュリティ問題があるという評判があります。アプリケーションを可能な限り安全にするために、どのような構成手法を使用していますか？

私は次のようなアイデアを探しています：

私は通常Linuxを使用していますが、Windowsソリューションもお気軽に提案してください。

linuxapache-2.2securityphpweb-server
31
David Pashley

  1. Open_basedirディレクティブを使用して、PHPスクリプトをホームディレクトリと最終的には追加のアプリケーションディレクトリに制限します。これは、それ自体で非常に効率的です。

  2. 強化されたphpを使用してください。コストはかかりません。

  3. suPHP を使用して、PHPスクリプトをファイルの所有者（Webサイトごとに1人のユーザー）として実行し、777などの不正なアクセス許可を持つファイルの使用を回避します... suPHP can 1つのサイトの愚かな要件がすべてを破壊しないように、Webサイトごとにphp.iniを使用することもできます。

  4. Mod_securityは大きなプラスですが、適切に使用および構成する必要があります。

15
Antoine Benkemoun

私の経験では、PHPベースのWebサイトのほとんどの脆弱性は、PHP自体の欠陥ではなく、不十分な（サイト）設計の結果です。

いくつかの簡単なヒント：

  • Universallyフィルター入力、エスケープ出力。明確化：フィルターはエスケープを意味するのではなく、「このユーザー入力で何か怪しいものを見つけた場合、送信を失敗させ、ユーザーに再フォーマットするように伝える」ことを意味します。
  • Escapeshellcmd（）を使用するのではなく、単にシェルでユーザー入力の実行を許可しない。それは危険であり、おそらく実際には必要ありません。
  • 本番サイトでphpinfo（）などの関数を呼び出さないでください（または、行う場合は、以下を参照してください*）。
  • Webアプリケーションを設計するときは、常に「これは攻撃ベクトルの可能性があるか」を考慮してください。たとえば、SQLインジェクション。答えが「はい」の場合は、すぐにプラグインします。「わかりました。開発の後半で機能として追加します」とは言わないでください。セキュリティは決して機能ではありません。
  • 決して生のエラーをユーザーに出力しません。つまり、php.iniのdisplay_errors = Off、log_errors = Onを設定します。実行時エラーをトラップし、きれいなものを出力します。 Twitterのクジラを例にとると、ユーザーにデバッグレベルの情報は提供されず、「うわー、何かが壊れました。更新してください」とだけ表示されます。

*私が書いた「phpinfo（）の保護、一種の」という短い投稿を覗いて、コメントを必ず読んでください http://egovsergo.com/2009/04/03/protecting- your-phpinfo / どうしてもphpinfo（）をプロダクションサイトから削除するのを忘れた場合、phpinfo（）を（ある程度）保護しなければならなかったのは簡単なことでした。

より一般的な方法では、一部の開発者は、「本番サイト」フラグが設定されているかどうかをチェックし、本番環境で機密関数を無効にする機密関数のラッパーを作成します。

3
msanford

PHPを強化するために変更する必要があるその他のパラメーター：

safe_mode = Off
register_globals = Off
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
log_errors = On
error_log = /var/log/phperror.log
display_errors = Off
enable_dl = Off
disable_functions="popen,exec,system,passthru,proc_open,Shell_exec,show_source,phpinfo"

すべてのPHPエラーをファイルに保存/ var/log/phperror.log：

touch /var/log/phperror.log
chmod 666 /var/log/phperror.log
3
Deem3n

dotdebリポジトリを/etc/apt/sources.lstに追加しました

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Php/Apache/mysqlにパッチを適用するのは、Debianよりもはるかに頻繁です。

1
Brent

「サイトごと」にopen_basedirを設定することを検討してください。 open_basedirはphp.ini設定であり、スクリプトが定義されたホワイトリスト外のファイルにアクセスできないようにします。サーバーが複数のサイトをホストしている場合、1つのサイトが別のサイトからデータベース設定を読み取ることができなくなります。また、phpスクリプトがコアシステムファイルにアクセス/変更するのを防ぎます。オープンベースの設定は簡単です。各Apache仮想ホストに「php_admin_value open_basedir /my/list/of/folders:/as/a/colon/seperated/list」という行を追加するだけです。

PHPスクリプト（たとえば、アップロードされた画像フォルダ）を含めることのできないすべてのサイト/フォルダのPHPスクリプトエンジンをオフにすることも検討してください。簡単に言うと、phpを必要としないApacheVirtualHostsに「php_admin_valueengineoff」を追加します。ディレクトリでPHPを無効にするには、同じことをDirectoryタグに入れます。

ファイルのパーミッションを可能な限り厳しく実行し、ApacheユーザーのPHPスクリプトへの書き込みアクセスを避けます。これにより、実行中のスクリプトが同じサイト/サーバー上の他のスクリプトを変更するのを防ぎます。可能な限り、アプリケーションを実行し、それらを使用するために必要な最小限の権限を把握してください。

それぞれが独自のデータベースを持つ複数のサイトをホストしている場合は、それぞれに個別のMySQL/Postgresユーザーを使用し、関連するデータベースにのみアクセスできるように各ユーザーに権限を設定します。繰り返しますが、これにより、不正なスクリプトが別のアプリケーションのデータベースを改ざんするのを防ぐことができます。

Suosin、HardenedPHP、mod_securityなどもすべて価値がありますが、代わりにではなく、厳密にロックされた構成に加えてそれらを使用してください。

1
Jim OHalloran

Suhosin/mod_security/SuPHPを使用すると、確かにPHPサーバーが安全になります。exec、passthru、system、escapeshellcmdなどの特定の機能を無効にすることも大いに役立ちます。

0
jplourenco

Suhosinにはかなりのパフォーマンスコストがあるため、「コストがかからない」というコメントは少しずれています。

0
Tom

基本的なファイアウォール/トポロジーの提案をお探しですか？ poundのようなものを使用して、洗浄されていないインターネットからPHP Webサーバーに直接アクセスできないようにする）というアイデアが好きです。こうすることで、Webサーバーを他の部分から分離することもできます。ネットワークも同様です。

0
D.F.