メモリ内のオブジェクトの.NETセキュリティ

Question

ユーザー名とパスワードを使用してセキュリティで保護されたWebサービス[B]に要求するASP.NET Webアプリケーション[A]を考えてみましょう。

[B]の認証に使用されるパスワードは、[A]に保存され、web.configファイルの「ベストプラクティス」を使用して暗号化されます。

暗号化されていないパスワードが[A]のメモリに存在する必要があります。おそらく、Webアプリケーションは暗号化されていないパスワードを静的オブジェクト/文字列にキャッシュするように設計されています（web.configファイルからの解読/読み込みのみです）。その「静的にキャッシュされた」アプローチは、セキュリティ面で悪化しているのでしょうか？

攻撃者がサーバーのメモリにアクセスして潜在的にパスワードを明らかにするASP.NETに対する攻撃が公開されていますか（またはそのような可能性がありますか）。

[B]と[A]との通信義務を引き受け、[A]からアクセスできるがインターネットからアクセスできない第3のアプリケーションサーバー[C]に割り当てることはより安全なアーキテクチャでしょうか？私はちょうど編集的であるのですか？

Answer 1

.NETの文字列はガベージコレクションのスケジュールを設定できません。あなたはパスワードが不要になった後にガベージコレクションされるように強制されるSecureStringオブジェクトにパスワードを読み取ることができます。

http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx

Answer 2

攻撃者が任意のメモリをASP.NETプロセスに読み書きすることができる場合は、これを防ぐために何もできません。あなたができることは何でも、彼は離れてパッチを当てることができます。第3のサーバーCを行ったとしても、代わりに悪意のあるサービスにパスワードを送るために 'A'にパッチを当てることができます。

Answer 3

これはアプリケーションがユーザーのマシンに座っている場合、私はむしろそれを心配しています。 Webベースのサーバーでは、悪意のあるユーザーがあなたのメモリにアクセスすることを期待してはいけないと思います。その時点であなたが手遅れになっているかもしれません。

Answer 4

最初に、暗号化されたweb.configセクションは本当に安全ではありません。もし彼らがweb.configファイルを読んでいるのであれば、暗号化されていないコンテンツ全体を漏らさないようにすることができます。

はい、web.configの暗号化されていないセクションがメモリに存在します。あなたが定義するアプローチは、実際に提供されるセキュリティのレベルには影響しません。

はい、メモリダンプが発生しました。また、web.configなどの保護されていると思われるファイルの内容が漏洩した攻撃もあります。あなたはあなたのパッチに追いついています..そうですか？

さらに攻撃者があなたのサイトに1つのページをアップロードする機能を持っている場合、そのページには同じアクセス権（web.configの復号化を含む）とそのデータが公開されます。

"[A]から[B]と通信する義務を引き受け、[A]からアクセス可能であるがインターネットからアクセスできない第3のアプリケーションサーバー[C]に割り当てることがより安全なアーキテクチャでしょうか？ ？ "

ええと。 Aが割れた場合、AとBの間に置くレイヤの数は重要ではありません。

インターネットからBにアクセスできないようにする必要があります。さらに、ファイアウォールは、Bと話すことができるものがAだけであることを確認する必要があります.AとBの間の通信は、ワイヤで暗号化する必要があります。

また、Bは暗黙的にAを信頼すべきではありません。つまり、セキュリティ保護されたトランザクションが発生するたびに、Aは適切なユーザー資格情報をBに送信する必要があります。そして、Bは、それらの信任状が要求された行動を取ることを認可されていることを確認する責任を負うべきです。

Bをデータベースサーバー、Aを人がログインするWebサイトとしましょう。 AがクエリをBに送信するたびに、エンドユーザーの資格情報を含める必要があります。 Bは、これらの資格情報の認証と承認をチェックして、このユーザーが要求された操作を実行できることを確認する必要があります。もちろん、これはAがBへのクエリを実行するための直接アクセスを持っていないことを要求しますが、それはまったく別のトピックです。

---