web-dev-qa-db-ja.com

Yahoo SignIn Sealはフィッシング防止に有効ですか?

重複の可能性:
セキュリティイメージの有効性

Yahooの有効性に関する情報 SignIn Seal は乏しく、私が見つけた最高のものはWikipediaのフィッシングに関するエントリ このセクション で、画像がありません」と「この機能[...]は他の攻撃を受けやすい」(どれですか?)しかし、ユーザーがそれに注意を払っていたとしても、私はコンセプトに頭を抱えるのに苦労しています。

ユーザーが実際にその特定のサイトにいるときにのみ、シールが表示されることをどのように保証しますか? Yahooのログインページのソースコードを見ると、無数のテクニックが使用されているのがわかりますが、それらの目的が何であり、それらがどのように連携して目標を達成するのかを理解するのは困難です。

  • JavaScriptを使用して、ページがiframeにあるかどうかを確認します(画像が表示されている場合、またはJavaScriptが無効になっている場合)。
  • 挿入された画像のsrcには、ランダムに見える長いトークンが含まれています。
  • 画像のURLはすぐに期限切れになるため、盗まれて他の場所で使用されることはありません。

上記から推測できること:

  1. ログインページリクエストがユーザーのブラウザから開始されている必要があります、またはシールを保持するCookieが送信されません;
    • 攻撃者がページをiframeに入れると、同じ起源のポリシーにより、コンテンツにアクセスできません。
    • 同様に、攻撃者は同じ理由でAjaxを介して要求することはできません。
  2. ログインページのリクエストに応じて、サーバーはその画像を提供する一意のURLを準備します(Cookieのコンテンツを使用-画像はサーバーに永続的に保存されません)。攻撃者がアクセスできなかった推測できないトークンを使用します。
  3. 画像は、ページがiframeにないことをページが正常に判断した場合にのみ表示されます。したがって、ユーザーが画像を見れば、サイトが合法であることを確信できます。

私の推論は正しいですか?このスキームに対する既知の攻撃はありますか? (多分MitMなどが関係するもの)

4
mgibsonbr

このサイトのどこかに、似たような質問をする回答があります。要約すると、エンドユーザーはこの機能を要求しますが、実際にはまったく保護されません。

このシナリオでユーザーをだます方法の1つは、SSLStripを使用してチャレンジ画像を"server down for maintenance".jpgに置き換えることです。ほとんどのユーザーはこれを確認し、選択した実際のアイコンの代わりとして喜んで受け入れます。

他の回答が見つかれば、リンクを投稿します。


更新:この機能はSiteKeyと呼ばれます。 これはソリューションとその脆弱性の優れた説明です @ D.W。

2

「正しい」攻撃は、Cookieがまだ存在しない状態でブラウザにログインしようとしたときに見られる動作をエミュレートすることだと私には思われます。これにより、「サインインシール」が完全に無効になり、デフォルトの動作に戻ります。

これは、ユーザーが別のブラウザーまたは別のコンピューターを起動したり、Cookieをクリアしたりするたびに(手動で、または熱心な「追跡防止」ツールからの介入により)表示されるエクスペリエンスであるため、ユーザーはそれに慣れているはずです。 。

もちろん、通常の表示とは少し異なりますが、「本物」と認識するのに十分な頻度で表示されており、資格情報を入力する以外に方法はありません。結局のところ、この画面を見たときはいつもそれを行っていたのです。それは、毎回正しい動作でした。

だから、絶対確実というわけではありませんが、このテクノロジーは少なくとも正しい方向への一歩です。完璧なものではありませんが、何もないよりはましだと主張することもできます(そうでないことを主張することもできますが、そこに行きます)。少なくとも彼らはそれについて考えています。それは数年前よりもずっと進んでいます。

2
tylerl