web-dev-qa-db-ja.com

CASがユーザーIDを訪問した任意のWebサイトに漏洩しないようにするにはどうすればよいですか？

概要

evil.example.comは、非表示のフレームを使用して、corporation.example.netにCASチケットを要求し、それを検証して、不幸なユーザーのユーザー名を受け取ることができます。これにより、CASユーザーはアクセスする悪意のあるサイトに匿名化されます。

  • CASサーバーの作成者/保守者として、ユーザーの匿名化を防ぐにはどうすればよいですか？
  • CASユーザーとして、自分の匿名化を防ぐにはどうすればよいですか？

バックグラウンド：

CAS（中央認証サービス） は、リダイレクトベースのフローを備えたシングルサインオンシステムです。

  1. クライアントページは、クライアントサイトのURLであるserviceパラメータを使用してCASサーバーにリダイレクトします。
  2. CASサーバーは、既存のCookie、ログインページなどを介してユーザーを認証します。
  3. CASサーバーは、serviceパラメータが追加されたticket URLにリダイレクトします。
  4. クライアントはサーバー検証エンドポイントを呼び出し、チケットをユーザー名に交換します。

攻撃

  1. ユーザーは既にcorporation.example.netのCASサーバーで認証されており、ブラウザーにはそのドメインのチケット許可Cookieがあります。
  2. ユーザーがhttp://evil.example.com/dancing-bunnies.htmlにアクセスすると、http://corporation.example.net/cas/login?service=http://evil.example.com/attack.htmlがフレームとして埋め込まれます。 （フレーミングはリダイレクトよりも目立ちません-セキュリティの違いはありません。）
  3. フレーム内のCASサーバーの/loginエンドポイントは、ユーザーエージェントがすでにログインCookieを保持していることを認識しているので、サービスURLとチケットに盲目的にリダイレクトします：http://evil.example.com/attack.html?ticket=ST-abc123
  4. evil.example.comはクエリ文字列からチケットを読み取り、http://corporation.example.net/cas/validate?service=http://evil.example.com/attack.html&ticket=ST-abc123を取得してyes\nalice\nで応答します。
  5. evil.example.comは、ユーザーがalice @ corporation.example.netであることを認識しました。

改善の可能性

  1. serviceパラメータURLのドメインを既知の安全なセットに制限する
  2. クライアントにリダイレクトする前にユーザーの操作を要求する
  3. フレーミングを禁止する（ヘッダーまたはスクリプトを使用）

これらのいずれかの欠点はありますか？他の解決策はありますか？

ノート

  • serviceパラメーターを一連の既知の安全なURLの文字列一致に制限することは、リダイレクトプロセスを通じて状態を伝えるためにクライアントによって使用されるため、おそらく実用的ではありません。

ETA：あなたの答えが次のことを前提としている場合、私はとても悲しいでしょう...

  • ...攻撃がオリジン間の通信に依存していること。
  • ...これはユーザーを匿名化する以外のことを行うと主張している
privacyanonymitysso
3
treat your mods well

ここに記載されているように、CAS 3にはサービスホワイトリストの拡張ポイントがあるようです https://wiki.jasig.org/display/CAS/well-known+modifications

メモで述べたように、これはあなたの懸念を解決し、あなたが利用できるはずです。

1
BoltzmannBrain

免責事項：CASはわかりませんが、CASの機能と仕組みを理解したと思います。

企業のWebサイトにフレーム無効化ヘッダーがない場合でも、攻撃シナリオはこの方法では不可能です。これらのフレーム無効化ヘッダーはクリックジャッキングを回避するためのものですが、それは別のトピックです。

フレームがリダイレクトを行う場合、フレームのコンテンツのみがリダイレクトされます。

悪意のあるサイトは別のサイトにあるため、埋め込まれたフレームのすべて（URLでさえも）にアクセスできません。可能であれば、そのようなシナリオは可能ですが、すべての最新のブラウザーは（IE4以降だと思いますが）クロスサイトアクセスを許可しないため、悪意のあるサイトは新しいURLにアクセスできず、IFRAMEの識別されたユーザーにアクセスできません。

ユーザーは常にログアウトすることで身を守ることができ、疑わしいサイトが許可を求めた場合は認証しないでください。

このシナリオの良い例はFacebookです。多くのサイトがFacebookのコメント機能やその他のものを組み込んでいます。ただし、ユーザー名は取得されません。どういうわけかFacebookユーザー名を取得できる場合（Facebookユーザーはめったにログオフしない）、これは大きなセキュリティホールになります。バグ報奨金を取得する方法、またはログオンしてユーザーの名前で投稿または投票する方法が見つかった場合は、申請することができます。

1
http

それは良い質問です。ただし、CASプロトコルについての私の理解は、/ serviceValidate URIを呼び出すと、CASはリクエストパラメータから取得したサービスチケットがサービスレジストリで使用可能かどうかをチェックし、さらにサービスが登録済みサービス。

あなたの例では、evil.example.comは登録されないため、CASサーバーが不正なサービス例外をスローするため、ユーザーIDを取得できません;）.

0
Melvin