PHP Webサーバーの保護

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

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

• 強化されたPHP / Suhosinの使用
• mod_securityを使用する
• php.iniでregister_globalsとallow_url_fopenを無効にする

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

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

2. 強化されたphpを使用する

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

4. Mod_securityは大きな利点ですが、十分に使用して構成する必要があります。

私の経験では、PHPベースのWebサイトのほとんどの脆弱性は、PHP自体の欠陥ではなく、貧弱な（サイト）デザインの結果です。

簡単なヒント：

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

*また、「Securing phpinfo（）、sort of」と呼ばれる短い投稿を覗いて、コメントを必ず読んでくださいhttp://egovsergo.com/2009/04/03/protecting-your-phpinfo/本番サイトでphpinfo（）を削除するのをどうにかして忘れた場合、それを（ある程度）保護する必要がありました。

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

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

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

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

Debianよりもはるかに頻繁にphp / apache / mysqlにパッチを適用します。

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

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

ファイル権限を可能な限り厳しく実行し、ApacheユーザーのPHPスクリプトへの書き込みアクセスを回避します。これにより、実行中のスクリプトが同じサイト/サーバー上の自身または他のスクリプトを変更することを防ぎます。可能な場合は777のアクセス許可を避け、アプリケーションの実行に必要な最小限のアクセス許可を見つけて使用します。

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

Suosin、HardenedPHP、mod_securityなども同様にすべて価値がありますが、代わりに、しっかりとロックダウンされた構成に加えて使用します。

Suhosinのパフォーマンスコストはかなり大きいため、「無料」というコメントは少しずれています。

基本的なファイアウォール/トポロジの提案をお探しですか？ポンドのようなものを使用して、ウォッシュされていないインターネットからPHP Webサーバーへの直接アクセスを防止するというアイデアが好きです。そうすれば、ネットワークの他の部分からウェブサーバーを分離することもできます。

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