4

ASP.NETアプリケーションのコンテキスト内で作業する私は、環境内の多くのデータベースの1つに対してデータベーススクリプトを実行できるページを作成しています。これを行うには、ユーザー名とパスワードの組み合わせをユーザーに求める必要があります。この値は、すべてのサーバーで問題なく使用できます。

問題は、この情報を保存するための最も安全な場所はどこですか？この特定のページにいるときは、複数のポストバックで何百ものスクリプトを実行している可能性があるため、一時的に保存する必要があります。私が言えることから、私には3つの選択肢があり、何が最善かわかりません。以下はオプションに関する私の見解ですが、ここにいるすべての人の推奨事項は何ですか？ユーザーにとってフレンドリーでありながら、最も安全なものは何ですか？

ビューステートに情報を保存する

私たちが最初に話し合ったアイデアの1つは、ユーザーがページのViewStateに入力した後に情報を保存することでした。情報はページの存続期間中のみ存在するため、これは役立ちますが、セキュリティへの影響は不明です。

セッションに情報を保存する

次のアイデアはセッションに保存することでしたが、これの欠点は、情報をアプリケーション内の他のページで利用できるようにすることができ、情報が常にサーバーのメモリに残ることです。

アプリケーションに情報を保存する

私たちが持っていた最後のアイデアは、ユーザー固有のキーとスライド式の5分の有効期限を使用して、アプリケーションキャッシュに保存することでした。これは他のページでも引き続き利用できますが、情報がより短い期間キャッシュされるようになります。

なんで？

重要な最後の質問は「なぜあなたはこれをしているのですか？」です。なぜ彼らのLANIDを使用しないのですか？委任に対するネットワークサポートがないため、LANIDを使用できません。

S0推奨される解決策は何ですか？なんで？それはどれほど安全ですか、そして私たちは安全であることができますか？

アップデート

素晴らしい情報が議論されました。明確にするために、私たちはイントラネット環境で実行しています。ネットワークの制限により、なりすましや委任を使用することはできません。

4

7 に答える 7

3

私の意見では、これの自然な場所はセッションです。

「アプリケーション内の他のページ」を恐れているように見える理由はわかりませんが (アプリケーションを制御しますよね?)、本当にそうである場合は、保存する前に何らかの暗号化を使用できます。

しかし、それを行う場合、データは ViewState にも存在する可能性があります。

于 2009-01-16T17:07:42.440 に答える
3

私はこれらのアイデアのどれも好きではありませんが、 viewstate のアイデアは完全に嫌いです。

あなたが接続しているデータベースの数はわかりませんが、数が限られている場合は、認証と承認を標準の安全な方法で処理し、ID の偽装を使用して統合セキュリティを介してそれらのデータベースに接続するのはどうでしょうか。最小限の権限を持つアカウント。

于 2009-01-16T17:15:22.440 に答える
1

このViewStateアプローチは優れていますが、ユーザー名とパスワードをクライアントに提供しているという問題があります。暗号化しても、暗号鍵が攻撃者に知られていたら大変なことになります。

Sessionandアプローチに関しては、アプローチは意味Applicationがないと思います。Applicationデータはユーザー固有であるためSession、進むべき道です。ユーザーのセッションが閉じられるとすぐに消えます。ちなみに、サーバーに保存することを選択した場合は、SecureStringクラスを使用してください。

于 2009-01-16T17:04:42.663 に答える
1

John MacIntyre が書いたように、これには統合セキュリティと偽装を使用する必要があります。

何らかの理由で使用できず、独自のログイン ページを提供する場合は、ブラウザとサーバー間のトラフィックを暗号化するために、必ず SSL を使用してください。SSL を使用しない場合、ViewState アプローチを使用することも完全に安全ではありません。コンテンツを非常に簡単に表示するためのツールがあります。列挙したメソッドから、最善の方法はセッション状態を使用することです。セッション状態の保存を Web サーバーのメモリからオフロードし、そのデータを必要な方法で保護できるデータベースに保存できます。これらの動作が気に入らない場合は、独自のセッション状態プロバイダーを作成して、必要なセキュリティを適用することもできます。

于 2009-01-16T17:40:00.783 に答える
0

Viewstateに保存すると、パスワードがインターネット上を何度も飛び交うため、露出が増加します。暗号化がこのリスクに対処するのに十分であるかどうかはあなた次第です。

アプリケーションまたはセッションを使用すると、両方ともサーバーにパスワードが保持されます。上記のように、SecureStringは、人々が単にパスワードをメモリから読み取らないようにします。セッションはより多くのユーザーに拡張され、おそらくアプリケーションよりもはるかに簡単に複数のサーバーに拡張されます。複数のWebサーバーを使用しないことが確実でない限り、すべてのサーバーを同期するのはユーザーの責任であるため、アプリケーションは使用しません。

于 2009-01-16T17:19:57.763 に答える
0

パスワードを保存しないでください。

代わりに、パスワードのハッシュを保存します。http://en.wikipedia.org/wiki/Crypt_(Unix)#Library_Functionを参照してください。

これが質問の答えではないことは承知していますが、このアドバイスを無視するプログラマーが増えれば増えるほど、犯罪者がデータを盗みやすくなります。あなたの組織がニュース記事にならないようにしてください。

于 2009-01-16T20:29:45.713 に答える
0

ユーザー名/パスワードは、実際にはどこにも保存しないでください。

セッションオブジェクトのプールから、できればライブデータベース接続を保存します。データベースへのログインに必要なのは、ユーザー名とパスワードだけです。

別のページがライブ接続を使用できますが、ユーザー名/パスワードを保存する場合のように、他のユーザーがデータベースに永続的にアクセスできるわけではありません。

于 2010-12-27T06:54:09.303 に答える