Webアプリケーションでのcookieのハイジャックを回避するための提案
私はかなり長い間Webアプリを開発してきました。ウェブサイトを作成している間、「remember me」機能は、実装する必要のある最も簡単な（クライアントに必須）機能の1つです。今日まで、私はASP.NET認証システムによって提供されるデフォルトの実装を使用していました。つまり、提供されたデフォルトの実装をいじらない限り、かなり安全です。しかし、今日、私はこの機能の実装の詳細について知りたくなりました。私はいくつかの調査を行い、いくつかの関連記事を読みました：
トロイの記事は基本的に、可能であればこの機能をまったく実装しないほうがよいという結論に至ります。最善の努力にもかかわらず、常にセキュリティ関連の妥協に至る必要があります。 。同様に、ミラー、チャールズのデザインに基づいたバリーの記事には、攻撃対象領域を最小限に抑え、攻撃ベクトルを複雑にする非常に優れた戦略的ステップがいくつかあります。
ですから、要点を述べると、これらの記事を読んだ後、私の心に浮かんだのは、why are the cookies not signed by the browsers ? Wouldn't it be best if each browser-client (mobile/desktop/whatever), had their own unique GUID kind of thing, which was not to be modified(under any circumstances), and then they can send their GUID to the servers, and the server could then use as the key-value to decrypt/verify any client-side information(cookies/querystrings) ?Wouldn't this solve the issue of session-hijacking/cookie-hijacking completely, as a cookie from one browser would then be totally useless for another browser ?
これが素朴に聞こえる場合は申し訳ありませんが、これに関する提案とフィードバックを本当にいただければ幸いです。ありがとう。
GUID送信をセキュリティで保護する必要があります（サーバーが別のサーバーになりすます可能性がある、または中間者の可能性を考慮してください）;これは急速に何かに進化すると思われます非対称暗号化が必要で、最後にHTTPSの簡略版が必要です。完全なHTTPSがすでに利用可能であるため、作業の重複と思われます。
一方、GUID（すべてが言われたときに、[一時的な]共有キーとして機能する）を使用しても、クライアントが危険にさらされている（マルウェア、「ブラック」）からは保護されません。フォレンジック、場合によってはインターフェースの設計に応じてソーシャルエンジニアリングも可能です。このためには、ローカルの信頼できるエスクローシステムが必要です。これは、安全なスマートカードの一種であり、readを実行して実際に複製することはできません。内部では、データがthereであることを第三者（サーバー）に証明できます。
しかし、その時点で、本当にcookiesが必要でしょうか？ユーザーのログインデータが安全に保持されたスマートカードがあります。セッションをブラウザではなくsernameにリンクする方がはるかに簡単です。 「remember me」機能は、スマートカードを接続することによって実行されます。
別のより簡単な可能性は、ユーザーlestoが示唆するように、フォームパスワードと同じように、パスワードで保護された領域（「キーリング」、「ポートフォリオ」、または「ウォレット」）に個人的に同意した秘密を保存することです。ユーザーはマスターパスワードでキーリングのロックを解除すると、ブラウザーが認証できるようになります。
ただし、スキーム全体をより直接的な方法で実装できます安全なCookieをキャッシュされたパスワードと一緒に安全な領域に保存することを強制する。安全な接続を介してCookieを受信すると、ブラウザはユーザーに安全な領域のロックを解除するように要求し、同じドメインに同じ名前のCookieが既に存在することを確認してから、要求を繰り返しますが、今回は予想されるCookieを送信します。ユーザーの観点から見ると、彼は "Remember me"オプションを有効にして安全なサイトにアクセスし、マスターパスワードを要求するブラウザーポップアップが表示され、次にログインしていることがわかります。
攻撃者はHTTPS交換にアクセスする方法（weeeellll ...）がなく、コンピューターを押収した場合、マスターアクセスキーのないAES-256暗号化ブロックでCookieとパスワードを見つけます。
あなたが提案しているものは、プライバシーとセキュリティに異なる影響を及ぼし、言及したGUIDの信頼性を保証できないため、一般的には機能しません。
- 簡単にキャプチャできます。アクセスできるWebサーバーにユーザーをリダイレクトするだけです。
- 誰かがカスタムブラウザーを作成して（または既存のブラウザーのソースコードを変更して）GUIDを偽造することを妨げるものは何もないため、「（いかなる状況でも）変更されるべきではない」という点は実際には機能しません。
- このソリューションには、誰かを一意に追跡できる（以前のポイントを確認しない場合）など、他にもさまざまなプライバシーの影響があります。
これにより、あるブラウザのCookieが別のブラウザではまったく役に立たなくなるため、セッションハイジャック/ Cookieハイジャックの問題は完全に解決しませんか？
完全ではありません。同じコンピュータで誰かがあなたのクッキーをハイジャックした場合はどうなりますか？ （公共のコンピューター）。そして、誰がGUIDを送信しますか？ブラウザ自体、GUIDをコピーすることもできるため、大きな脆弱性が残ります。ユーザー入力を信頼しないでください！
HttpOnlyをご覧になることをお勧めします： https://www.owasp.org/index.php/HttpOnly
「GUID」をプライベートキーで変更します。ユーザーが（またはドメインベースで）最初にブラウザーを起動/提供したときに生成され、クライアントの応答に署名して識別する方法を使用します。
これは、Secure Shell（SSH）ベースの自動認証が機能する方法とまったく同じです。ただし、固定またはドメインベースの秘密鍵を使用するようにブラウザーを編集する必要があることを現実にするには、ログインページを追加します。ログインページでは、ログインに成功するとクライアントの公開鍵がアップロードされ、保存する必要があります。また、HTTPSサーバーを変更して確認します。格納されているものに対するクライアントID。
これは実際のHTTPSと非常に似ていることに注意してください。永続的なクライアントキーとサーバー側のキー<->セッションルックアップを追加する必要があるだけです。
これは実際には「クライアント認証TLSハンドシェイク」と呼ばれていますが、従来のログインによるキー交換は標準ではありません。
その後、秘密鍵が保護されている限り、セッションは保護されますが、すでに多くのブラウザーがパスワードをそれらに保存する方法を提供しているため、これは大きな問題とは見なされません。