 |
| HTTP |
|---|
| 主要項目 |
| リクエストメソッド |
| ヘッダーフィールド |
| ステータスコード |
| 認証方式 |
| 脆弱性およびそれを利用した攻撃手法 |
HTTP cookie（エイチティーティーピークッキー）は、ユーザがウェブサイトをブラウジングしている間にウェブサーバによって作成され、ユーザのウェブブラウザによってユーザのコンピュータやその他のデバイスに保存されるマジッククッキー（小さなデータのブロック）である。単にクッキー（cookie）、あるいはウェブクッキー、ブラウザクッキーとも表記される。HTTP cookieは、RFC 6265などで定義されており、ステートレスなHTTPプロトコルにおいて、ウェブサーバとウェブブラウザ間でログイン状態などを管理するための仕組み、およびその情報のことを指す。
HTTPは元来ハイパーテキストにおいて単にファイル転送を行うために開発された。そのため、同じURLへのアクセスならその状況によらず同一の情報源を提供すること、つまり「ステートレスなプロトコル」が前提となっている。例えば、動的なコンテンツ生成の仕組みとしてフォームが導入されているが、これは要求に直接対応する応答だけに影響をおよぼす。言い換えると同じ瞬間に同じ内容の要求を行っていれば、そのクライアントが以前にどのような通信を行っていても区別されない。HTTPはその意味で現在においてもステートレスなプロトコルである。
一方、World Wide Webが普及するにつれ、「ユーザーのログイン状態を維持したい」「オンラインストアのショッピングカートに追加された商品などの情報を保存したい」など、状況によって異なる内容のページを提供したいというニーズが生まれた。IPアドレスによる識別や、URLにその状態を表現しするなどの方法があるが、プライバシーやセキュリティの観点から容易に解決できない欠点を抱えていた。
そこで、1994年にネットスケープコミュニケーションズ社によってクッキー が提案・実装された。クッキーでは次のようにサーバとクライアント間の状態を管理する。
この仕組みによって、ステートレスなプロトコルであるHTTP上でステートフルなサービスを実現する。ここで注意すべき点は、一度設定されたクッキーは、条件を満たす限り何度でも要求に組み込まれるという点である。この仕組みによって、ショッピングカートの維持、ログイン認証、ユーザー設定の保存、さらには行動トラッキングといったウェブ上で不可欠な機能が実現されている。
クッキーは以下のコンポーネントで構成される。
「クッキー」という言葉は、ウェブブラウザのプログラマであるルー・モントゥリによって作られた。これは、UNIXプログラマが使用する、プログラムが受信して変更せずに送り返すデータのパケットである「マジッククッキー」という言葉に由来している。
クッキーは毎回送られるものであり、またHTTPヘッダの一部なのでASCII文字列になっている必要がある。そのためクッキーでデータを直接扱うよりも、セッションIDを実装する手段として使うことが多い。この場合、実際のデータは、セッションIDをキーとしてサーバが保持することになる。
例えば特定のページの表示回数を、ウェブページ上に表示したいときには、おおむね次のようなやりとりが行われる。
クッキーの最も代表的な用途は、ショッピングサイトにおけるカートやログイン状態の管理などに見られる「セッション管理」である。今日ではショッピングカートの中身は、クライアント側のクッキーではなくサーバ上のデータベースに保存されることが多い。クッキーには「どのユーザーが、どのカートに紐づいているか」を示すセッションIDだけを記録し、実際のデータはサーバ側で管理するという方法が広く使われている。
例として、MediaWikiにおけるクッキーの使用をあげる。
MediaWikiソフトウェアでは、ログイン情報をクッキーで実現している。その方法はおおむね次のようである。
ウェブサイトの運営者やインターネット広告配信業者が、ユーザーの詳細なアクセス履歴を取得・追跡するためにクッキーを使用することがある。これにより収集されたデータは、販売やターゲティング広告に利用されることがある。また、ウェブサイト運営者やインターネット広告配信業者などがIPアドレスによらないクライアントの識別を可能にするために用いることがある。ただし、ユーザーが意図しない場所で行動が記録されるため、プライバシー侵害の懸念が強く、近年では世界中で法的な規制が進んでいる。
クッキーはユーザの好みに基づいてパーソナライズするためにも使用される。ユーザーが選択した「ダークモード表示」「言語設定」「1ページあたりの表示件数」などの設定値がクッキーにエンコードされ、ブラウザに保存される。次にサイトを訪れた際にも、サーバがそのクッキーを読み取ることで、最初からユーザー好みのレイアウトでページを表示することができる。
クッキーを設定する際、どの要求に対してクッキー情報を送り返すのか、URLの範囲を指定する。規定値は、クッキーを設定したサーバに対するすべての要求であり、対象を広げることも狭めることもできる。ただし広げる場合でも、トップレベルドメインより狭い範囲でなければならない。
またクッキーの有効期限は、通常はブラウザを終了するまでだが、指定した期限まではブラウザを再度起動しても保持されるように設定することができる。有効期限の情報も、サーバからブラウザにクッキー情報を送信する段階で付加され、無期限という設定は出来ない。遥か未来を指定することで半永久的に有効にすることも可能だが、ブラウザやサーバが2038年問題で不具合を起こす場合があることから、2038年1月19日3時14分07秒(UTC)以降の時間を期限とすることはあまりない。
セッションクッキー（インメモリクッキー、一時クッキー、非永続的クッキーとも呼ばれる）は、ユーザがウェブサイトをナビゲートしている間のみ一時メモリに存在する。 セッションクッキーは、ユーザがウェブブラウザを閉じたときに期限切れになるか削除される。セッションクッキーは、有効期限が割り当てられていないことによってブラウザに識別される。
永続的クッキーは、特定の日付または特定の期間の後に期限切れになる。作成者によって設定された永続的クッキーの寿命の間、ユーザがそのクッキーが属するウェブサイトにアクセスするたびに、または別のウェブサイトからそのウェブサイトに属するリソース（広告など）を表示するたびに、その情報はサーバに送信される。
このため、永続的クッキーはトラッキングクッキーと呼ばれることもある。これは、広告主が長期間にわたってユーザのウェブブラウジングの習慣に関する情報を記録するために使用できるためである。永続的クッキーは、ユーザをウェブサイト上のアカウントにログインさせたままにし、訪問のたびにログイン認証情報を再入力しなくて済むようにするためにも使用される。
セキュアクッキーは、暗号化された接続（すなわちHTTPS）を介してのみ送信できる。暗号化されていない接続（すなわちHTTP）を介して送信することはできない。これにより、盗聴によるクッキーの盗難に対してより安全になる。クッキーに `Secure` フラグを追加することで安全に設定できる。
HttpOnlyクッキーは、JavaScriptなどのクライアント側APIからはアクセスできない。この制限により、クロスサイトスクリプティング（XSS）によるクッキー盗難の脅威が排除される。ただし、クッキーはクロスサイトトレーシング（XST）およびクロスサイトリクエストフォージェリ（CSRF）攻撃に対しては依然として脆弱である。クッキーに `HttpOnly` フラグを追加することで設定できる。
2016年にGoogle Chromeバージョン51は、`Strict`、`Lax`、または `None` の可能な値を持つ属性 `SameSite` を持つ新しい種類のクッキーを導入した。属性 `SameSite=Strict` の場合、ブラウザはオリジンドメインと同じターゲットドメインにのみクッキーを送信する。これにより、クロスサイトリクエストフォージェリ（CSRF）攻撃を効果的に軽減できる。`SameSite=Lax` の場合、ターゲットドメインがオリジンドメインと異なる場合でもクッキーをリクエストとともに送信するが、GETなどの安全なリクエストのみであり、サードパーティークッキーとしては送信されない。`SameSite=None` の場合はサードパーティー（クロスサイト）クッキーを許可するが、多くのブラウザでは `SameSite=None` のクッキーにSecure属性を要求する。
スーパークッキーとは、トップレベルドメイン（`.com` など）またはパブリックサフィックス（`.co.uk` など）をオリジンとするクッキーである。対照的に、通常のクッキーは `example.com` などの特定のドメイン名をオリジンとする。 パブリックサフィックスリストは、スーパークッキーがもたらすリスクを軽減するのに役立つ。スーパークッキーという用語は、HTTPクッキーに依存しないトラッキング技術にも使用される。
ゾンビクッキーとは、ウェブサーバによって訪問者のコンピュータ等の隠し場所に配置され、元のクッキーが削除された後に自動的にHTTPクッキーとして再作成されるデータとコードのことである。
クッキーは、HTML DOMの一部としてアクセスできる。JavaScriptをはじめとする、クライアント側のスクリプトは、クッキーを操作することができる。ただし後述のようにクッキーには有効範囲が設定されており、そのURLにおいて有効なクッキーだけがアクセス対象となる。
現在使われているウェブブラウザのほとんどはクッキーの送受信が可能であり、初期状態でクッキーを送受信する設定になっている。しかし、クッキーの送受信をするしない、またそのクッキーの内容は、ウェブ閲覧者の自由に置かれるべきものであるので、ブラウザの初期設定でそれらを操作できるようになっている。すなわち、クッキーの送受信を停止する、クッキーの内容を確認する、クッキーを消去するといった機能がウェブブラウザに備わっている。
クッキーを運用する際、クロスサイトスクリプティングやセッションハイジャックのセキュリティ上のリスクが存在する。Webサイトの管理者は、推奨されている対策を行うことが重要である。
クッキー情報を不正に得る手段としてクロスサイトスクリプティングが挙げられる。クッキーには有効範囲が設定されているが、その有効範囲内にクロスサイトスクリプティング脆弱性を持つページがある場合、JavaScript等を併用して、他のサーバにクッキー情報を（URLの一部に組み込むなどして）送信させることが可能になる。対策としては、クッキーに HttpOnly 属性を付与し、JavaScriptからのアクセスを完全に遮断する方法がある。
クッキーでセッション管理を行う場合、もし第三者がセッションIDを知ることができれば、そのIDを名乗ることで本来のユーザになりすますことができる。このような「なりすまし」行為をセッションハイジャックと呼ぶ。
例として、以下のような通信を行うシステムがあるとする。
もし第三者が盗聴や中間者攻撃によりセッションIDを知ることができれば、そのセッションが有効な間だけとはいえ、1～2を飛ばして3から開始することができる。すなわち、パスワードを知らなくても「なりすまし」が可能となる。
第三者のクッキー情報を知る方法のひとつは盗聴である。盗聴を防ぐ対策として、Webサイト全体をHTTPS（常時SSL化）にし、クッキーに Secure 属性を付与することで、暗号化通信のときだけクッキーを送信するように制限する方法がある。
ユーザーがログインした状態で、悪意のあるリクエストを送信させるためのWebサイトにアクセスさせることで、本人の意図しない操作（送金など）をさせる攻撃である。属性をStrictやLaxに設定することで、意図しない別サイトからのリクエストによるセッションの悪用を防ぐ。
攻撃者が事前に用意したクッキー内のセッションIDを強制的に利用者に使わせることで、ログイン後のアカウントを乗っ取る攻撃である。クッキー内のセッションIDをリクエストごとに新しいものを生成することで、対策することができる。
クッキーは本来、ショッピングカートの維持などウェブサイトを便利にするための技術だが、ユーザーの行動を追跡（トラッキング）するためにも悪用・活用される。この手法は、アドネットワーク（Google AdSenseなど）を利用するウェブ広告業者によってよく用いられている。
インターネット広告の配信において、バナー広告は、業者のサーバ（サードパーティー）へのリンクを介して画像を取得する形式が一般的である。クッキーはHTMLに限らず、画像にも設定することができるため、クッキーは画像ファイルにも設定できるため、広告業者は自社の広告が埋め込まれたあらゆるウェブサイトを横断して、同一ユーザーのブラウジング履歴（アクセス履歴）を長期的に記録・統合できる。ユーザのアクセス履歴を追跡するという意味からトラッキング・クッキーと呼ばれたり、メインのHTMLではなく画像の提供元が設定するという意味からサードパーティークッキーと呼ばれたりする。これらは、行動ターゲティング広告やコンテンツ連動型広告および検索連動型広告などに活用され、時にフィルターバブルの原因ともなっている。
ユーザーの知らないところで詳細な行動履歴が収集・関連付けられるため、これをプライバシーの権利の侵害と捉える懸念が世界中で高まった。多くのクライアント向けセキュリティ対策ソフトの多くは、トラッキング・クッキーを検出・除去する機能を備えている。また、サードパーティークッキーに対する批判から、近年ではプライバシーを保護しつつ広告を配信する代替技術（Federated Learning of Cohortsなどのプライバシーサンドボックス技術）への移行が進んでいる。
通常のクッキーが拒否・削除されるようになったため、クッキーを用いずにユーザーを追跡する代替技術や、より巧妙な追跡手法が登場している。一般的には、サードパーティーのGoogle Analytics等に見られるIPアドレス・ユーザーエージェント・ウェブビーコン・HTTPリファラなどを利用してアクセス解析をおこないウェブ トラッキングをする方法である。
フィンガープリントと呼ばれる方法もある。これは、JavaScriptおよびHTML5（WebGL、canvas要素、Webフォントなど）を利用し、ブラウザの設定や端末の固有構成から端末の識別子を生成して識別する。
Adobe Flashで使われるLocal Shared Object（フラッシュ・クッキーとも呼ばれる）やSilverlightの保存領域、HTML5（インストール済みのWebフォントなど）、Faviconなどを利用してクッキーと同様のトラッキングをすることが可能である。ユーザには非常に気づかれにくい上に、クッキーが拒否あるいは削除されてもそれらの情報から容易に生成・復元することもできる。これらを総称して、ゾンビクッキーやスーパークッキーと呼ばれる。
これらの技術への対策には、サードパーティー製ブラウザアドオンの使用とJavaScriptの制御や無効化、ウェブブラウザのプライバシーモードやCCleanerを用いたキャッシュおよび閲覧履歴の完全な削除などの対策が必要である。なお、匿名ブラウザであるTor BrowserやOnion Browserに関しては、いまのところウェブトラッキングやキャンバス・フィンガープリンティングなどの回避に有効である。
トラッキング技術によるプライバシー侵害に対し、国内外の法律で規制が強化されている。
サードパーティークッキーによる、個人のブラウジング履歴の長期的な記録は、潜在的なプライバシーの懸念であり、2011年には欧州および米国の議員が行動を起こすきっかけとなった。2011年以降、欧州連合加盟国を対象とするすべてのウェブサイトにおいて、サイト運営に不可欠ではないクッキー（トラッキング目的など）をユーザーのデバイスに保存する前に、事前の同意を得るオプトインが義務付けられた。これにより、欧州のサイトにアクセスすると「クッキーの受け入れを許可するか」を選択するポップアップが広く表示されるようになった。
2018年施行されたEU一般データ保護規則（GDPR）により、クッキーIDやIPアドレス自体が個人データと明確に定義された。ユーザーはデータポータビリティ権や消去権が保障されており、違反した企業には莫大な制裁金が科される。
2019年にリクナビの運営会社が目的を十分に説明しないまま、クッキーで得られた情報を外部に販売した問題が発覚したことを受けて、2022年4月1日施行の個人情報の保護に関する法律によって、クッキーの活用に規制がかけられるようになった。
2023年6月施行の改正電気通信事業法（第27条の12）において、Webサイトやアプリからクッキーなどを外部の第三者へ送信させる際、その送信先や目的などを利用者に通知・公表することを義務付ける規制（外部送信規律）が義務付けられた。
1994年6月、ネットスケープコミュニケーションズの従業員であり、MCI向けの電子商取引アプリケーションを開発していたルー・モントゥリが、すでにコンピューティングで使用されていたマジッククッキーをウェブ通信で使用することを提唱。ヴィントン・サーフとジョン・クレンシンは、ネットスケープコミュニケーションズとの技術的な話し合いでMCIを代表していた。MCIは、自社のサーバが部分的なトランザクションの状態を保持する必要がないようにしたかったため、ネットスケープに各ユーザのコンピュータにその状態を保存する方法を見つけるように依頼した。クッキーは、仮想ショッピングカートを確実に実装するという問題に対する解決策を提供した。
モントゥリはジョン・ジャナンドレアと共に、同年最初のネットスケープのクッキー仕様を書いた。1994年10月13日にリリースされたMosaic Netscapeのバージョン0.9betaはクッキーをサポートしていた。ラボ外でのクッキーの最初の使用例は、Netscapeのウェブサイトへの訪問者がすでにサイトを訪問したことがあるかどうかを確認することであった。モントゥリは1995年にクッキー技術の特許を出願し、1998年に付与された。クッキーのサポートは、1995年10月にリリースされたInternet Explorerバージョン2に統合された。
当時、クッキーの導入は一般には広く知られていなかった。特に、クッキーはデフォルトで受け入れられており、ユーザにはその存在が通知されていなかった。1996年2月12日にフィナンシャル・タイムズがクッキーに関する記事を掲載した後、一般大衆はクッキーについて知ることとなった。同年、クッキーは特にプライバシーへの潜在的な影響のためにメディアから多くの注目を集めた。クッキーは1996年と1997年の2回の米国連邦取引委員会の公聴会で議論された。
正式なクッキー仕様の開発はすでに進行中であった。特に、正式な仕様に関する最初の議論は1995年4月にwww-talkメーリングリストで始まっていた。IETF内に特別なワーキンググループが結成された。ブライアン・ベーレンドルフとデビッド・クリストルは、HTTPトランザクションに状態を導入するため代替案を提案した。しかし、クリストル自身とルー・モントゥリが率いるグループはすぐに、Netscapeの仕様を出発点として使用することを決定した。1996年2月、ワーキンググループはサードパーティークッキーを重大なプライバシーの脅威として特定した。同グループによって作成された仕様は、最終的に1997年2月にRFC 2109として公開された。そこでは、サードパーティークッキーは全く許可されないか、少なくともデフォルトでは有効にされないことが指定されていた。この時期、広告会社はすでにサードパーティークッキーを使用していた。RFC 2109のサードパーティークッキーに関する推奨事項は、NetscapeやInternet Explorerでは従われなかった。RFC 2109は2000年10月にRFC 2965に置き換えられた。RFC 2965は `Set-Cookie2` HTTPヘッダフィールドを追加した。しかし `Set-Cookie2` はめったに使用されず、現実世界で使用されるクッキーの決定的な仕様として書かれたRFC 6265で2011年4月に非推奨となった。最新のブラウザは `Set-Cookie2` ヘッダフィールドを認識しない。
その後クッキーは1997年にRFC 2109で初めて標準化され、2000年のRFC 2965、2011年のRFC 6265で更新された。2007年現在ほとんどのウェブサーバ、ウェブブラウザで利用可能である。
前述の通り、HTTP Cookie には幾つか仕様があるが、IETFの標準化した RFC 2109 や RFC 2965 は、ネットスケープ仕様とExpires属性からMax-Age属性への変更等互換性がないため、実際のウェブサイトではほとんど使われていない。一方で、Expires属性等で用いられる日付形式は仕様外の記述が氾濫しているうえ、セキュリティ上の理由からhttponly属性やsecure属性等が事実上追加されており、長らく文書の存在しない状態が続いていたが、RFC 6265 はこれらの問題を解消することを意図して制定されている。
2016年頃から、RFC 6265の改訂作業が行われている。クッキープレフィックスSameSite属性の追加などが行われる予定で、すでにウェブブラウザでの実装も並行して進められている。
Expires属性などが定義され、長年デファクトスタンダード（業界標準）となった。Max-Age属性が導入されたほか、この時点でサードパーティークッキーがプライバシーの脅威として特定された。httponly属性やsecure属性などが事実上追加され、正式に標準化された。__Secure-と__Host-）などが追加された。{{cite news}}: |access-date=を指定する場合、|url=も指定してください。 (説明) | この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 |
