web-dev-qa-db-ja.com

HTTPS Webアプリケーションの場合、パスワードをPOSTする前に暗号化して、MITM攻撃者がパスワードを不正に利用することを防ぐ価値はありますか?

私たちのアプリケーションは、最近侵入テストを通過しました。テストでは、本質的に次の1つのクリティカルセキュリティ違反が見つかりました。

問題:

  • 攻撃者はWiFiスポットを設定します。
  • ユーザーが当社のサイト(HTTPS)に入ります。
  • 攻撃者は、Cainなどのツールを使用して、ユーザーをHTTPにリダイレクトするか、なりすまし証明書を使用してHTTPSに保持します。 (いずれにせよ、ユーザーは「ここから外れる」/「例外を追加する」ページを通過する必要がありました)
  • ユーザーは自分のユーザー名とパスワードを入力します。
  • パスワードはMITM攻撃者に投稿され、攻撃者はそれを見ることができます。どうやらCainにはユーザー名とパスワードを自動的に収集する機能があり、私たちのパスワードはそこで簡単に捕まえられるでしょう。

推奨される解決策

このレポートでは、(JavaScriptを使用して)クライアント側でパスワードを暗号化またはハッシュ化することを推奨しています。彼らは特定のスキーマを推奨することはできませんでした(彼らはクライアント証明書に言及しましたが、これは大規模なアプリケーションには非現実的かもしれません)。

投稿する前にパスワードを暗号化またはハッシュする価値はありますか?それは一般的な慣行ですか?

31
Kobi

この推奨事項は意味がありません。パスワードのハッシュ化または暗号化に使用されるJavaScriptコードは、クライアントにも転送する必要があります。攻撃者がman-in-the-middle攻撃を仕掛けることができる場合、暗号化に使用されるJavaScriptコードを検査することもできますし、それを別のもの(暗号化しないなど)に置き換えることもできます。

暗号化の代わりにハッシュすることは、サーバーが実際のパスワードの代わりにハッシュされたパスワードを受け入れる場合にのみ機能するため、あまり意味がありません。この場合、攻撃者はパスワードを知る必要すらなく、ハッシュを知っていれば十分です。

クライアント証明書を保持するSSL中間者攻撃をマウントできないため、クライアント証明書が役立つ可能性があります(プレーンHTTPにダウングレードしても証明書は送信されません)。ただし、最初にクライアントに証明書を配布し、それをブラウザ内にインストールする必要があるため、このソリューションはクライアントが少ない場合にのみ機能します。

それとは別に:攻撃者が途中にいる場合、パスワードはまったく必要ない可能性があります。彼が必要とするのは、被害者がログインし、攻撃者が既存のセッションを引き継ぐことだけです。

このような中間者の状況を検出して、ユーザーに通知し、侵害されたネットワークからのログインを拒否できるようにすることも役立つ場合があります。接続のダウングレードを検出するためのいくつかのアイデア(つまり、httpを攻撃者に送信し、それをhttpsとして転送する):

  • JavaScriptで現在地のメソッドを確認してください。
  • JavaScriptで安全なCookieを作成します。サイトがhttps(ダウングレードなし)で提供されている場合にのみ、返送する必要があります。
  • 画像を提供するスクリプトをHTTPとして組み込み、サーバー側で画像がどのように組み込まれたかを確認します。それがHTTPSとして含まれている場合は、HTTPに明示的に含まれているため、HTTPダウングレード攻撃を想定できます。 HTTPでアクセスされた場合、ダウングレード攻撃も行われます(ただし、より優れた攻撃者が行われます)、またはブラウザーは混合コンテンツを気にしません。

そして、偽造された証明書で中間者を検出する方法について:

  • 2番目のhttpsサイトを(異なるホスト名で)セットアップし、このサイトへのajaxリクエストを構築します。これは、攻撃者がhttpに変更する(たとえば、URLを動的に作成する)のは簡単ではありません。証明書が信頼されておらず、ブラウザがユーザーにサイトのプライマリ証明書のみを要求するため、攻撃者が任意のサイトをMITMしようとすると、このajaxリクエストは少なくとも一部のブラウザで失敗します。

もちろん、これらすべては、特にあなたをハッキングすることを本当に決心していない攻撃者に対してのみ役立ちますが、最も簡単なターゲットを奪います。この場合、あなたがしなければならないのは、他よりも攻撃するのが少し難しいことだけです。

49
Steffen Ullrich

代わりに HTTP Strict Transport Security を実装することをお勧めします。これにより、ユーザーは最初から偽装された証明書を受け入れることができなくなります。

11
suriv

アクティブなMITM攻撃中に攻撃者がJavascriptコードを簡単に置き換えることができることを無視したい場合:

非対称暗号化キーを生成し、クライアントにその公開キーを提供して、クライアント側でパスワードを暗号化するために使用できます。ログインごとに新しいキーを使用すると、誰もパスワードを再発行できなくなります。

3
flob