認証のためにCookieを十分に盗まないのはなぜですか？
Cookie認証を使用するログインページの「このCookieを編集」拡張機能を使用して、すべてのCookieをエクスポートしようとしました。ログアウトしているときに、ログインすることを期待してCookieを挿入しようとしましたが、何も起こりませんでした。
検索したところ、送信されたCookieが暗号化された形式であることがわかりました。しかし、ページはTLS暗号化を使用していませんでした。何か不足していますか？
編集：ログイン済みのときに同じCookieを使用しようとしました。つまり、すべてのCookieをエクスポートし、シークレットウィンドウにインポートしましたが、何も起こりませんでした。
また、この種の攻撃は、Google、Facebookなどの最も人気のあるサイトでは機能していないようです。では、このような攻撃からどのように保護しますか？
技術的には、Cookieのコンテンツが暗号化されていたとしても、Cookieが新しいブラウザに正しくコピーされ、新しいブラウザが同じHTTPヘッダーを送信する場合（同じユーザーエージェント文字列、リファラーは期待どおり、コンピューターは同じIPアドレスを持ち、他のすべての headers サーバーは以前に保存して比較することができます）、サーバーは理論的には区別できません元のブラウザと新しいブラウザの間。
私は、ブラウザを開いてログアウトしていないたびに自動ログインするサイトからCookieをコピーしようとしていると想定しています。
一部のサイトは、これが盗まれたcookie /セッションであるかどうかを検出するために他の方法を使用する可能性がありますが、それは 敗北 です。
- IPアドレスが変更されたかどうかを確認する
- ユーザーエージェントは同じですか
- リファラーに意味があるかどうかを確認する
- ブラウザが送信するその他のHTTPヘッダー
あなたの質問に答えるために、自動ログインサイトを扱っていて、まだログアウトしていない場合、それを機能させることができるはずです。新しいブラウザが送信しているすべてのHTTPヘッダー 同じ であること、IPアドレスが同じであること、リファラーが予期されるもの、同じユーザーエージェントであることを確認してください。
また、使用しているサービスが、コピーを忘れた2番目のCookieを使用しているため、異常が発生し、追い出されることに注意してください。
Cookieの内容はアプリケーションで定義され、それらを使用する方法にはさまざまな種類があります。ここに、あなたの努力が失敗した考えられる理由のいくつかの短いリストがあります。
- Cookieは、IPアドレス、デバイスの指紋、またはキャプチャしていないその他の非Cookieデータにバインドされています。
- 元のCookieには有効期限が含まれており、有効期限が切れています。
- Cookieは使い捨てです。つまり、サーバーはリクエスト/レスポンスごとに値をローテーションし、すでに使用されているCookie値を無効にします。
- Cookieがサーバーに存在しないセッションにバインドされました（ログアウトした可能性があります）。
- Cookieがページ内の非表示要素（CSRFトークンなど）とペアになっていて、その値を取得または再作成していない。
- サーバーは負荷分散されており、procのセッション状態と、ロードバランサーによって実施される一時的なセッションスティッキ機能メカニズムが備わっています。新しいセッションでは、クライアントには、セッションが存在しないファーム内の別のノードが割り当てられました。
- Webサーバーはルールエンジンを使用して不審なアクティビティを検出し、スプーフィングされたCookieが順序どおりに表示されなかったか、予期しないときに表示されました。
- Cookieは問題ありませんでしたが、リファラーヘッダーなど、その他の詳細をめちゃくちゃにしました。
- Cookie自体は、それらを配信した接続ではなく、署名または暗号化されている可能性があります。
- ログアウトしたときに、サーバーがデータベースからセッションを削除した可能性があります。
前述のように、ログアウトすると、サーバーは盗んだばかりのCookieを無効にして、自分になりすまそうとする価値がなくなります。
したがって、この特定のWebサービスからセッションを盗むために必要なものをテストするためにCookieを盗もうとすることを本当にテストしたい場合は、Cookieをエクスポートして、ログアウトせずに新しいブラウザー/シークレットモードにインポートする必要があります。元のブラウザのタブ。
ただし、注意してください。Cookieは、他の多くの基準と照合されることもあります。 IP、ユーザーエージェントなどをチェックできます https://wingsdream.wordpress.com/tag/mitigating-http-session-hijacking/
また、トークンやブラウザのフィンガープリントを継続的に更新するシステムなど、さらに巧妙な戦略を考案して、このCookieを所持している人物がそのCookieを渡した人物であり、盗まれていないことを再確認することもできます。したがって、認証Cookieを「盗む」場合でも、それらで認証することができない場合があります。
サーバーでセッションが無効化されました。安全なWebサイトは、あなたが説明している種類の攻撃を正確に防ぐためにこれを行います。ログアウトすると、サーバーは自身のデータベースからセッションを削除するため、同じセッションCookieが再度使用された場合でも、サーバーはそれらを受け入れません。このため、たとえブラウザーがCookieを保持していなくても、ブラウザーを閉じるだけでなく、Webサイトから適切にログアウトすることが重要です。
安全でないウェブサイトは、セッションをサーバー上に置いたままにする可能性があるため、「ログアウト」（つまり、ブラウザーからCookieを削除）した後でも、同じセッションCookieを後で再び使用できます。
実験を繰り返しますが、今回は事前にログアウトしないでください。 Webサイトにログインし、ブラウザからCookieを手動で削除します。 Cookieなしで再度Webサイトにアクセスすると、ログインできません。Cookieを復元してWebサイトに再度アクセスしてみてください。再度ログインする必要があります。
単純なサイトの場合は、Cookieをコピーするだけで十分です。より「安全な」サイトでは、他の人がIPなどの他の要素について言及したように、セッションを固定します。
ローカル/セッションストレージ、IndexDBなどの他の永続的な値をチェックするJavaScriptコードが存在する可能性もあります。それらを見てみてください。これは、すべてのデータがajax経由でロードされ、oAuthと永続ストレージの形式が一緒に使用される単一のサイトアプリケーションである可能性もあります。シークレットは他の場所に保存されるため、Cookieは必要ありません。
多くの場合、Cookieを盗みます[〜＃〜] is [〜＃〜]認証に十分ですが、何か間違ったことをした可能性があります。
TLS /暗号化はここでは関係ありません。ヘッダーからCookieを読み取っているときには、トラフィックはすでに復号化されています。すべてchromeは、すでに復号化されていることを示し、暗号化は完全に透過的です。
質問に答える。認証方式はさまざまです。 Cookieのみを使用する場合もありますが、その場合は盗むだけで十分です。時々彼らは全くクッキーを使用しません。時々彼らはクッキーと他のデータの混合を使います。
Cookieスキームは無限にあります。それらすべてに簡単な答えはありません。