2009-06-12 7 views
0

セットアップが表示されません'/ login/**'はmy channelConfig.secure []リストにありますが、他のほとんどはchannelConfig.insecure []に​​あります。/loginのリクエストはすべてhttps://にリダイレクトされ、他のすべてのリクエストはhttp://にリダイレクトされます。ログインページがSSLを使用して、暗号化されていないページは暗号化されたセッションクッキー(Grailsの、Acegiのは)

私の問題は、ログインプロセスがCookieを「暗号化された接続のみで送信」に設定するため、ログインページが/ homeにリダイレクトされると、ホームページにCookieが表示されずにリンク先ページ。私が再度ログインしようとすると、ログインページはクッキーを見て、私をリダイレクトします。

私はthis page about SecurityConfigで狩りを行い、暗号化されていないHTTP経由で作成されたSSL上のCookieを読み取るオプションがあるかどうかを確認しましたが、何も見つかりませんでした。暗号化されていないコントローラでログインCookieを利用できるように設定できるオプションはありますか?

答えて

6

これは脆弱性です。

セッションクッキーを見ることができるman-in-the-middleは、ユーザーとしてリクエストを行うことができます。これは、パスワードが傍受されるほど悪いです。 man-in-the-middle自分自身で新しいセッションを確立することはできないだろうが、彼は、ユーザーがユーザーがログイン後に何かできることを行うことができるだろう。


SSLを使用してはありませんログイン時にユーザー名とパスワードを単に隠すだけではありません。

最初に、クライアントとサーバー間のすべてのメッセージに対して機密性を提供します。機密データとしてパスワードを認識するのは簡単ですが、どのアプリケーション機能が機密データを使用しているかは明白ではないかもしれません。ユーザー入力と動的に生成されるコンテンツを保護することは、アプリケーションで使用される各データフィールドのプライバシー問題を慎重に評価するよりも安全で簡単です。画像、ヘルプページなどの静的コンテンツはおそらく敏感ではありませんが、そのコンテンツの要求を分析することで、攻撃者はユーザーがサイト上で何をしているかを知ることができます。

第2に、SSLはすべての要求に対して完全性を提供します。これにより、攻撃者は、自分の悪意のある入力を変更したり、ユーザーの要求に追加したり、サーバーによって生成された結果を変更したりすることができなくなります。

+0

ログインページを唯一の暗号化ページにすることは、暗号化がない場合とまったく同じように悪いですか? プレーンテキストでパスワードを送信する必要はありませんが、すべてのページを暗号化する必要はありませんか?もしそうでなければ、私は私のアプローチを変えなければならない。 –

+0

ほぼパスワードを明らかにしていないため、他のサイトで同じパスワードを使用してもサイトが完全に脆弱な場合には、ユーザーに何らかの問題が発生する可能性があります。私はいくつかの情報で私の答えを更新しました。 – erickson

+0

包括的な答えをありがとう。暗号化されていない接続を使用する主な理由はパフォーマンスでしたが、HTTPとHTTPSのパフォーマンス(http://stackoverflow.com/questions/149274/http-vs-https-performance)に関する別の質問を読んだ後、私たちは私たちのコンテンツのほぼすべてが動的なので、それから主要な速度です。 –

関連する問題