Web11: HTTP Cookie といくつかのセキュリティ問題

1. はじめに

Cookie、または HTTP Cookie、Web Cookie、ブラウザ Cookie は、Web サイトから送信され、ユーザーがこの Web サイトを閲覧するときにユーザーのブラウザに保存される小さなデータです。ユーザーが Web サイトをロードするたびに、ブラウザーは Web サーバーに Cookie を自動的に送信し、ユーザーの以前のアクションを Web サイトに通知します。

Cookie は、Web サイトがステータス情報 (ショッピング カート内の商品など) を記憶したり、リンク、ログイン、その週、月、年にアクセスしたページなどのユーザー アクティビティ (クリックを含む) を保存したりするのに役立つ信頼性の高いメカニズムとなるように設計されています。 ）。

Cookie はウイルスを媒介したり、コンピューターにマルウェアをインストールしたりすることはありませんが、トラッキング Cookie、特にサードパーティ Cookie の使用は、ユーザーの閲覧履歴から個人情報を特定する方法とみなされます。 Cookie は、パスワードや、ユーザーが HTML フォームに入力するコンテンツ (クレジット カード番号や個人の住所など) を保存できます。

ユーザーが初めて Web サイトにアクセスすると、Cookie が Web サーバーからブラウザに送信され、ユーザーのコンピュータに保存されます。その後、ユーザーが Web サイトに戻ると、Cookie に保存された情報により Web サイトはユーザーを認識します。

認証 Cookie は、ユーザーが Web サイトにログインしているかどうかを判断するために使用される一般的な方法です。このような仕組みがないと、Web サイトがユーザーに個人情報を送信するタイミングを把握することが困難になり、ユーザーに複数回のログインを強制することになります。認証 Cookie は非常に便利ですが、ハッカーが Cookie 内の機密データを読み取る機会を生み出し、それによってユーザーに損害を与える行為を実行します。

2. HTTP Cookie の概要

2.1.歴史

Cookie という用語は、コンピュータ プログラムによって送受信される不変のデータであるマジック Cookie という用語に由来しています。 Lou Montuli という名前のプログラマーは、1994 年に Web コミュニケーションでマジック クッキーを使用するというアイデアを思いつきました。当時、彼は Netscape Communications で MCI 用の電子商取引アプリケーションを開発するプロジェクトに携わっていました。 Cookie は、仮想ショッピング カートを構築する際のソリューションとして使用されており、MCI のサーバーが取引ステータスを保存する必要がなくなり、代わりにユーザーのコンピュータに保存されるようになりました。

Montuli は John Giannandrea とともに、Netscape Cookie の最初の仕様を作成しました。 1994 年 10 月 13 日にリリースされた Mosaic Netscape のバージョン 0.0beta は Cookie をサポートしていました。 Cookie の最初の使用 (ラボの外) では、Netscape の Web サイトを訪問した顧客が以前に訪問したことがあるかどうかがチェックされました。 Montuli は 1995 年に Cookie の特許を取得しました。また、Internet Explorer バージョン 2 (1995 年 10 月リリース) には Cookie の使用が組み込まれています。

この時代には Cookie の導入はまだ普及していませんでした。特に、Cookie はデフォルトで受け入れられ、ユーザーにはその存在が通知されません。一般の人が Cookie について知ったのは、1996 年 2 月 12 日にフィナンシャル タイムズに Cookie に関する記事が掲載されてからでした。それ以来、クッキー、特にクッキーに含まれる個人情報が大きな注目を集めるようになりました。クッキーは、1996 年と 1997 年の 2 回の米国連邦取引委員会の公聴会で議論されました。

正式な Cookie 仕様の最初の議論は 1995 年 4 月に始まりました。この作業を実行する目的で、インターネット エンジニアリング タスク フォース (IETF) 内の特別なグループが設立されました。最後に、この仕様は 1997 年 2 月にグループによって公開されました。この仕様では、サードパーティ Cookie がすべての人に受け入れられないか、少なくともデフォルトで有効になっていないと定義されていました。
2011 年 4 月に、実用化されている Cookie の標準仕様が文書RFC 6265で公開されました。

