web-dev-qa-db-ja.com

セッション用のHTTPSおよび暗号化されたCookie

現在、CASを使用したSSOシステムを開発しています。 CASは、SSOセッションと見なすことができるチケット許可チケット（TGT）を使用します。 CASはデフォルトでTGTを暗号化します。また、デフォルトでは、ノード間にHTTPSがあります。

HTTPSはすでに暗号化を扱っているため、Cookie（TGT）の値を暗号化する必要がある理由がわかりません。はい、まだCookieから値を読み取って使用できます。ただし、セッションをすでにハイジャックしている場合は、クライアントが暗号化されたTGTをサーバーに送信するだけで、それを以前に復号化しないため、暗号化されたTGTを使用してそれを行うこともできます。

だから私の質問は：すべてのノード間ですでにHTTPSがある場合、暗号化されたCookie値の理由は何ですか？考えられる攻撃シナリオについて言及できますか？

encryptiontlscookiessso
2
yemerra

通常、sslで暗号化されたWebサイトにアクセスする場合、通常はcookieを暗号化する必要はありませんが、誰かが何らかの方法でssl接続をハイジャックしても、TGTはそのユーザーには使用できません。

SSOシナリオと同様に、状況は大きく変化します。

認証プロセス/要求フロー

IDがKDC（鍵配布センター）で検証された後の認証プロセス中に、認証サーバーは2つのメッセージを送信します。

One message is the TGT that contains:
    your name/ID,
    the TGS name/ID,
    timestamp,
    your network address 
    lifetime of the TGT 
    TGS Session Key,
    and is encrypted with the TGS Secret Key . 

The other message contains:
    the TGS name/ID,
    timestamp,
    lifetime (same as above), and
    TGS Session Key
    and is encrypted with your Client Secret Key.

TGSセッションキーは、ユーザーとTGSの間で使用される共有キーです。次のステップで

クライアントシークレットキーは、パスワードの入力を求め、ソルトを追加し、全体をハッシュすることによって決定されます。これを使用して、TGSセッションキーを取得するために2番目のメッセージを復号化できます。
ただし、TGS秘密鍵がわからないため、TGTを復号化できません。暗号化されたTGTは資格情報キャッシュ内に保存されます。

これでTGSセッションキーが取得されました。TGSから必要なサービスにアクセスするための最終トークンを要求できます

TGT（TGS秘密鍵で暗号化されたもの）と、たとえばHTTPサービス要求（TGSセッション鍵で暗号化されたもの）がTGSに送信されます。

TGSはTGTを復号化し、TGSセッションキーをフェッチします。このキーを使用して、http認証リクエストを復号化します。

チケット認可サーバーは、HTTPサービスセッションキーをランダムに生成し、以下を含むHTTPサービスチケットを準備します。

your name/ID,
HTTP Service name/ID,
your network address 
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
and encrypts it with the HTTP Service Secret Key.

次に、TGSから2つのメッセージが送信されます。 1つは暗号化されたHTTPサービスチケットです。他は含んでいます：

HTTP Service name/ID,
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
that is encrypted with the TGS Session Key.

メッセージクライアントを受信するまでは、2番目のメッセージを復号化し、httpセッションキーを取得します。

これでユーザーはHTTPサービスにアクセスできます

TGTが暗号化されていない場合

TGTが暗号化されていなかった場合、それを持っている人は誰でもHTTPサービス要求を変更でき、要求の誰かのIDを偽造して、HTTPサービスセッションキーを取得します。

ユーザーでも、TGTを変更することで、認証プロセスをとにかく利用できます。

tGT暗号化の誤用を避けるために行われます

1
8zero2.ops

クッキーはブラウザに残ります。また、機密情報が保存されている場合は、暗号化する必要があります。ただし、機密情報はCookieに保存しないでください。
そしてセッションID（すでにランダムな値です）の暗号化はまったく意味がありません。また、一部のユーザー情報をセッションIDとして使用している場合、この方法自体は不適切であり、暗号化する代わりに、セッションの管理方法を再定義することを検討する必要があります。これについてOWASPを確認してください。

0
one

Cookieが、サーバーがユーザーを識別できるようにする単なるセッションIDである場合、正しくコメントすると、TLS暗号化に加えて、暗号化は無意味になります。ただし、実際にはCookieに情報を保存する必要があるアプリケーションが存在する可能性があります。この情報は、ユーザーがブラウザーの開発ツールを使用して自分のCookieを検査することから、機密性を保持したい場合でも機密に保ちます。例としては、サーバーが単一のデータベースを共有せず、Cookieに含まれる分散環境のセッション情報などがあります。ユーザーに見せたくない発行サーバーの秘密の識別子。彼女はそれを偽装する可能性があるためです（もちろんこれは純粋な推測です）。

私はいつもそのようなデザインを避けて、SAMLのようなオープンスタンダードを採用しようとしますが、このようにするアプリケーションがあると確信しています。

0
kaidentity