ユーザーセッションを維持する-セキュリティに関する考慮事項

Question

私たちは最近、ユーザーが無期限にログインを維持できるようにするために、Webアプリのいくつかの機能を開発しました。これにより、セキュリティ上の影響を知りたいと考えています。これの目的は、ページの編集に非常に長い時間がかかる場合のユーザーデータの損失を防ぐことでした。以前は、POSTがブロックされ、ログオンが別の画面で処理されるため、セッションが期限切れになると、クリップボードにコピー/貼り付けする必要がありました。。

そこで、ユーザーセッションがまもなく期限切れになるかどうかを検出し、ボタンをクリックしてセッションを維持できるモーダルを提示します。彼らがこの警告モーダルを十分に長い間無視した場合、セッションが実際に期限切れになるとすぐに、「ログイン」モーダルに置き換えます。

最初のモーダル/警告メカニズムは、AJAX= getcall呼び出しを介してサーバーから取得し、ログアウトまでの時間を返します。時間が15分未満の場合、「ログイン状態を維持する」モーダルを開きます。 2つのオプション-今すぐログアウトするか、ログインしたままにします。ログアウトすると明らかです。ログインしたままにすると、別のAJAXサーバーに再度アクセスして、ユーザーの認証Cookieが更新されます。

2番目のモーダルはより複雑です。モーダルはページとのさらなる相互作用をブロックし、正しいパスワードの再入力時にのみ削除されます。モーダルはページからのデータの読み取りを実際には保護しないことを認識していますが、これは要件の性質です。

ユーザーが再ログオンするために必要なデータ（ユーザー名や以前のロールなど）は、モーダル内の非表示の入力フィールドにプレーンテキストで格納されます。これをハッシュ化することを検討しましたが、実際には必要とは思われませんでした。ユーザー名は特に重要ではなく、要求されたロールは再ログオン時に再評価されます。 POSTを「調整」しようとした場合、アクセス権のないロールに自分自身をアップグレードすることはできません。

私たちが検討した最悪のシナリオは、誰かがPOSTを別の有効なユーザー名/パスワードで編集し、ページに留まっている間に他のユーザーとしてログインすることです。彼らはページを読むことができます。とにかく彼らはそれを行うことができます-離れてナビゲートすると、「新しい」ログインの正しい画面に戻ります。このシナリオですべてのPOSTが確実にブロックされるようにするためにいくつかの作業が必要ですが、他に考慮すべきことはありますか？ユーザー名をもう一度手動で入力して、ユーザーに再識別を強制することで得られますか？

WebアプリはASP.NET MVC3です。

[〜＃〜]更新[〜＃〜]

これまでのフィードバックに感謝します。

オンボードでクライアントからのデータを信頼しないようにしたので、ユーザー名とロールを一緒に暗号化し、ログイン試行時にこれを復号化することにしました。それ以来、別のユーザーがログインした場合にすでに実施されているAntiForgeryToken保護機能により、どのポストアクションも検証に失敗することを発見しました。

タイムアウトは現在15分警告で60分に設定されているため、ポップアップに大きな使いやすさの問題があるとは思われません。途中まで更新されないスライディング有効期限を考慮に入れました（http://msdn.Microsoft.com/en-us/library/system.web.configuration.formsauthenticationconfiguration.slidingexpiration.aspx）。これはすべて、データの損失に関するユーザーの苦情に対処するために実装されたことを覚えておくことが重要です。システムに大量のテキストを入力すると、時間がかかり、セッションが完了する前にセッションが古くなる可能性が高くなります。

後で追加されるもう1つの機能は、ユーザーが入力フィールドを変更し、サーバーにハートビートを送信することです（まだ認証されていない場合を除く）。このイベントの処理方法やハートビートをトリガーしてすべてのキープレスを起動しないようにする方法はまだ決定していません。これが実行されると、タイムアウト警告ダイアログボックスが表示される頻度が減ります。

