一般的なPHPセットアップの不安？

10

私は大学のシステム管理者と仕事をしていて、たぶんよくあることを偶然見つけましたが、私にはかなりショックでした。

すべてのpublic_htmlディレクトリーとWeb領域は、Webサーバーの読み取り許可とともにafsに保管されます。ユーザーは、public_htmlにphpスクリプトを含めることが許可されているため、php内（およびメインのWebファイル！）から他のユーザーのファイルにアクセスできます。

これにより、.htaccessパスワード保護が完全に役に立たなくなるだけでなく、ユーザーがmysqlデータベースのパスワードと同様の機密情報を含むphpソースファイルを読み取ることができるようになります。または、他のユーザーがWebサーバーに書き込みアクセス権を持っているディレクトリを見つけた場合（たとえば、個人ログまたは送信されたフォームデータを保存するため）、それらのアカウントにファイルを保存できます。

簡単な例：

<?
  header("Content-type: text/plain");
  print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); 
?>

これは一般的な問題ですか？そして、通常はどのようにそれを解決しますか？

更新：

入力いただきありがとうございます。残念ながら、簡単な答えはないようです。このような大規模な共有環境では、ユーザーはおそらくこれほど多くの選択肢を与えられるべきではありません。私が考えることができる最良のアプローチは、すべての「public_html」ディレクトリのメイン構成で「open_basedir」を設定し、suphpを実行して、クリーンなphpのみを許可することです（cgiスクリプトなし、バッククォート付きの外部コマンドの実行など）。

ただし、このようにポリシーを変更すると、多くの問題が発生し、ユーザーがピッチフォークをつかんで追いかけるようになる可能性があります。設定を変更する方法について決定した場合は、同僚と話し合い、ここで更新します。

apache-2.2 security php

— ポンタス
ソース

これは興味深い質問です。主要な共有ホスティングプロバイダー（DreamHostなど）では、これは不可能です。しかし、私は彼らがこれからどのように保護するかに興味があります。cstamasが述べたように、suphpは良い解決策のように見えますが、これはほとんどのホスティングプロバイダーが使用するものですか？

— Lèseはmajesté

1

open_basedir以下のソリューションを運用共有ホスティングシステムで使用しましたが、全員を独自の仮想ホストに分割しました-単一のディレクトリで機能するかどうかは不明です

— voretaq7

8

所有者のuidでphpスクリプトを実行するsuphpを使用できます。

http://www.suphp.org

— cstamas
ソース

これはおそらく上記の問題を解決しないでしょう（少なくとも共有ホスティング環境では、.htpasswdファイルは通常、サイトを所有するユーザーとグループ（apache）または世界（ユーザーがセキュリティを知らない/気にしないため）が読み取り可能であり、そのため、suphpを使用しても、これらのファイルを読み取ることができます）

— voretaq7

@ voretaq7：他のいくつかの制限を適用できます。私が覚えている限り、自分が所有していないファイルへのアクセスを拒否することもできます。したがって、これは上記の攻撃を除外します。

— cstamas 2010年

ファイルのアクセス許可を制限できることは知っていますが（ "グループ/その他/誰でも書き込めません"）、FSアクセス許可を超えて読み取りをブロックする方法がわかりません。彼らは持っcheck_vhost_docrootていますが、実行中のスクリプトにのみ適用されるAFAIK（？私はそれについて間違っている可能性があります）

— voretaq7

1

このような環境でsuphpが優れたソリューションであるかどうかはわかりません。ユーザーは、www-userにはないあらゆる種類の権限を持っている可能性があります。攻撃者がphpを介して侵入した場合、sshキーまたはキータブを見つけたり、ユーザーのログインスクリプトを変更してバックドアを作成したりする可能性があります。また、public_htmlディレクトリはメインの仮想ホストの「/〜username」から利用できるため、「vhosts」設定はそれほど役に立ちません。たぶんpublic_htmlのスクリプトは完全に無効にすべきだと思います。

— Pontus

4

私の提案は、ファイルへのPHPのアクセスを制限することです（open_basedirvhostごとに＆類似のディレクティブを介して）：ユーザーがWebrootの下でファイルを開いたり、読んだり、書き込んだりできるようにする必要があります。スペース）、ただしhtpasswdファイルなどを格納するディレクトリではありません。

