午前I問題

Webアプリケーションのセッション管理に用いるCookieの属性に関する記述のうち、最も適切なものはどれか。

ア）HttpOnly属性を付与すると、JavaScriptからのCookie読み取りを禁止でき、XSS攻撃によるセッションCookie窃取のリスクを軽減できる

イ）Secure属性を付与すると、Cookieの値が自動的に暗号化されるため、HTTP通信で送信しても内容を第三者に読み取られることはない

ウ）SameSite=Noneを指定すると、CSRF攻撃に対する防御が自動的に有効になる

エ）Cookieに有効期限を設定しなければ、ブラウザを閉じてもセッションは無期限に保持される

午前I の解答・解説を見る

正解： ア）HttpOnly属性を付与すると、JavaScriptからのCookie読み取りを禁止でき、XSS攻撃によるセッションCookie窃取のリスクを軽減できる

解説：

  • ア）正解。HttpOnly属性が付与されたCookieは、document.cookieなどJavaScript経由でのアクセスができなくなる。これにより、XSS脆弱性が存在してもスクリプト経由でセッションCookieを窃取される被害を軽減できる。
  • イ）不正解。Secure属性はCookieをHTTPS通信でのみ送信させる制御であり、Cookie自体を暗号化する機能ではない。HTTP通信では送信されない（送信対象外になる）だけであり、「暗号化して送信する」という説明は誤り。
  • ウ）不正解。SameSite=NoneはむしろクロスサイトでのCookie送信を許可する設定であり、CSRF対策としては逆方向。CSRF対策として有効なのはSameSite=StrictまたはSameSite=Laxであり、CSRFトークン等との併用が推奨される。
  • エ）不正解。有効期限（Expires/Max-Age）を指定しないCookieは「セッションCookie」となり、ブラウザを閉じると（実装によってはタブを閉じると）破棄される。「無期限に保持される」が誤り。

午前II問題

Same-Origin Policy（同一オリジンポリシー）とCORS（Cross-Origin Resource Sharing）に関する記述のうち、最も適切なものはどれか。

ア）Same-Origin Policyは、スキーム・ホスト・ポート番号がすべて一致する場合のみ同一オリジンと判定し、異なるオリジン間でのスクリプトからのリソースアクセスをブラウザが制限する仕組みである

イ）CORSはサーバ側の設定にかかわらず、ブラウザが独自に判断してクロスオリジン通信の許可・拒否を決定する仕組みである

ウ）レスポンスヘッダにAccess-Control-Allow-Origin: *を設定すれば、Cookie等の資格情報（credentials）を伴うクロスオリジンリクエストも安全に許可できる

エ）CORSはサーバへのリクエスト自体を送信不可にすることで、クロスサイトリクエストフォージェリ（CSRF）を完全に防止する仕組みである

午前II の解答・解説を見る

正解： ア）

解説：

  • ア）正解。Same-Origin Policyはスキーム（http/https）・ホスト（ドメイン）・ポート番号の3要素すべてが一致する場合のみ同一オリジンとみなし、それ以外は異なるオリジンとしてJavaScriptからのリソースアクセス（レスポンス読み取り等）をブラウザが制限する。
  • イ）不正解。CORSはサーバ側がAccess-Control-Allow-Origin等のレスポンスヘッダで許可するオリジンを明示し、ブラウザがそのヘッダに基づいてスクリプトへのレスポンスアクセスを許可するかどうかを判定する仕組みであり、ブラウザが独自に許可・拒否を決定するわけではない。
  • ウ）不正解。Access-Control-Allow-Origin: *（ワイルドカード）は仕様上、Access-Control-Allow-Credentials: trueと併用できない。資格情報を伴うリクエストを許可する場合は、オリジンを具体的に限定して指定する必要がある。ワイルドカードとcredentials許可の組み合わせは任意のサイトからの資格情報付きアクセスを許してしまう重大な誤設定である。
  • エ）不正解。CORSはリクエスト自体の送信を止める仕組みではなく（単純リクエストは実際には送信されレスポンスの読み取りを制限する場合が多い）、あくまでブラウザ側でのレスポンス読み取り制御が中心。CSRF対策としてはCSRFトークンやSameSite Cookieなど別の対策が必要であり、CORS単体でCSRFを「完全に」防止するとはいえない。

午後問題

複数のWebサービスを展開するG社は、フロントエンド（app.example.com）とバックエンドAPI（api.example.com）をサブドメインで分離したアーキテクチャを採用している。リリース前セキュリティレビューで次の点が指摘された。

  • バックエンドAPIのCORS設定がAccess-Control-Allow-Origin: *かつAccess-Control-Allow-Credentials: true相当の設定になっており（実際にはオリジンを動的に反射する実装で、リクエストヘッダのOriginの値をそのまま許可オリジンとして返していた）、任意のオリジンから資格情報（セッションCookie）付きでAPIを呼び出せる状態だった
  • セッションCookieにはHttpOnly属性は付与されていたが、SameSite属性が未設定（ブラウザのデフォルト挙動に依存）であり、Secure属性も付与されていなかった
  • 攻撃者が用意した悪意あるサイト（evil.example.net）からapp.example.comのログイン済みユーザがアクセスした場合、バックエンドAPIに対してユーザのセッションCookie付きでリクエストを送信し、レスポンス（個人情報等）を攻撃者のスクリプトが読み取れる可能性が指摘された

