Cookie
最初のローカルストレージ。
Cookieの登場以前、サーバーはネットワークの要求が同じユーザーによって行われたかどうかを判断できず。
このを解決するために、Cookieが登場。
サイズはわずか4kb、プレーンテキストファイルであり、HTTPリクエストが開始されるたびにCookieが送信。
正常に作成されると、名前は変更不可。
Cookieはドメイン名をまたぐことはできない。
つまり、ドメインaとドメインbのCookieを共有することはできない。プライバシーとセキュリティにとって非常に重要。
他のサイトからのCookieの不正な取得を防ぐことができる。
各ドメインでCookieの数は20を超えてはならず、各Cookieのサイズは4kbを超えてはならない。
セキュリティ上の問題もあり、Cookieが傍受された場合
セッションのすべての情報を取得可能。
暗号化されていても役に立たない。
Cookieの存在を気にしなくても転送され、応じた処理がなされる。
新しいページがリクエストされるとCookieを送信。
最も一般的な利用は、cookieとセッションの組み合わせ。
sessionIdをcookieに保存し、各リクエストはsessionIdを運ぶ。
サーバーはリクエストを開始したユーザーを認識し、情報に対応して応答します。
ログイン時の本人認証にはクッキーとセッションの両方を利用可能
最近はこの本人認証だけでなく、スマホでの二段階認証、二要素認証などがどんどん普及中。
ページのクリック数をカウントするためにも使用可能。
クッキーフィールドと機能
サーバーは、Set-Cookie応答ヘッダーを使用してCookie情報を構成。
Cookieには、expires、domain、path、secure、HttpOnlyの5つの属性値が含まれる。
expiresはCookieの有効期限。
domainはドメイン名
pathはパス。
ドメインとパスを合わせて、CookieにアクセスできるURLを制限。
secureは、セキュリティが確保された状態でのみCookieを送信できることを可能に。
HttpOnlyは、Cookieがサーバーからのみアクセス可能でjsからはアクセスできない。
クッキーの名前
Cookieの値
認証Cookieの場合、値にはWebサーバーから提供されたアクセストークンが含まれる。
クッキーのサイズ
パス:Cookieにアクセスできるページのパス。
たとえば、ドメインがexample.comでパスが/testの場合
/testパスの下のページのみがこのCookieを読み取ることが可能。
Secure
HTTPSセキュリティプロトコルを使用してCookieを送信するかどうかを指定。
HTTPSセキュリティプロトコルを使用すると、ブラウザとサーバー間の転送中にCookieが盗まれたり改ざんされたりするのを防ぐことが可能。
この方法は、Webサイトの身元認証にも使用できる。
HTTPS接続の確立段階で、ブラウザはWebサイトのSSL証明書の有効性をチェック。
ただし、自己署名証明書を使用しているなど、無効なSSL証明書が検出された場合がある。
ブラウザーはユーザーの接続要求をすぐに終了せず、セキュリティメッセージを表示。引き続きサイトにアクセスするか選択。
ドメイン
Cookieにアクセスできるドメイン名
Cookieメカニズムは厳密な同一生成元ポリシーには従わない。
サブドメインが親ドメインのCookieを設定または取得可能。
Cookieの特性は、シングルサインオンを実装する場合に非常に便利。
しかし、攻撃されるリスクも増大。
たとえば、
攻撃者はこれを使用して同じセッションIDを使用することで利用者になりすます。セッションフィクセーションを行える。
対応として、
ブラウザはDomain属性の国や地域のトップレベルドメインに登録されている.org、.com、セカンドレベルドメイン名などのgTLDの設定を禁止。攻撃の範囲を狭める。
有効ではあるが、絶対ではない方法。
HTTP
スクリプトを介してCookieにアクセスできるかどうかを設定するためのHTTPOnly属性が含まれる。
デフォルトはアクセス可能。
クライアント側でjsコードを使用してhttpOnlyタイプのCookieを設定することはできない。
サーバー側でのみ設定可能。
クライアント側のスクリプトがdocument.cookie属性を介してCookieにアクセスするのを防ぐために使用。
クロスサイトスクリプティングによってCookieが盗まれたり改ざんされたりするのを防ぐのに役立つ。
HTTPOnlyのアプリケーションにはまだ制限があります.
一部のブラウザーでは、クライアント側スクリプトによるCookieの読み取りを禁止できますが、書き込み操作は許可される。
ほとんどのブラウザーでは、XMLHTTPオブジェクトを介したHTTPレスポンスのSet-Cookieヘッダーの読み取りが引き続き許可される。
Expires/Max-size
Cookieのタイムアウト期間。
値が設定されている場合、時間になるとCookieは無効。
設定されていない場合、デフォルト値はSession。
Cookieがセッションとともに無効になることを意味。
ブラウザーが閉じられるとタブごとではなく全体で期限切れになる。
LocalStorage
LocalStorageはHTML5で新しく導入された機能。
保存する情報が大きすぎて、Cookieでは足りない場合がある。
LocalStorageが役立つ。自分でクリーンアップしない限り永久保存され、ページを更新したり閉じたりしても消えない。
削除する時はブラウザーのキャッシュ削除などから可能。
フロントエンドで利用できるのみ、サーバへデータ送信しない。
ブラウザがプライベートモードに設定されている場合、LocalStorageを読み取ることが出来ない。
同一生成元ポリシーによって制限。ポート、プロトコル、ホストアドレスのいずれかが異なる場合、アクセス出来ない。
サイズ
LocalStorageのサイズは通常5MBとCookieより大幅に増加。より多くの情報を保存できる。
すべてのHTTPリクエストで送信されるCookieとは異なり、データ自体はブラウザにのみ保存。
使用例
ブラウザーゲーム、スキンを変更する機能があるサイト、LocalStorageにゲームデータ、スキン情報を保存しておくことが可能。
Webサイトでのユーザーの閲覧情報もLocalStorageに保存可能。
頻繁に変更されることのない個人情報もLocalStorageに保存される可能性がある。
JSON Web Token（JWT）のログイン情報の保存として使われることもあるが、セキュリティとして一長一短。
localStorage.getItem('key')
localStorage.setItem('key','value')
localStorage.removeItem('key')
localStorage.clear()
SessionStorage
SessionStorageとLocalStorageはどちらもHTML5で提案。
SessionStorageは同じウィンドウまたはタブページのデータを一時的に保存するために使用。
ページを更新しても削除されず、ページを閉じると削除。
LocalStorageとの違い
SessionStorageとLocalStorageはどちらもデータをローカルに保存。
SessionStorageにも同じ生成元ポリシーの制限がある。
より厳しい制限があり、SessionStorageは同じブラウザの同じウィンドウでのみ共有可能。
クローラーはLocalStorageもSessionStorageもクロールできない。
使用例
SessionStorageは時間に厳密。
Webサイトのユーザーのログイン情報や、一時的な閲覧記録を保存するために使用。
ウェブサイトを閉じると、この情報も削除。
sessionStorage.getItem('key')
sessionStorage.setItem('key','value')
sessionStorage.removeItem('key')
sessionStorage.clear()