次のようなディレクトリ構造：

/Client
    /auth
    /site
        /www_root
        /www_tmp

この要件を満たしています：open_basedirで指摘することができ/Client/site、安全に、そしてhtpasswdファイルがに保存されている/Client/auth（して.htaccessファイルまたはhttpd.conf代わりに、適切な場所を指すように変更されました）。
これにより、クライアントが他のユーザーのファイルを開くことを防ぎ、悪意のあるユーザーが他のファイル/Client/auth（またはシステムの他の何か、/etc/passwdたとえば:-)を読み取ることができないという利点があります。

参照http://php.net/manual/en/ini.core.phpを open_basedirの＆あたりのバーチャルホストの実装の詳細については。

— voretaq7
ソース

1

suphpcstamasによって指摘されているように、共有ホスティング環境では本当に良いアイデアです-設定するのに少しオーバーヘッドがありますが、セキュリティの向上はそれだけの価値があります。すべてのPHPサイトをFreeBSDの刑務所や専用の仮想マシンにサンドボックス化するのではなく、セキュリティ上の最大のメリットの1つです。

— voretaq7

「open_basedir」は、「public_html」が独自の仮想ホストを通じて提供されるという条件で、メインのWebファイルをユーザーのファイルから分離する簡単な方法のようです。ただし、ユーザーが独自の仮想ホストを持っていないため、ユーザーを互いに保護することはできません。正しい？

— Pontus

open_basedir<Directory>ディレクティブ内での設定は試していませんが、許容できると思います（「試してみてください」-実行できない場合は機能しません:)

— voretaq7

1

これまでのところ、open_basedirはほとんどの商用Webホストが使用しているように見えます（通常、サブスクライバーは独自の有料ドメインを持っているか、無料のサブドメインを受け取ります）が、学術機関などのディレクトリベースのホームページでは、suphpが最良の答えのようです。

— Lèseはmajesté

1

ほとんどの共有ホストは、各ユーザーのpublic_htmlディレクトリ（または各ユーザーが独自のvhostを持っている場合はvhost）のhtaccessファイルにopen_basedir構成を定義するため、これは一般的な問題ではありません。

例：.htaccessファイル：

# Assuming these are not set globally - its good practice to limit:
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag short_open_tag off
  php_value max_execution_time 60

# These set the user-specific paths
  php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
  php_value session.save_path /afs/example.com/home/smith/tmp
  php_value upload_tmp_dir /afs/example.com/home/smith/tmp

ただし、.htaccessファイルに適切な権限を設定して、ユーザーがopen_basedirを変更できないようにしてください（subdir / .htaccessで上書きを試みても機能しないはずですが、テストして確認してください）。。

HTH

C.

— symcbean
ソース

2

これは、新しいアカウントの初期保護を提供するのに役立ちます。ただし、ユーザーが編集できないという事実により、.htaccessファイル（public_htmlディレクトリへの書き込みアクセスのみが必要なため、ファイルを削除できます）を削除して独自のファイルを作成したくなる場合があります。各ユーザーのメイン構成に「<Directory>」ブロックを追加すると機能しますが、ここでは引き続きphpから外部コマンドをバックティックすることができます。つまり、open_basedirは簡単に回避できます。

— Pontus、

@Pontus：ファイルの削除についての良い点（afsが不変のファイル属性をサポートしているかどうかはわかりません）。chrootの刑務所でWebサーバーを実行すると、あらゆる種類のプログラム実行の脆弱性から保護できると言っていたら、+ 1しました。

— symcbean 2010年

1

AFSは単純なUNIXユーザー許可を無視します。suPHPは、phpプログラムを実行する前にsetuidを実行しますが、AFSへのアクセスに必要なkerberosトークンをプロセスに与えず、その権限に制限することはできません。suPHPは、そのユーザーとしてAFSシステムに提示する前に、これらのトークンを取得するために何らかの方法で変更する必要があります。私の知る限り、それは行われていません。（実際、私は他の誰かがそうしていないかどうかを確認しようとしたときにこの質問を見つけました。）

— チャールズB
ソース