言及する価値があるかもしれない他の何かは、サイト全体がHTTPSであり、安全であるとフラグが立てられたHttpOnly CookieであるASP.Net AntiForgeryTokenを使用していることです。

誰か他のフィードバックや提案がある場合は、あなたから聞いていただければ幸いです。

D.W. · Answer

このアプローチでは、2つの「悪臭」がします。

まず、クライアントを信頼してはいけません。ユーザー名をクライアント側に保存し、クライアントがそれを正直に送り返すことを信頼しても、私は賢明ではありません。これにより、誰かが別のユーザー名で単一のページにアクセスできる可能性があることをすでに発見しました。それはすでに少し怪しげに聞こえますが、どうすればより悪い攻撃がないことを知ることができますか？少しでもクライアントを信頼するようなスキームは勧めません。
第二に、これの使いやすさには問題があるようです。フローを中断するダイアログボックスをポップアップするのは、本当に面倒です。セッションを切断するかしないか。個人的には、ほとんどのWebサイトでは、タブを開いたままにしておけば、セッションを長時間開いたままにしておくことには大きな危険はないと思います。ユーザーに再ログインを強制しないことの有用性の利点は価値があると思いますセキュリティ上のリスクですが、それはあなたが決めることです。私の唯一の提案は、フローを中断するポップアップダイアログボックスを回避することです。もちろん、私はユーザビリティの専門家ではありません。より専門的な意見が必要な場合は、 ser Experience.SE で質問できます。

更新（11/14）：理由のためにダイアログボックスを追加したとのことですが、それでもユーザビリティからの最善の解決策ではないと思います視点。データ入力の最中にいたユーザーがデータを失っていたことが解決策である場合、他の解決策のほうが使い勝手がよいようです。例：JavaScriptを使用して、Webアプリケーションに30秒ごとに入力したテキストを自動保存させることができます。これにより、セッションがタイムアウトした場合、ログインし直してテキストを再表示できます。または、セッションの長さを延長することもできます。または、任意のタブ（入力など）でユーザーアクティビティを検出し、ユーザーが60分間操作しないとセッションを終了できます。ユーザーエクスペリエンスの担当者に質問すると、他の提案にもつながる可能性があります。これはこのサイトのトピックから外れているので、そのままにしておきます。

私はすぐにあなたの計画を破ってリボンに細断する攻撃はしません。しかし、これらの「悪臭」は私にいくらかの懸念を残し、Webアプリケーションでの防御設計のための優れた実践に従っていないと私に思わせます。

Md Mahbubur Rahman · Answer

ユーザーセッションを安全に維持します。ロードに関する限り、それはハードウェアとその記述方法次第ですが、ユーザーがページを更新するよりも悪影響はありません（おそらく、標準ページでのAJAX呼び出しのオーバーヘッドを考慮した方が少ない）負荷）。
それがあなたが求めているものであれば、あなたはweb.configでタイムアウトを調整することができます...
クッキーには目的があり、それがあなたのドメインである限り受け入れられると私は思っていますが、一部の人々はクッキーを無効にしているので、フォールバックが発生します。
.NET AJAX with UpdatePanelを使用すると、サーバー側のポストバックがあります。唯一の違いは、ページ全体が読み込まれないことです。すべてのサーバー側のコードは通常どおりトリガーされますが、情報はAJAXテクノロジーを使用した別の方法でのサーバーとページ。
.NETがPageMethodsを呼び出すメカニズムを使用して、クライアント側のJavaScriptからサーバー側のメソッドを呼び出すこともできます。これは、.NETで従来のUpdatePanel手法よりも「手動」でAJAX=を使用する方法です。
銀行は同じ方法論を使用して、財務をチェックしている間もセッションを続行しますが、通常は続行するかどうかを尋ねる直前にポップアップを表示します。
ユーザーを通常よりも長い時間強制的にログインさせ続けると、セキュリティ上のリスクになる可能性があります（図書館や学校のコンピュータに誰かがログインして机から離れるのを想像してください-そのセッションが翌日に続く場合）

次のリソースが役立つ場合があります