2.2.用語

セッションクッキー

セッション Cookie は、インメモリ Cookie または一時 Cookie とも呼ばれ、ユーザーが Web サイトにアクセスしている間の一時メモリ内にのみ存在します。 Cookie の作成時に有効期限または有効期間が設定されていない場合は、セッション Cookie が設定されます。通常、Web ブラウザは、ユーザーがブラウザを閉じるとセッション Cookie を自動的に削除します。

永続的な Cookie

永続的な Cookie はユーザーのセッションを延長します。永続 Cookie の Max-Age が 1 年に設定されている場合、その期間中、ユーザーが Web サイトにアクセスするたびに、Cookie に設定された初期値がサーバーに送信されます。ユーザーが最初に Web サイトをどのように訪問したかなど、重要な情報を記録するために使用できます。このため、永続的な Cookie はトラッキング Cookie とも呼ばれます。

安全なクッキー

セキュア Cookie は、HTTPS の使用時に有効になるセキュリティ属性で、クライアントからサーバーに転送されるときに Cookie が常に暗号化されることを保証し、情報の盗聴や漏洩を回避します。さらに、すべての Cookie はブラウザの同一生成元ポリシーに準拠する必要があります。

HTTP のみの Cookie

Cookie の HttpOnly 属性は、ほとんどのブラウザでサポートされています。 HttpOnly セッション Cookie は 1 つの HTTP (または HTTPS) リクエストでのみ使用されるため、JavaScript などの非 HTTP API によるアクセスが制限されます。この制限により、クロスサイト スクリプティング (XSS) の脆弱性による Cookie の盗難は軽減されますが、排除されるわけではありません。

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

ファーストパーティ Cookie は、ブラウザのアドレス バーに表示される同じドメイン (または同じドメイン内のサブドメイン) に属する Cookie です。サードパーティ Cookie は、ブラウザのアドレス バーに表示されるさまざまなドメインに属する Cookie です。 Web サイトにはサードパーティ ドメインのコンテンツ (バナー広告など) が含まれる場合があり、そこからユーザーの閲覧履歴を追跡できます。ほとんどのブラウザーのプライバシー設定は、サードパーティの追跡 Cookie をブロックします。

たとえば、ユーザーが Web サイトexample1.comにアクセスしたとします。この Web サイトには ad.foxytracking.com からの広告が含まれています。ロードされると、ad.foxytracking.com の Cookie が保存されます。次に、別の Web サイト (example2.com) にアクセスします。この Web サイトには、ad.foxytracking.com からの広告も含まれており、ad.foxytracking.com に属する Cookie も設定されます。最後に、これらの Cookie は両方とも、広告を読み込むとき、または Web サイトにアクセスするときに広告主に送信されます。広告主はこれらの Cookie を使用して、広告を含むすべての Web サイトでのユーザーの閲覧履歴を構築できます。

2014 年には、100 を超えるサードパーティ ドメインで読み取れる Cookie を設定する Web サイトがいくつかありました。平均して、Web サイトには約 10 個の Cookie が設定され、最大 Cookie 数は 800 を超えます。

スーパークッキー

スーパークッキーは、.com などのトップレベル ドメイン、または .co.uk などのパブリック サフィックスから生成される Cookie です。セキュリティ上の問題により、スーパークッキーがブラウザによってブロックされることが重要です。ブロックが解除されると、悪意のある Web サイトを制御する攻撃者がスーパークッキーを設定してユーザーのリクエストを偽装し、同じトップレベル ドメインまたはパブリック サフィックスを共有する他の Web サイトにリクエストを送信する可能性があります。たとえば、.com ドメインから発信されたスーパー Cookie は、Cookie が example.com から発信されたものでない場合でも、example.com へのリクエストに悪影響を与える可能性があります。偽装ログインやユーザー情報の変更に悪用される可能性があります。

ゾンビクッキー

ゾンビ Cookie は、ユーザーが削除した後に自動的に再作成される Cookie です。これは、Cookie のコンテンツを別の場所 (Flash コンテンツ ストア、HTML5 ストア、その他のクライアント側メカニズムなど) に保存するスクリプトによって行われます。

