CORPORATE

技術情報

知らないと危険！Cookieのセキュリティリスクと対策

この記事は「GMOインターネットグループ Advent Calendar 2024」19日目の記事です。

こんにちは、GMO NIKKOの横内です。普段はRuby on Railsを使った開発やプロダクトの脆弱性診断などセキュリティ関連の業務をしています。今回はWebブラウザで広く利用されているCookieの脆弱性について書いていきたいと思います。

はじめに

今回この記事を書こうと思った経緯としては、最近の業務でCookieについて理解を深める機会がありそれを共有しようと思ったからです。Cookieは普段あまり意識することなく使用していますが、適切な設定を行わなければ容易に脆弱性になりうることを再確認し、今回ブログにて共有しようと思った次第です。

Cookieの基礎知識

Cookieは、ウェブサイトがユーザーのブラウザに保存する小さなテキストファイルで、ユーザーの情報や設定を保持するために使用されます。具体的には、ユーザーがウェブサイトを訪問するたびに、ブラウザは対応するCookieをサーバーに送信し、ユーザーの状態を管理します。CookieはステートレスなHTTPプロトコルの性質上、ユーザーのセッション情報や個別の設定を維持するための重要な役割を果たします。

Cookieは「送信される対象のドメインやパス」「有効期限」のような複数の属性を持つ構造で、これらの属性によってCookieの動作や有効範囲が制御されます。

そして今回はCookieのセキュリティを強化するSecure属性、HttpOnly属性、SameSite属性について触れていきたいと思います。

Secure属性

Secure属性は、CookieがHTTPS接続時にのみブラウザからサーバーに送信されるように制限する属性です。これにより、通信が暗号化されていないHTTP接続を介してCookieが送信されるリスクを低減します。

Secure属性が設定されていない場合、それを利用しセッションハイジャックや中間者攻撃などの攻撃を受ける可能性があります。

セッションハイジャックの例

Secure属性を設定していないWebサイトを利用したセッションハイジャックの例を紹介します。

① 攻撃者が公衆Wi-Fiネットワークを設定

まず攻撃者は、カフェや空港などの公衆の場で偽のWi-Fiアクセスポイント（ホットスポット）を設置します。正規のネットワーク名（SSID）に似せた名前を使用することで、ユーザーが誤って接続するよう誘導します。

② ユーザーが公衆Wi-Fiに接続し、ターゲットサイトにアクセス

そしてユーザーが攻撃者の偽装した公衆Wi-Fiに接続した状態で、ログイン機能のあるSecure属性が設定されていないWebサイトにアクセスします。Secure属性が設定されていないため、セッションCookieはHTTPおよびHTTPS接続の両方で送信されます。

③ 攻撃者が通信を傍受し、セッションCookieを取得

攻撃者は、偽のWi-Fiネットワークを通じてユーザーとサーバー間の通信を傍受します。Secure属性が設定されていないCookieは、暗号化されていないHTTP接続でも送信されるため、攻撃者はセッションCookieを容易に取得できます。

④ 攻撃者が取得したCookieを使用してターゲットサイトに不正アクセス

攻撃者は取得したセッションCookieを自分のブラウザに設定し、ターゲットサイトにアクセスします。これにより、攻撃者はユーザーのセッションとして認識され、認証された状態で不正にアクセスが可能になります。結果として、ユーザーの個人情報やアカウント情報が漏洩するリスクが発生します。

対策

CookieにSecure属性を設定し、HTTPS接続時のみ送信されるようにします。これにより、暗号化されていないHTTP経由でのCookie漏洩を防ぎ、セッションハイジャックのリスクを低減します。ウェブサイト全体でHTTPSを徹底し、Secure属性を適用することが重要です。

HttpOnly属性

HttpOnly属性は、Cookieがクライアントサイドのスクリプト（例えばJavaScript）からアクセスできないようにする属性です。これにより、クロスサイトスクリプティング（以下XSS）攻撃を通じてCookieが盗まれるリスクを低減します。

XSSの例

HttpOnly属性を設定していないWebサイトにてXSSを利用しCookieを悪用する例を紹介します。

①攻撃者がウェブサイトに悪意のあるスクリプトを注入
まず攻撃者は、XSSを利用してターゲットウェブサイトに悪意のあるJavaScriptコードを注入します。これには、コメント欄やフォーム入力など、ユーザーが入力を行う部分を狙うことが一般的です。

