1

既成のミドルウェアを使用せずに、wsgi-appをブラウザーセッション管理に実装する可能性と推奨事項を検討しています。

検討中の一般的なアプローチは次のとおりです。

ブラウザとサーバー間でSSLを使用します。SSLセッションIDをWSGIまたはOS.environmentに公開し、アプリケーションレベルの永続性と認証を有効にするセッションIDとして使用します。サーバーとブラウザが再度ハンドシェイクするとSSLセッションIDがいつでも変更される可能性があるため、Cookieを使用して、生成されたSSLIDのハッシュバージョンを保持することをお勧めします。ハンドシェイクしてSSLIDの変更が検出された場合（環境に公開されたSSLセッションIDがクライアントから返されたCookieと一致しない場合）、ハッシュされたCookieをチェックして、以前の既知のセッションIDが含まれているかどうかを確認できます。次に、現在のセッションを続行し、Cookieで使用される（およびバックエンドデータベースに保存される）SSLセッションIDを、ハンドシェイクを介して新しく生成されたSSLセッションIDに更新する必要があります。したがって、SSLセッションIDを使用してもセッションを続行できます。

私が理解しているように、SSLでセッションIDを生成し、セッションIDを保持するためにcookies+hmacだけに依存するよりも安全な処理を実行するという考え方です。

上記のプロセスについての誰かの考えに興味があります。原則としては聞こえますが、この種の機能についてはほとんど経験がありません。いくつかのシナリオでクライアントとサーバーとwsgi-appの間の交換の流れを引き出しましたが、うまくいくように見えますが、すべてのベースをカバーしたのは快適ではありません。

4

1 に答える 1

3

プロトコルの何が問題になっていますか

次のことを検討してください。

  1. Alice はサーバーに接続し、SSL セッション ID を取得しますS。を含む Cookie がH(S)Alice に送信されます。
  2. ボブは交換を聞いています。SSL セッション ID は暗号化されていないため、彼はS.
  3. Bob は、セッション Cookie を に設定してサーバーに接続しますH(S)。彼のセッション ID は認識されませんが、あなたのシステムは彼を Alice のセッションに入れます (おそらく Alice も追い出します!)。

解決策は、HMAC を使用してセッション ID に署名することです。しかし、そもそも HMAC 化されたセッション ID を使用することもできます。

いくつかの詳細:

  • ボブが送信する Cookie の名前を知るには、サーバーに連絡するだけです。
  • ボブは、あなたが使用しているハッシュアルゴリズムのアイデアを得るために同じことを行うことができます.

HMAC の優れている点

セッション Cookie + HMAC は暗号的に安全であることが証明されています。HMAC は、データの認証を目的として設計されました。HMAC の背後にあるロジックは健全であり、今日の時点で、プロトコルに存在する攻撃はありません。

さらに良いことに、基礎となるハッシュ アルゴリズムへの攻撃は、HMAC への攻撃が存在することを意味しないことが証明されました (ただし、MD5 を使用する必要があるという意味ではありません!)。

HMAC を使用したくない理由はありません。

SSL セッション ID は、せいぜい、ロード バランサーに役立ちます。

独自の暗号化を実装しない

暗号化を再発明してはなりません。暗号化アルゴリズムは、この分野で多くの経験を持つ (おそらく) 何千人もの人々によってレビューされてきました。

より良いアイデアが浮かんだと感じたときはいつでも、何かが欠けている可能性があります。多分あなたはそうではありません！しかし、アルゴリズムに関する論文を書き、査読を受ける必要があります。

標準に固執します。

于 2012-12-07T12:01:13.097 に答える