2.3.クッキーの構造

サイズが 4KB の Cookie には、次の 7 つの主要コンポーネントが含まれています。

1. 名前
2. 価値
3. 期限切れ（有効期限）
4. パス (Cookie が有効な場所へのパス、「/」は Cookie がどのパスでも有効であることを意味します)
5. ドメイン
6. 安全な
7. HTTPのみ

最初の 2 つのコンポーネント (名前と値) は必須です。

2.4.使用

セッション管理

Cookie を使用すると、複数の Web サイト訪問にわたってユーザー関連データを維持できます。 Cookie は、ユーザーが商品を閲覧中に選択した商品を保存するのに役立つ仮想ショッピング カートであるショッピング カートを作成するためのソリューションです。

現在のショッピング カート アプリケーションでは、カート内のアイテムのリストをクライアント側の Cookie に保存するのではなく、サーバー側のデータベースに保存することがよくあります。 Web サーバーは通常、セッション識別子 (一意のセッション ID) を含む Cookie を送信します。 Web ブラウザは、各ユーザーのショッピング リクエストとともにこのセッション ID を返します。

ユーザーが Web サイトにログインできるようにすることも、Cookie の応用例です。通常、最初のログイン中に、Web サーバーはセッション ID を含む Cookie をクライアントに送信します。ユーザーが情報を送信すると、Web アプリケーションがセッションを認証し、ユーザーがそのサービスを使用できるようにします。

Cookie は、迅速で便利なクライアント/サーバー対話メカニズムを提供します。 Cookie の利点の 1 つは、ユーザーのコンピュータ上にあるファイルにユーザー情報を保存することです。これにより、サーバーのストレージ容量と処理時間が大幅に削減されます。

パーソナライズされた

Cookie を使用すると、ユーザーが Web サイトにアクセスしたときにその個人情報を記憶し、そのユーザーが再度 Web サイトにアクセスするたびに、より関連性の高いコンテンツを表示することができます。

顕著な例は、amazon.com の書籍の推奨機能です。ユーザーが本をクリックすると、Amazon はユーザーが次にチェックすべき本を提案します。これらの提案は、ユーザーが以前に閲覧した書籍と購入することを選択した書籍に基づいています。

もう 1 つの例は、Google 検索の検索候補機能です。個人アカウントでログインして検索を実行すると、Google は「あなた専用」の候補を提供し、希望する結果が常にリストの先頭に表示されます。

モニター

トラッキング Cookie を使用すると、ユーザーの閲覧履歴を追跡できます。これは、Web サイトにリクエストを送信するコンピューターの IP アドレスを使用したり、HTTP リクエスト ヘッダーの Referrer フィールドに依存して実行することもできますが、Cookie を使用するとより正確になります。これは次のように行われます。

1. ユーザーが Web サイトにアクセスしても、このリクエストに Cookie が含まれていない場合、サーバーはユーザーがこの Web サイトに初めてアクセスするとみなします。サーバーはランダムな文字列を生成し、リクエストされた Web ページとともにそれを Cookie としてブラウザに送り返します。
2. この時点から、この Web サイト内の新しい Web ページがリクエストされるたびに、Cookie がブラウザによってサーバーに自動的に送信されます。サーバーは通常どおり、リクエストされた Web ページを返しますが、その Web ページの URL とアクセスはログ ファイルに保存されます。このログファイルに保存された情報を分析することで、その人の閲覧履歴、頻繁にアクセスするWebサイト、閲覧習慣などが明らかになります。

2.5.導入

Cookie はサーバーからブラウザに送信されるデータです。ユーザーが Web サイトにリクエストを送信するたびに、ブラウザーは内部のコンテンツを変更せずにそのリクエストをサーバーに送り返します。 Cookie は、JavaScript などのスクリプト言語によって設定することもできます。

各 Web ブラウザでは、4 KB ファイルに少なくとも 300 個の Cookie を保存でき、サーバーまたはドメインごとに少なくとも 20 個の Cookie を保存できます。

