FastCGI経由でPHPを偽装する必要がありますか？

私はFastCGIを介してIIS 7.5に最新バージョンのPHPをインストールしていますが、すべての指示はFastCGIが設定によって呼び出しクライアントになりすますべきだと言っています

 fastcgi.impersonate = 1

私のウェブサイトにこの設定がある場合

専用アプリケーションプール
ApplicationPoolIdentityのアプリケーションプールID
匿名認証のみ（IUSRとして）

偽装したいのはなぜですか？

私はASP.NETのバックグラウンドから来ました。IUSRは読み取り専用のアクセス許可を取得し、アプリケーションプールIDは書き込みのアクセス許可を取得します。IUSRへの書き込みアクセスを許可すると、通常、WebDAVの脆弱性の扉が開かれます。したがって、PHPをIUSRとして実行することをためらいます。

この質問（1 | 2）を求めている人はあまりいないので、何かが足りないと思います。誰かが私のためにこれを明確にすることはできますか？

— WimpyProgrammer
ソース

回答:

13か月後、私は自分の質問を再検討したかった。その間に、私はIIS 6からIIS 7.5に6個のWebサイトを転送し、好みの方法でそれらを構成しました。私が言えることは、ウェブサイトが機能し、セキュリティの問題がなく（これらは人気のあるサイトではない）、そして私の意見では、学習はlearn.iis.netが推奨するものよりも安全であるということです。

後世のために、関連する設定を以下に示します。PHP INIの場合：

cgi.force_redirect = 0
cgi.fix_pathinfo=1
fastcgi.impersonate = 0

IISの場合：

アプリケーションプール> ID> ApplicationPoolIdentity
Webサイト>認証>匿名認証>特定のユーザー：IUSR

NTFSアクセス許可とそれらを適用する場所：

IUSR-読み取り許可、書き込み拒否
- IIS Webサイトのルートディレクトリ。たとえば、Zend Frameworkプロジェクトでは、これは/ publicディレクトリになります。
- アプリケーションがファイルをアップロードしてパブリックディレクトリに保存する場合、この許可を一時アップロードディレクトリに適用する必要があります。これはmove_uploaded_file、アップロードディレクトリの権限が保持されるためです。これは、私が見つけたこの許可設定の最大の欠点です。
ApplicationPoolIdentity（IIS AppPool\<<YourApplicationPoolName>>）-読み取りとリストの付与
- PHPアプリケーションのルート。たとえば、Zend Frameworkプロジェクトでは、これがプロジェクト全体になります。
- アプリケーションフォルダーにない、アプリケーションに含まれる外部ライブラリ（Zend、Doctrineなど）。
ApplicationPoolIdentity-変更の付与
- あなたのアプリケーションのような書き込みをする任意の場所upload_tmp_dir、session.save_pathそして、error_log。
- Doctrineのプロキシの自動生成などをサポートするために、開発環境のPHPアプリケーションのルートにこの権限を追加する必要がある場合があります。
ApplicationPoolIdentity-許可リスト
- アプリケーションが仮想ディレクトリにある場合、この権限をWebサイトのルートに追加する必要があります。これにより、アプリケーションはその親web.configを読み取ることができます。たとえば、アプリケーションのルートがhttp://example.com/MyPHPAppである場合、example.com Webディレクトリでこの権限を設定します。具体的には、「このフォルダとファイル」、「このコンテナ内のみ」にのみ適用する必要があります。

これが、learn.iis.netの指示が理想的ではないと判断した人の助けになることを願っています。

— WimpyProgrammer
ソース

これに感謝します！自動化するバッチスクリプトを追加しました。私のインストールでは問題なく動作します。

— 種牡馬

impersanationを有効にして、認証>匿名アクセス>編集をアプリケーションプールIDに設定する必要があります。次に、IIS APPPOOL \ <アプリケーションプール名>を使用してファイルシステムのアクセス許可のみを設定します。

— モンスティーアール

@Kurianはい、そのアプローチはよりシンプルで、learn.iis.netの指示に従っています。他の利点はありますか？上記のシステムを選択したのは、アプリケーションの許可とWebユーザーの許可が分離されているためです。

— WimpyProgrammer

複数のアプリケーションが互いのデータにアクセスすることを防ぎます。1つのアプリケーションがハッキングされた場合、ApplicationPoolIdentityがなければ、そのサーバー上の他のアプリケーションをハッキングするために使用できます。次に、アクセス許可に関する限り、ASP.NETと同じようにFastCGIを処理できます。

— Monstieur

最初の部分に同意します。ApplicationPoolIdentityはサンドボックスアプリケーションに最適であるため、上記でも使用しています。2番目の点まで、ASP.NETサイトの管理方法は異なります。ASP.NETサイトをセットアップするとき、匿名ユーザーにIUSRを使用し、アプリケーションプールにApplicationPoolIdentityを使用します。アクセス許可は上記で説明したものと非常によく似ています。

— WimpyProgrammer

参照：http : //www.php.net/manual/en/install.windows.iis6.php

偽装とファイルシステムアクセス

IISを使用する場合は、PHPでFastCGI偽装を有効にすることをお勧めします。これは、php.iniファイルのfastcgi.impersonateディレクティブによって制御されます。偽装が有効になっている場合、IIS認証によって決定されたユーザーアカウントに代わって、PHPがすべてのファイルシステム操作を実行します。

ドキュメントごとに、fastcgiがすべて同じアクセス許可を使用してクライアントに代わって動作することを許可します（この場合、IUSRアカウントのように見えます）。つまり、クライアント（またはアノン）自身の資格情報に対して通常許可されているすべてのアクションを実行することです。これ以上でもそれ以下でもありません。このセットがないと、貧弱なfastcgiが機能しなくなる可能性があります。

— ボブ・ザ・デストロイヤー
ソース

それは彼の状況の場合であり、ゲストアカウントまたは何かに基づいてアクセスすることになります。

— マット

答えてくれてありがとうマットとボブ！私は誰も刺さないだろうと考え始めていました。

— WimpyProgrammer

偽装なしでPHPを実行すると、アプリケーションプールIDとして実行されます。これにより、匿名ユーザーに読み取り専用権限を付与し、アプリIDに書き込みアクセス権を付与できます。したがって、偽装がなければPHPは無力ではありません。明確にするかもしれないテストを作成しました。IUSR（アノン）：読み取りを許可し、書き込みを拒否します。アプリID：読み取り/書き込みを許可。偽装をオフにしても、コードを介してファイルを書き込むことができます。なりすましを有効にすると、できません。しかし、IUSRに書き込みアクセス権を与えたくありません。私は他のフォーラムでいくつか質問をし、詳細がわかったらここに戻ると思います。

— WimpyProgrammer