web-dev-qa-db-ja.com

SSLを使用せずにFireSheepからWebアプリを保護できますか？

一部のWebユーザーにWebサイトへの特権アクセスを許可したいが、すべてのユーザーにSSLを提供することができない（または望まない）-少なくとも最初のログインページを過ぎたとします。

この場合、FireSheepを無効にするが、苦痛なユーザーエクスペリエンスを作成しないユーザーセッションを管理する方法はありますか？

web-applicationattack-preventionsession-management
19
Falkayn

原則として、受動的な攻撃から防御できる場合があります。しかし、実際にはそれは簡単なことではなく、優れたソリューションではありません。

原則として、JavaScriptで独自の暗号化コードを記述して、クライアント側のすべてを（JavaScriptで）暗号化できます。最初に遭遇するのは、JavaScriptの暗号化がブラウザーのネイティブ暗号化よりも実質的に遅いため、パフォーマンスが低いことです。自然な反応は、ユーザーのパスワードなど、最も機密性の高いデータのみを暗号化することを提案することです。ただし、これを正しく行うのは非常に難しく、多くの微妙な落とし穴があります。

  1. Cookieを暗号化していない場合、セッションハイジャックに対して脆弱であり、何も得られません。また、JavaScriptからCookieやその他のHTTPヘッダーを暗号化するのは簡単ではありません。したがって、おそらく独自のユーザー認証方法を発明し、セッション管理にCookie（自家製のもの）以外のものを使用することを余儀なくされるでしょう。これは多くの作業であり、間違いを犯しやすいものです。

  2. パスワードのみを暗号化すると、CSRF攻撃に対して脆弱になる可能性があります。盗聴者は引き続きすべてのページコンテンツを見ることができます。特に、CSRFトークンがリンクに含まれている場合、盗聴者はすべてのCSRFトークンを見て、CSRF攻撃を仕掛けることができます。これに対して十分な努力を払って防御することは可能ですが、クライアントとサーバーの両方でさらに多くの作業が必要であり、正しく行うのが難しいです。

  3. ユーザーがFacebookアカウントを使用してサイトにログインできる場合、Facebookを制御していないため、盗聴者がFacebookアカウントを盗んでサイトにログインするのを防ぐことはできません。

  4. それでも、ページコンテンツを変更する中間者攻撃（アクティブな攻撃）に対して脆弱です。 Firesheepを変更してARPハイジャック、競合攻撃、または中間者として自分自身を挿入し、すべてのページコンテンツを変更するその他の方法を使用することは、技術的にそれほど難しくありません。攻撃者はキーロガーとして機能する悪意のあるJavascriptを挿入したり、認証資格情報を盗んだりできるため、セキュリティが失われます。

  5. キャッシュの利点を失わないように注意する必要があります。

今は不可能だと言っているのではありません。それはほぼ間違いなくそうではありません。ほとんどの受動的な攻撃を防ぐWebサイトとソリューションを構築することはほぼ確実に可能です。しかし、それは複雑で簡単ではありません。つまり、それを構築するにはかなりのセキュリティの専門知識が必要であり、何かを台無しにする重要な可能性はまだあります。また、結果が高くつくことにもなります。そして、セキュリティは本質的に制限されています-どのスキームも部分的なソリューション/緩和にすぎません-したがって、価値は制限されます。それは良いトレードオフだとは思いません。

SSLを使用せずに盗聴から身を​​守るための最先端の試みについて読みたい場合は、次のリソースを参考にしてください。

また、SSLのパフォーマンスを向上させるためのリソースもいくつか紹介します。

SSLは無料ではありませんが、SSLのパフォーマンスへの影響は実際よりも悪いと人々が考えることもあるということも覚えておいてください。

7
D.W.

ここ で説明されているように、動的セッション管理による認証を含む「セキュリティスルーオブスキュリティ」スキームを使用して、現在のFiresheepを回避できます。 「ダイジェスト認証」（ RFC 2617 ）を使用できますが、それでもMITM攻撃に対して脆弱であり、ユーザーエクスペリエンスが低下し、サーバーはパスワード（または同等のパスワード）を平文で保存する必要があります。

ただし、SSL/TLSを回避しても、暗号化を使用しないという2つの基本的な問題を回避することはできません。（1）すべてのプライベートコンテンツが公開されて共有され、（2）攻撃者がスキームを突き止め、それを無効にする可能性があります。

アクティブな攻撃のかわいい例、パフォーマンスペナルティに関する神話、およびEFFからのSSLの展開に関する具体的なアドバイスをご覧ください： HTTPSを正しく展開する方法 。また、（まだ）Stack Overflowで修正されていない理由について Stack Overflowメタディスカッション にも注意してください。

一般的なサイトの露出は、私が最初に思ったよりも悪いことに注意してください。例えば。 Firesheepの作者としてのこのしわに注意してください 素晴らしい記事で説明

ここで攻撃されているサイトへのアクセスを単純に回避することはできません。 Facebookの「いいね」ボタン、Diggの「Digg It」ボタン、Twitterウィジェット、Flickrや他の写真共有サイトでホストされている埋め込み画像など、今日のウェブには膨大な量の混合コンテンツがあります。このコンテンツのいずれかを含むWebページにアクセスするたびに、ブラウザーはウィジェットをプルダウンするリクエストとともに、ユーザーが持つ認証Cookieも送信します。

彼がそこで議論するエラーを少なくとも修正することができます（ユーザーがログアウトしたときに実際にセッションCookieを無効にするようなものです!!）。

また、これらの「サイドジャック」攻撃からある程度自分自身を保護する方法についてユーザーにアドバイスすることもできます。 VPNを使用するか、WPA2 wifiネットワークを見つけます（ただし、WPA2の問題 こちら を参照）。

@ D.Wに感謝私が見た中で最も考え抜かれた暫定的なアプローチへのリンクは、Ben AdidaによるSessionLock Liteです。それは少なくともパッシブな攻撃者による永続的なハイジャックを防ぎます： Benlog"私のセッションCookieから手を離してください 。ただそこで止まらないでください-SSLデプロイメントを設計してください...

10
nealmcb

疑いの影がなければ、答えは[〜＃〜]いいえ[〜＃〜]です。セッションIDを伝達するための完全にセキュアなトランスポート層が必要です。安全でない接続を介してこのセッションIDを変換できないので、これは OWASP A9-Insufficient Transport Layer Protection の違反になります。

8
rook

私はルークの答えに同意します。ただし、ファイアシープと一般的にすべてのセッションハイジャックの使用を軽減軽減できるアイデアはあります。

私の提案は、ブラウザの指紋をすべてのユーザーにリンクすることです。指紋が異なる場合、ユーザーはこの指紋を自分のアカウントで再認証する必要があります。

基本的に、私は panopticlick.eff.org がブラウザを見るだけで作成できる同様のフィンガープリントを保存することを意味します。

  • 指紋が変更されるたびに、ユーザーがこの指紋を認証したことを確認してください
  • このユーザーアカウントで指紋が認証されていない場合は、ユーザーを再認証します。

Webユーザープロファイリングの詳細については、以下を参照してください。

2
Chris Dale