クッキーを設定する

Web サーバーとブラウザは HTTP (HyperText Transfer Protocol) 経由で相互に通信します。たとえば、ページ http://www.example.org/index.html にアクセスするには、ブラウザは次のような HTTP リクエストを送信してサーバーに接続します。

サーバーは、HTTP 応答と呼ばれる単純なテキスト パケットをブラウザに送信することで応答します。このパケットには、Cookie の内容を含む行が含まれる場合があります。

Set-Cookie は、ブラウザーに Cookie を保存し、今後サーバーへのリクエストがあるたびにサーバーに送信するように指示するフィールドです (Cookie の有効期限がまだ切れている場合)。たとえば、ブラウザは次のような HTTP リクエストを送信することで、http://www.example.org/spec.html にリクエストを送信します。

これは、同じサーバーに属する別のページへのリクエストです。この場合、サーバーはこのリクエストが前のリクエストに関連していることを理解し、リクエストされた Web ページをブラウザに送信し、場合によっては他の Cookie 値を追加して応答します。

Cookie の値は、HTTP 応答の Set-Cookie: name=value フィールドをブラウザに送信することで、サーバーによって変更できます。その後、ブラウザは古い Cookie の値をこの新しい値に置き換えます。

Cookie 値には、「,」、「;」を除く、印刷可能な任意の ASCII 文字を含めることができます。そしてホワイトスペース。また、名前と値を区切る文字である「=」文字を Cookie 名に含めることはできません。
クラム クッキーという用語は、クッキーの名前と値のペアを指すために使用されることがあります。

Cookie は、JavaScript または同様のスクリプト言語によって設定することもできます。 JavaScript では、cookie を設定するために document.cookie オブジェクトが使用されます。 HttpOnly 属性は、不正なスクリプトによる Cookie コンテンツの読み取りを防止する役割を果たします。

クッキーのプロパティ

サーバーは、名前と値のペアの他に、ドメイン、パス、有効期限、最大有効期間、セキュア、および HttpOnly など、他の多くの Cookie プロパティも設定できます。ブラウザはこれらの属性をサーバーに送信せず、名前と値のペアのみを送信します。これらの属性は、Cookie をいつ削除するか、Cookie をブロックするか、またはサーバーに Cookie を送信するかを決定するためにブラウザによって使用されます。

ドメインとパス

ドメインとパスによって Cookie の範囲が決まります。これらにより、ブラウザは Cookie をいつサーバーに送信するかを決定できるようになります。指定しない場合、デフォルトで、要求されたオブジェクトのドメインとパスが使用されます。ただし、ドメイン属性のない foo.com 用に設定された Cookie と、ドメイン foo.com 属性が設定された Cookie の間には違いがあります。最初のケースでは、foo.com へのリクエストがある場合にのみ Cookie が送信されます。後者の場合、Cookie は foo.com のすべてのサブドメインに送信されます。以下は、ユーザーがログインした後の Web サイトからの、docs.foo.com へのリクエストによる Set-Cookie ディレクティブの例です。

最初の Cookie LSID にはドメイン属性がなく、パスは /accounts です。ブラウザーは、要求されたページが docs.foo.com/accounts に含まれている場合にのみ Cookie を送信します。残りの 2 つの Cookie、HSID と SSID は、foo.com のサブドメインへのリクエストがある場合にサーバーに送り返されます。
トップドメインとそのサブドメインのみにCookieを設定することもできます。セキュリティ上の理由から、 www.bar.comからwww.foo.comに Cookie を設定することは許可されません。

有効期限と最大有効期間

Expires 属性はブラウザに Cookie をいつ削除するかを指示します。 Expires の日付は「Wdy, DD Mon YYYY HH:MM:SS GMT」のようになります。 Max-Age は、Cookie の有効期限を示すためにも使用されます。次の例を考えてみましょう。

