HTTPプロトコルでは、状態を保持しないストートレスな通信ですので、情報連携する際は、様々な方法が用意されています。
formのhiddenパラメータを使う。
formのhiddenパラメータを使って情報を別画面に受け渡すことができます。
メリット
- セッション管理をする必要がないのでモードレスの子画面の実装と相性が良い
- 第三者に対しては堅牢です。
デメリット
- 「フォームのHTML」や「データ通信量」が肥大化する。
- 利用者自身では、プロキシツールを使うことで簡単に内容を改ざんできてしまいますので、ログイン認証の際の利用には向きません。(使う場合は暗号化も検討する。)
用途
- モードレスの子画面を実装する場合
- 利用者自身によっても、書き換えられたら困るようなログイン認証や金銭が関わるような処理以外では、ほぼ第一候補となりえます。
セッション変数を使う。
メリット
クッキーよりも、実装は簡単。
デメリット
- セッションごとにサーバーのメモリを使うことになるので利用者数によってメモリが足りなくなる。
- セッションIDの固定化攻撃に弱い。
用途
ログイン認証の際の受け渡しに使う。
クッキーを使う。(セッション管理とあわせて使われる。)
「名前=変数」という情報の組み合わせをブラウザで保持するもの。一度これを覚えたブラウザは再度そのサイトにアクセスした場合は、覚えたクッキー値を再度送信します。
特徴
- クッキーで保持できるデータの個数や長さには制限がある。
- 本人が書き換えることができるので、機密情報保持には向かない。
メリット
デメリット
・セッションIDの固定化攻撃に弱い。
用途
少量のデータを覚えておくためには使われるが、機密情報等のアプリケーションのデータを保持する目的では使われない。
具体的には、「セッションID」を保持しておくために使われたりします。
なお、セッションIDが一致しているとなりすましも可能なため、十分な桁数の乱数をセッションIDとします。(というか、Javaとか、.NET、PHPの言語で開発されている場合は、自作ではなく必ず標準ライブラリでセッションIDを用意するようにしましょう。世界の研究者が脆弱性についての研究をしたアルゴリズムで生成されているためツールで作るのが安全です。)
クッキーとは?
クライアントのブラウザ側に保存されるテキストデータのことです。(ちなみにセッションはサーバ側で保管されます。)
ブラウザはサーバーから受けたクッキー情報をサーバーのドメインに紐づけて保存します。次の同じドメインへのアクセス時にクッキー情報を付与してアクセスするので複数のリクエスト間で共有したい「状態」をブラウザ側に保管する仕組みになります。
クッキーのデータ構造
キーと値のペアの集合になっています。
セキュリティ上の制約
自分で発行したクッキーにしかアクセスできない。
発行元のホスト情報が記録されていて、それ以外のホストからはアクセスできないようになっています。
物理的な制限
- 一つのPCに保存できるクッキーの数は、300個まで
- 1個のクッキーのサイズは、4Kバイトまで
- サーバー、ドメインごとに20個まで
クライアントでオフにできる。
クライアントのブラウザでクッキーの利用自体オフにできます。
HTTPヘッダにより送信される。
通信傍受の危険性があるので、非常に危険です。
実務では?
まず、クッキーにパスワードや、クレジット情報等の貴重な情報を保持させる実装にはしないです。
クッキーをブラウザが無効化していた場合は?
「URLリライティング」という機能を使い、URLにセッションIDを付加することで対応します。
Ruby on Railsにおけるクッキー
Ruby on Railsでは、クッキーとセッションは明確に紐づいています。クッキーによってやりとりされるセッションIDをキーにセッションは保管されています。(デフォルトのセッション情報の保管場所がRailsではクッキーになっています。)
なので、ブラウザ側で保持されるクッキーを削除すればRailsで作られたアプリにアクセスする際は同一セッションとみなされなくなります。
この記事へのコメントはありません。