トルネードにセッションがないのはなぜですか
クッキーはセッションよりも安全性が低いと聞きました。
たとえば、ユーザーがログインしているかどうかをWebがCookieを使用して検出した場合、Cookieを偽造して偽のユーザーをシミュレートできます。なぜなら、Cookieを読み取って簡単に偽造できるからです。これが私が見つけたリンクです： Session vs Cookie Authentication
pythonでTornadoを使用してWebサイトを構築しています。Tornadoでのログインモジュールの簡単な例を次に示します。 https://stackoverflow.com/questions/6514783/tornado-login-examples-tutorials
驚いたことに、トルネードにはセッションがありません。そのドキュメントは安全なクッキーがあると言いますが、私はそれが通常のクッキーより安全だとは思いません。
通常のクッキー：
_browser ------- I'm Tom, my password is 123 -------> server
_安全なクッキー：
_browser ------ &^*Y()UIH|>Guho976879 --------> server
_&^*Y()UIH|>Guho976879を取得できたとしても、Cookieを偽造できると思いますよね？
私が正しい場合、トルネードにセッションがないのはなぜですか？または、安全なCookieをセッションと同じように安全にする方法はありますか？ブラウザーを閉じたときにCookieを消去した方が安全なのでしょうか？
クッキーはセッションよりも安全性が低いと聞きました。
あなたは何かを誤解したに違いありません。実際、HTTPセッションは通常、Cookieを使用して実装されます。
＆^ * Y（）UIH |> Guho976879を取得できたとしても、Cookieを偽造できると思いますか？
確かにあなたはクッキーを変更できますが、それは有効なものとしてサーバーによって受け入れられますか？実際の ドキュメントを見てください をとると、次のようになります。
Cookieは安全ではなく、クライアントが簡単に変更できます。現在ログインしているユーザーを特定するなど、Cookieを設定する必要がある場合、偽造を防止するためにCookieに署名する必要があります。 Tornadoは、set_secure_cookieおよびget_secure_cookieメソッドを使用して署名付きCookieをサポートします。 ...
署名付きcookieには、タイムスタンプとHMAC署名に加えて、cookieのエンコードされた値が含まれています。 Cookieが古い場合、または署名が一致しない場合、get_secure_cookieは、Cookieが設定されていない場合と同様にNoneを返します。
したがって、セキュアなCookieを操作しようとすると、フレームワークはCookieを認識して無効として扱います。つまり、Cookieが最初から送信されなかったようなものです。
他の回答は、ここから保護されているforging Cookieではなくtamperingである、またはinspectingそれ。
「current_user = tom」と言うCookieをブラウザに送信すると、ユーザーは「current_user = dave」と言う代替Cookieを送り返すことができます。 Cookieを検証する対象がない場合、アプリケーションは「dave」としてログインしていると見なします。
これはsigning秘密鍵を使用するCookieによって軽減できます。改ざんされたCookieは正しい署名を持たないため、拒否されます。
ただし、まだ問題がある可能性があります。保存する状態の一部がsecretの場合。たとえば、ユーザーのバスケットに製品の原価とマークアップを格納したい場合があります。明らかに、ユーザーが読み取れるプレーンテキストのCookieはここでは適切ではありません。
これにより、2つの解決策が得られます。
- 暗号化 Cookieの内容。秘密鍵を知らない限り、Cookieの読み取りや修正はできません。
- 実際のデータをローカルに（たとえば、ディスクまたはメモリストアに）保存し、Cookieで識別子のみを送信します。これは一般に「セッションデータ」と呼ばれます。
セッションは実装が比較的簡単で、これらの特定の攻撃に対して安全であることが証明されています。ただし、Webサーバーやアプリケーションサーバーがデータを読み書きできる必要があるため、バックエンドインフラストラクチャに負担がかかります。これは、たとえば、複雑なロードバランシングのセットアップでは注意が必要です。そのため、アプリケーションサーバー間で共有する必要があるデータは秘密鍵だけなので、Cookieで少量のデータを直接暗号化するのが賢明な代替手段になる場合があります。
これらはいずれも、悪意のあるユーザーが本物のセッションからCookieを複製するだけのハイジャックなどの他の攻撃から直接保護しないことに注意してください。また、セッショントークンは、「セッション固定」と呼ばれる関連攻撃に対して脆弱である可能性があります。この場合、攻撃者は正規のユーザーが接続する前に識別子を選択するため、同一のCookieを作成できます。これは暗号化されたCookieでは不可能ですが、それに固有の攻撃が他にもあると思います。
あなたが見つけた質問は、あなたが何を参照している（私が思う）ことを本当に説明していません。彼らが説明している違いは、ユーザー側のセッション情報（ショッピングのどのアイテムがバスクされているかなど）がサーバー側であり、一意の識別子（別名セッションCookie）のみをクライアントに渡すか、またはすべてを保存するかどうかです。クライアント上で。
すべてのWebアプリケーションには、状態を維持するメカニズムが必要です。 HTTPはデフォルトでステートレスであるため、サーバーが1つの要求を別の要求に対応させる方法はありません。
ほとんどのアプリケーションがこれを解決する方法は、Cookieを使用することです。 Cookieの使用に関するセキュリティの課題はよく理解されており、正しく実装されていれば、重大なセキュリティの問題を引き起こすことはありません。
これを行うための他のオプションは、通常、認証ヘッダーであるため、HTTPダイジェストまたはNTLM認証を使用します。これは、社内のアプリケーションでより一般的ですが、JavaScriptを使用してこれらのヘッダーを生成することもできます（最新のシングルページアプリケーションで見られる）。
いずれにしても、ユーザーを識別するための各要求でクライアントからサーバーに渡される情報が必要です。
Cookieの偽造に関しては、通常、セッショントークンにはかなりのランダム性があるため、Cookie値を偽造することは現実的ではありません。