最初の Cookie の有効期限は 2013 年 1 月 15 日に設定されており、有効期限が切れるとブラウザによって使用されます。 2 番目の Cookie made_write_conn には有効期限がなく、セッション Cookie として使用され、ブラウザがオフになると削除されます。 3 番目の Cookie reg_fb_gate は、有効期限が過ぎているため、すぐに削除されます。

安全かつ HttpOnly

Secure プロパティと HttpOnly プロパティは null ですが、その代わりに、それらの存在は Secure ベースと HttpOnly ベースが適用されていることを示します。

Secure 属性は、暗号化された接続内での Cookie の送信を維持します。 Web サーバーが非セキュア接続からセキュア属性を使用して Cookie を設定した場合でも、その Cookie は中間者攻撃によって傍受される可能性があります。

HttpOnly 属性は、JavaScript などの HTTP (または HTTPS) 以外の接続を通じて Cookie を公開しないようブラウザに指示するため、クロスサイト スクリプティング (XSS) の脆弱性を悪用して Cookie を取得することが困難になります。

3. Cookie 使用時のセキュリティ上の問題

Web サイトがセッション ID を使用してユーザーのセッションを識別すると、攻撃者が Cookie を盗んでユーザーになりすます可能性があります。一般的な Cookie 盗難のシナリオをいくつか示します。

盗聴

ネットワーク内のトラフィックは、第三者 (受信者と送信者以外) によって傍受され、読み取られる可能性があります。このトラフィックには Cookie が含まれています。送信が暗号化されていない場合、攻撃者は Cookie に含まれる機密情報を読み取ることができます。そして、攻撃者はこの情報を利用して、ユーザーになりすまして銀行取引などの危険な行為を実行し���す。

この問題は、ユーザーのコンピュータとサーバーの間で安全なプロトコル、つまり HTTPS プロトコルを使用することで解決できます。サーバーは、Cookie を設定するときに Secure フラグを使用できます。 Cookie は、SSL 接続などの暗号化されたチャネル経由でのみ送信されます。

クロスサイトスクリプティング

Javascript などのスクリプト言語では、Cookie の値を読み取り、任意のサーバーに送信することができます。

Web サイトにクロスサイト スクリプティング エラーがあるとすると、ハッカーは次のような悪意のあるコードを挿入する可能性があります。

被害者が上記のリンクをクリックすると、ブラウザは onclick 属性のスクリプトを実行し、被害者の Cookie をサーバー Attacker.com に送信します。

クロスサイト スクリプティングは、Web サイトの一般的な脆弱性の 1 つです (OWASP によると、2013 年の最も一般的な脆弱性トップ 10 で 3 位にランクされています)。

この脆弱性のリスクは、Cookie に HttpOnly フラグを設定することで制限できます。その時点では、スクリプト言語では Cookie にアクセスできません。

クロスサイトリクエスト偽造

CSRF (クロスサイト リクエスト フォージェリ) またはワンクリック攻撃は、Web サイトの脆弱性を悪用する方法であり、被害者 (Web サイトによって許可されているユーザー) が知らないうちに不正なコマンドを実行します。

CSRF は、被害者のブラウザを騙して http リクエストを Web アプリケーションに送信させます。被害者のセッションが期限切れになっていない場合、上記のリクエストは被害者の認証権限を使用して行われます。

たとえば、被害者のボブは、特定の銀行 X の Web サイトで取引を行っているとします。攻撃者はフレッドです。この男は、口座 A から口座 B に送金したいときに銀行 X の Web サイトがどのように機能するかを知っています。

http://bank.example.com/withdraw?account=accountA&amount=100&for=accountB

彼はボブに悪意のあるメッセージを送信するでしょう。

銀行 X がユーザー認証情報を Cookie に保存し、ボブが上記のリンクをクリックすると、ボブのお金がフレッドに送金されます。

このリスクを制限するために、Cookie に Expires パラメータを設定できます。

4. 結論

Cookie は現在、ほとんどの Web アプリケーションで使用されています。また、ユーザーに重大な影響を与える潜在的なリスクも含まれています。したがって、開発者側では、Cookie を明確に理解し、アプリケーションをハッカー攻撃に対してより安全にするために必要なパラメーターの設定方法を知る必要があります。