私は最近会社に入社し、その会社の環境を分析したときに、SharePoint の web.config の信頼レベルが Full に設定されていることに気付きました。私はこれが絶対にひどい慣行であることを知っており、stackoverflow コミュニティがこの決定の欠陥を概説するのを手伝ってくれることを望んでいました.
ああ、この決定は、開発者が CAS ポリシーを作成せずに Bin フォルダーに dll を展開できるようにするために行われたようです。はぁ。
明確にしてさらに悪いことに、この Web アプリケーションにはサードパーティのコードもデプロイしています。
トッド、
Dino Espisito 著の『Programming Microsoft ASP.Net 3.5 』という本には、ASP.Net アプリケーションで完全な信頼を許可しない正当な理由が示されています。
他の理由の中でも特に、インターネットに公開されている Web アプリケーションは「想像できる限り、コンピューター セキュリティにとって最も敵対的な環境の 1 つ」であると Dino は述べています。と：
公開されている完全に信頼できるアプリケーションは、ハッカーが攻撃を開始するための潜在的なプラットフォームです。アプリケーションの信頼性が低いほど、そのアプリケーションはたまたま安全になります。
StackOverflow コミュニティが Full Trust の問題をよりよく概説していないことに驚いています。私は同じことを望んでいたので、答えを見つけるために本の山を掘り下げる必要はありませんでした。
彼らが CAS のポリシーを無視している場合、彼らの仕事を少し難しくする (または、少なくとも寛容さを失う) ため、彼らに再度ダイヤルしてもらうのは難しいかもしれません。Web アプリケーションの SQL 接続文字列で SA アカウントを使用するのは良くないと上司に納得させなければならなかったときのように、セキュリティ プラクティスを変更するのは常に困難ですが、我慢してください。
完全な信頼により、アプリケーションはエスカレートしてコンピューター上の任意のリソースを制御できます。これらを許可するには、アプリケーションにセキュリティ上の欠陥が必要であり、彼らはおそらく、巧妙なプログラミングによってエスカレーションを防いだと主張するでしょうが、何かが起こった場合は、むしろWeb アプリケーションはコンピュータ全体を制御できませんでしたか? というか、念のため？
編集：私はここで自分の言語に少し熱心でした. 完全な信頼では、アプリケーションは必要なものを制御できますが、アプリケーション プール プロセスがそれを実行するのに十分な権限を持っている場合に限ります。したがって、アプリケーションが必要とするものを除いて、サーバー上で権限のない制限付きユーザーとして実行している場合、「完全な信頼」に対するリスクは本質的にないと思います。実際には、アプリ プールの所有者は、アプリに持たせたくない多くの権限を持っている可能性が高く (場合によっては、それ以上の権限を持っている可能性があります)、アプリのセキュリティを制限し、追加の権限の必要性を個別に付与する方がはるかに安全です。アプリケーションに。訂正してくれてありがとう、バリー。
正直なところ、SharePointは制限が厳しすぎることがわかりました。
次のページを見て、信頼レベルに基づいて実行できることと実行できないことを確認して くださいhttp://msdn.microsoft.com/en-us/library/ms916855.aspx
すぐに遭遇した問題の1つは、CachingApplicationBlockを使用できないことでした。MVPパターンを使用しており、Winフォームアプリケーションを開く可能性があるため、ASP.NETキャッシュの代わりにこのアプリケーションブロックを使用していました。
もう1つの問題は反映されないことです。これにより、バージョン番号がアセンブリのメタデータから取得されるため、[バージョン情報]ページが失敗しました。
最善の解決策は、Sharepointをアプリケーションホストとして使用しないことだと思います。コーディングの量が非常に少なく、信頼レベルに影響を与えず、新しいアプリケーションをセットアップするよりも作業が少ない場合にのみ、Sharepointをアプリケーションホストとして使用します。信頼レベルの壁にぶつかり始めているある種のコーディングを行っている場合は、アプリケーションを適切なASP.NET環境に移動してください。しかし、それは私だけであり、私は偏見を持っています。たぶん、中程度の信頼レベルの妥協を目指すべきです。
私は開発マシンで完全な信頼を使用しています..新しいコードを構築するときに BIN に展開できます。CAS ポリシーを作成するのは面倒なので、私は自分のコードを信頼して本番環境の GAC で実行しています。
サードパーティのことは私を心配させるでしょう..しかし：
Web で見られるほとんどのサードパーティ ソリューションは、GAC にもデプロイされます (同じ理由によると仮定します)。これにより、信頼レベルに関係なく、すべての権利が付与されます。サードパーティを信頼するかどうかに関係があるように感じます..そして、自分の開発者を本当に信頼していますか?
ハッカーは何をしますか？ハッカーがあなたの BIN フォルダに悪意のある dll をドロップするシナリオは、あまり現実的ではないと思います.. ハッカーがそれを実行できるかどうかに関係なく、おそらく信頼レベルを変更することもできます.
欠陥？たくさんの。しかし、最も厄介なのは CAS ユーティリティから直接出てきたものです。
「...ファイル システムやネットワーク アクセスなどのコンピュータのリソースへのフル アクセスを許可し、セキュリティ システムの制御外で動作する可能性があります。」
つまり、完全な信頼が付与されたコードは、システム上の他のコード (管理されているかどうかに関係なく) を実行でき、ネットワークを介して任意のマシンを呼び出すことができ、ファイル システムで何でも実行できます (制限されたファイル (OS ファイルも含む) のアクセス許可の変更を含む) ）。
ほとんどの Web プログラマーは、「それは問題ではありません。それは私のコードにすぎません」と言うでしょうが、それは問題ありません....コードにセキュリティ上の欠陥が発生し、攻撃者がそれを使用して不快なことを行うことができるようになるまで. その場合、以前に付与された完全な信頼は非常に不幸になります。