設問1

CORS設定の誤りについて、指摘された問題の技術的な原因と、講じるべき修正内容を述べよ。

設問1の解答・解説を見る

正解例：

原因： リクエストのOriginヘッダの値をそのままAccess-Control-Allow-Originレスポンスヘッダに反射（オウム返し）する実装になっており、実質的にすべてのオリジンからの資格情報付きクロスオリジンリクエストを許可してしまっている。これにより、悪意あるサイトからのスクリプトが、ログイン済みユーザのセッションCookieを使ってAPIを呼び出し、本来アクセス権限のないはずのレスポンス内容を読み取れてしまう。

修正内容： 許可するオリジンをアプリケーションが正規に利用するapp.example.comなどのホワイトリストとして明示的に管理し、リクエストのOriginヘッダがホワイトリストに含まれる場合のみ、そのオリジンをAccess-Control-Allow-Originとして返す実装に修正する。ワイルドカード（*）や無条件反射は資格情報を伴うリクエストでは使用しない。

解説・採点基準（計15点）：

採点項目キーワード配点
Originヘッダの無条件反射が原因である旨の指摘「Originの反射」「実質的な全許可」6点
ホワイトリストによる許可オリジンの限定に言及「許可オリジンのホワイトリスト化」「明示的な許可リスト」6点
ワイルドカードとcredentialsの組み合わせが不可・危険である旨への言及「*とcredentials併用不可」3点

設問2

セッションCookieの属性設定について、追加すべき属性を2つ挙げ、それぞれの効果を述べよ。

設問2の解答・解説を見る

正解例：

  1. Secure属性：Cookieの送信をHTTPS通信時のみに限定し、HTTP通信での平文送信によるネットワーク盗聴（中間者攻撃）でのセッションCookie漏洩を防ぐ。

  2. SameSite=LaxまたはSameSite=Strict属性：クロスサイトのコンテキストからのCookie送信を制限する。Strictであれば他サイト経由のリクエストには一切Cookieが付与されず、Laxでも多くのクロスサイトPOSTリクエスト等でCookie送信を抑止できるため、CSRFや本事案のようなクロスオリジンからの不正なセッション利用のリスクを軽減できる。

解説・採点基準（計15点）：

採点項目キーワード配点
Secure属性とその効果（HTTPS限定・盗聴防止）に言及「Secure」「HTTPS限定」6点
SameSite属性とその効果（クロスサイト送信制限）に言及「SameSite」「Strict/Lax」「クロスサイト送信の抑止」6点
CORS設定修正と組み合わせた多層防御である旨への言及（加点）「多層防御」「CORS修正と併用」3点

HttpOnlyは既に付与済みのため、これを再度挙げるのみの回答は新規対策として認めない。

重要キーワード

用語説明
セッション管理とCORSセッションCookieの属性設定とオリジン間リソース共有（CORS）に関するセキュリティ設計全般
HttpOnly属性JavaScriptからのCookie読み取りを禁止し、XSSによるセッションCookie窃取のリスクを軽減するCookie属性
Secure属性CookieをHTTPS通信でのみ送信させ、平文通信での盗聴リスクを軽減するCookie属性
SameSite属性クロスサイトコンテキストでのCookie送信を制限し、CSRF等のリスクを軽減するCookie属性（Strict/Lax/None）
Same-Origin Policyスキーム・ホスト・ポートが一致する場合のみ同一オリジンとみなし、異なるオリジン間のリソースアクセスをブラウザが制限する仕組み
CORS（Cross-Origin Resource Sharing）サーバがレスポンスヘッダで許可するオリジンを明示し、クロスオリジンでのリソース共有を制御可能にする仕組み

まとめ

  • 午前I視点： HttpOnlyはXSS対策、SecureはHTTPS限定送信、SameSiteはクロスサイト送信制限と、それぞれのCookie属性が防ぐ攻撃の対応関係を正確に区別する。
  • 午前II視点： CORSはサーバ側が許可オリジンを明示する仕組みであり、Access-Control-Allow-Origin: *とcredentials許可は仕様上併用不可という点が頻出のひっかけポイント。
  • 午後視点： Originヘッダの無条件反射によるCORS誤設定と、Cookie属性（Secure・SameSite）の設定不備は組み合わさって被害が拡大する。ホワイトリスト化とCookie属性強化の両輪で対策する。