②ユーザーが感染したページを閲覧
ユーザーが攻撃者によって改ざんされたページを閲覧すると、悪意のあるスクリプトがブラウザ上で実行されます。

③悪意のあるスクリプトが実行され、セッションCookieを取得
実行されたスクリプトは、document.cookieを利用してセッションCookieを取得し、攻撃者が管理するサーバーに送信します。HttpOnly属性が設定されていない場合、JavaScriptからCookieにアクセス可能となります。

④攻撃者が取得したCookieを使用して不正アクセス
攻撃者は取得したセッションCookieを自分のブラウザに設定し、ターゲットサイトにアクセスします。これにより、ユーザーのセッションとして認識され、不正にアカウントにアクセスできます。

対策

CookieにHttpOnly属性を設定し、JavaScriptからのアクセスを防ぎます。これにより、XSS攻撃によるセッションCookieの盗難を防ぎ、セッションハイジャックのリスクを大幅に低減します。HttpOnlyを有効にすることで、ブラウザ上での不正なスクリプト実行からCookieを保護します。

SameSite属性

SameSite属性は、Cookieがクロスサイトリクエスト（異なるサイトからのリクエスト）と共に送信されるかどうかを制御する属性です。Strict、Lax、Noneの3種類があり、特にクロスサイトリクエストフォージェリ（以下CSRF）攻撃の防止に有効です。

  • Strict 完全に同一サイトからのリクエスト時のみCookieが送信されます。
  • Lax 一部のクロスサイトリクエスト（GETメソッドなど）ではCookieが送信されますが、セッショントークンなどの重要な操作では送信されません。
  • None クロスサイトリクエスト時にもCookieが送信されます。

SameSite属性が適切に設定されていない場合、それを利用しCSRFやセッションハイジャックの攻撃を受ける可能性があります。

CSRFの例

①ユーザーがターゲットサイトにログイン
ユーザーは正規のウェブサイトにログインし、認証Cookieがブラウザに保存されます。このとき、SameSite属性が適切に設定されていない場合、他サイトからのリクエストでもCookieが送信されます。

②攻撃者が悪意のあるサイトを用意
攻撃者は、ユーザーを誘導するための偽のウェブサイトやメールを用意します。このサイトには、不正なアクションを実行するリクエストを自動的に送信する仕掛けが組み込まれています。

③ユーザーが攻撃者のサイトを訪問し、不正なリクエストを送信
ユーザーが攻撃者のサイトを訪問すると、悪意のあるスクリプトやフォームが自動的に実行され、ターゲットサイトへの不正なリクエスト（例：送金リクエスト）が送信されます。このとき、SameSite属性がNoneや適切に設定されていないため、認証Cookieがリクエストと共に送信されます。

④ターゲットサイトがリクエストを正当なものとして処理
ターゲットサイトは受信したリクエストを正当なユーザーからのものと認識し、リクエストされたアクション（例：送金）を実行します。これにより、ユーザーの意図しない操作が行われ、被害が発生します。

対策

CookieにSameSite属性をStrictまたはLaxに設定し、他サイトからのリクエストでCookieが送信されないようにします。これにより、CSRF攻撃を防ぎ、認証Cookieの不正利用を防止します。

最後に

今回はCookieの脆弱性について書いてみましたがいかがだったでしょうか。

日々の開発業務に取り組む中で、Cookieについてはまだまだ理解が足りない部分があることに気づきました。今回の記事を書くことでCookieの重要性やセキュリティについてしっかり学ぶことができてとても良かったです。

これからの開発ではCookieの管理も意識することでよりセキュアな開発をしていきたいと思っています。皆さんもぜひCookieの扱いに注意してみてください！

ブログの著者欄

横内 亮太

GMO NIKKO株式会社

Ruby on Railsでの開発、脆弱性診断などのセキュリティ業務を行っています。

採用情報

関連記事

No.1&STEAM人財採用 新卒年収710万プログラム

KEYWORD

CATEGORY

TAG

もっとタグを見る

PICKUP

採用情報

SNS FOLLOW

GMOインターネットグループのSNSをフォローして最新情報をチェック

CATEGORY