一度に1つのタブからのみWebサイトを利用できるようにすることで得られるセキュリティ上の利点はありますか？
ポーランドのある銀行のウェブサイトでは、ユーザーがブラウザの1つのタブでしか開かないことがわかりました。たとえば、送金先の口座番号を探しているときに送金履歴を確認することはできません。考えられるセキュリティ上の理由を除いて、これを行うための適切な理由は考えられません。サイトを1つのサイトに制限することにはセキュリティ上の利点がありますか？もしそうなら、彼らは何ですか？
一般に、いいえ、ユーザーに単一のタブを強制することは合理的ではありません。 Webサイトを1つのタブのみで利用できるようにする技術的なセキュリティ上の理由はありません。これは一般に、システム設計が不十分なためによくあることです。
1つのタブを強制すると、ログアウトしたときに、機密情報が他の20個のタブに貼り付けられたままになることはありません。ただし、これが問題となるサイトではlocalStorageまたはwebsocketを使用して、1つのタブからログアウトするときにすべてのタブを同時にクリアできるため、これは不十分な理由です。
セキュリティの人的要因は、一部のサイトが故意に1つのタブに制限されるという限界的な理由です。 1つのタブを強制することで、ユーザーは一度に1つのことに集中するように強制され、これにより何かを忘れる可能性が低くなります。 IMO、欠点は利点を上回っているため、これは不十分な理由です。
この制限はセキュリティ対策によって引き起こされるのではなく、単に経済的な対策によって引き起こされます。
観察するこの動作は、実際には社内の多くのWebアプリケーションで見られ、Java J2EE Web Application Server（IBM WebSphere Application Serverが最も広く普及している）に多くリンクされています） 。
このようなアプリケーションは、軽量のクライアント（汎用のWebブラウザ）に依存していますが、重いクライアント（マシンにインストールされている実行可能ファイルから実行されるソフトウェア）を使用するアプリケーションとほとんど同じ方法で（不十分に）設計されています。
Webサイトは通常、要求-応答モデルを念頭に置いて設計されています。設計者は、ユーザーに許可する要求と、適切なサーバーの処理と応答を決定します。これにより、ブラウザがサーバーにリクエストを送信するたびに、好きなだけタブを開くことができます。
しかし、現在直面しているWebアプリケーションは、状態遷移モデルを念頭に置いて設計されています。
重いクライアントソフトウェアでは、非常に正確なワークフローに制限されます。アイテムをクリックすると、いくつかのオプションが提案され、それらの1つを選択するか、またはキャンセルをクリックするように強制されます。 =ボタンが利用可能な場合、最初に他のウィンドウまたはメニューを通過せずに一部のウィンドウを直接開くことができない場合や、現在進行中のアクションによっては、一部のオプションが常にアクセスまたは有効にできない場合があります。
いつでも特定の状態にあり、アプリケーションコントロールでのアクションに応じて、現在の状態から別の状態に切り替わります。可能な各状態遷移は、アプリケーション設計者によって適切に定義されています。
このようなWebアプリケーションは、重いクライアントアプリケーション用に最初に設計されたこの開発モデルを採用して、Webアプリケーションに適用します。複数のタブを開くと、現在の状態を判断できないアプリケーションを混乱させるため、これは明らかにうまくスケーリングしません。口座残高を調べているか、新しい銀行振込を入力していますか？どちらも許可されていません。一度に1つの状態のみにすることができます。また、このようなWebアプリケーションでサポートされていないことが多い、[戻る]ボタンや特定のページのブックマークなど、ブラウザーの特定の機能についても触れていません。
これはセキュリティの選択ではなく、アプリケーションのプログラミングをより簡単に、より速く、そしてより安価にするので、経済的な選択です。
これを何らかの方法で実装した8つの銀行と協力してきたことで、これは重要なセキュリティ機能であると確信しています。タブであることは無関係ですが、1つのインスタンスに制限することは、多くの攻撃経路を減らすのに非常に役立ちます。
複数のインスタンスを許可すると、攻撃者は有効なセッション中に別のマシンから攻撃する可能性があります。 1つだけを許可すると、これのほとんどのバリアントが削除されます。
それらの銀行が実装した一般的な方法は、トークン/ Cookieをチェックし、新しいセッションが交渉されるとすぐに存在するセッションをすべて閉じることでした。
これを行うスウェーデンの銀行があります。リクエストごとに1つの使用トークンを渡すため、リクエストを2回行うことはできません。これは、誰かがセッションCookieを盗んだ場合、だれかに気付かれずにそれを使用できないことを意味します。
これは、ユーザーエクスペリエンスにかなり大きな影響を与えるセキュリティの小さな追加です（最近はSSL/TLSが改善されたため、追加されていないこともあります）。
Klarnaなどの他の銀行では、シングルクリック決済ソリューションを使用してユーザーエクスペリエンスを大幅に向上させていますが、セキュリティを確保するのははるかに困難です。
最終的に、銀行はこのトレードオフを行う責任があります。ユーザーを1つのタブに制限することで、ユーザーがタブを閉じるのを忘れた場合に機密データが漏洩するリスクを下げるなど、ある程度役立つ場合がありますallタブ。
ステートフルアプリの場合、別のタブを開くとユーザーが混乱します。1つのタブに表示されるデータには、別のタブで実行されたアクションが含まれないためです。
これはセキュリティの問題ではありませんが、追加の作業なしでより複雑な操作をステートレスにすることができるため、Webアプリケーションで一般的な設計上の選択です。
はい、ただし、アプリケーションが別のタブで動作しないようにします。
"ビジネスロジックの欠陥" と呼ばれるWebアプリケーションの脆弱性のクラスがあります。これらは、従うべき複数ステップのプロセスがある場合に特に一般的です。ページごとに渡され、各ステップで変更されるトークンをユーザーに提供することにより、ユーザーが設定された順序でマルチステッププロセスに従うことを保証します。これにより、特定のページに到達したために前のすべての手順が正当に実行されたと開発者が想定するリスクが軽減されます。
トークンはページ間でGETまたはPOSTパラメータで渡されるため、別のタブで別のページを開くと、トークンが変更され、元のタブのトークンは無効になりますナビゲーション用。
セッションのサーバー側で検証できるトークンを渡すこの方法は、本質的にCSRFからも保護します。この方法を使用してサイト全体を保護すると、要求ごとにトークンの検証がスキップされることがないため、見落とされないことが保証されます。これは、ユーザーがダブルクリックするのを防ぐこともできます。トークンは最初のリクエストに対してのみ有効であり、そのようなアクションが誤って2回送信されないようにするため、送金ボタン。