私たちには、SSLの使用に制限があるため、ログイン/サインアップにSSLを使用するウェブサイトがあります。 ログイン後、別の安全でないサイトに行き、radnomが生成したセッショントークンを使用してユーザートランザクションを識別します。SSLセキュアなログインですがセキュアではないリソースですが、これは意味がありますか？
どのように安全ですか？実際のユーザーがブラウズしている間にスニッファがトークンをキャッチした場合、それを悪意のある操作に使用できることを考慮してください。
ユーザーのセッションを保護するための他のアイデアはありますか？
お好みの検索エンジンへの事前
セッショントークンを使用してHTTP経由でアクティブセッション（標準で確立された慣行）を維持している場合、セッションのハイジャックが発生しやすくなります。有効なトラフィックフローを傍受してそのトークンを取得し、 。
これを防ぐには、トークンが暗号化されたトンネルを介してのみ送信されるため、SSL/TLS経由でユーザーとのやりとりをすべて行う必要があります。
あなたがそうすることができない場合、あなたは脆弱です。セッショントークンをIPアドレスに関連付ける（セッショントークンが発行されたのと同じクライアントIPアドレスで提示された場合にのみ受け入れる）ようなことを行うことで、このリスクに対するある程度の緩和を導入することができます。 IPアドレスが変わると、ワームの蔓延が変わる可能性があります（たとえば、ユーザーがサイトにログインした後、ワイヤレスネットワークを移動すると想像してください）。
この脅威が十分に重要であるかどうかを確認する必要があります。アプリケーションで処理されるデータのタイプは何ですか？それが機密であるならば、おそらくあなたはそれを保護する必要があるでしょう...もしそれが公開されていて、誰が何にアクセスしているのかを追跡するためにユーザーログインを使用しているのであれば、おそらくそうではありません。
OWASP Session Management webpageには他にもいくつかのアイデアがありますが、本当にこの脅威に対処する必要がある場合は、SSL/TLS経由のすべての対話を行う必要があります。
Jeffさん、ありがとうございました。それは有益でした:) –
私は助けてうれしい！ – jeffsix
パンチFiresheepのおかげで、それは良い考えではありません、それはすぐに明らかになるだろう。
ええ、私はこのFirefoxのプラグインを知っています...しかし、私はSSL以外の解決策がないとは想像できません。 –
他の解決策がありますが、それらはずっと悪化する傾向があります。あなたはAJAXを使用してすべてを行い、必要な任意の形式の暗号化を使用することができます。 –
寄付いただきありがとうございます –
この主題は、ITセキュリティスタック交換に大きな長さで文書化されています：
What sites are still vulnerable to FireSheep?回答：SSLのサイト全体を使用していない任意のサイト - だけのためにあなたの提案されたアプローチ（SSLを使用するサイトログインフォーム、SSLなし）は脆弱です。
Can you secure a web app from FireSheep without using SSL?短い回答：いいえ。長い答え：理論的にはそうですが、実際にはそうではありません。すべての選択肢が悪化する。
What are the pros and cons of site wide SSL (https)?長所：あなたはもはや脆弱ではありません。
そして最後に、ボーナス：この脅威から身を守る方法の詳細：
これは非常に詳細な短い回答でした。 –
ありがとう、@ BasselAlkhateeb！それが助けてくれてうれしい。それが参考になったと思ったら、それをアップウォークしてください。 –
私は..しかし、誰かがdownvoted :) –
さて、あなたはあなたの答えの権利を持っていますあなたの質問で。ユーザーのログイン資格情報は保護されていますが、誰でもそのユーザーのアクティブなセッションを引き継ぐことができます。 –