午前I問題

複数のプロセス（スレッド）が共有資源に同時にアクセスする際に生じる問題に関する記述として、適切なものはどれか。

ア）デッドロックとは、2つ以上のプロセスが互いに相手の保持する資源の解放を待ち続け、処理が永久に進行しなくなる状態である。

イ）レースコンディションとは、プロセスの実行順序やタイミングによって処理結果が変わってしまう状態であり、セキュリティ上の脆弱性にはつながらない。

ウ）セマフォは、共有資源への同時アクセス数を無制限に許可するための同期機構である。

エ）ミューテックスは、複数のプロセスが同一の資源に同時書き込みを行うことを許可し、処理速度を向上させる機構である。

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

正解： ア

解説：

  • ア）正解。デッドロックの定義として適切です。資源の循環待ちにより処理が停止する状態を指します。
  • イ）不正解。レースコンディションは実行順序の不定性による結果の不一致であり、認可チェックのバイパスや二重実行など重大なセキュリティ脆弱性の原因になります。
  • ウ）不正解。セマフォは同時アクセス数を「制限」する同期機構であり、無制限に許可するものではありません。
  • エ）不正解。ミューテックス（相互排他）は同時アクセスを「禁止」し、1つのプロセスのみが資源を排他的に扱えるようにする機構です。

午前II問題

TOCTOU（Time-of-Check to Time-of-Use）脆弱性に関する記述として、最も適切なものはどれか。

ア）ファイルの存在や権限を確認した時点（Check）と、実際にそのファイルを使用する時点（Use）との間に時間差があり、その間にファイルが差し替えられることで意図しないファイルが操作される脆弱性である。

イ）暗号アルゴリズムの実装において、鍵長が推奨値より短いために総当たり攻撃で解読されてしまう脆弱性である。

ウ）Webアプリケーションの入力フォームで、HTMLタグを含む文字列がエスケープされずにそのまま出力される脆弱性である。

エ）通信プロトコルにおいて、認証情報が平文のままネットワーク上を流れることで盗聴される脆弱性である。

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

正解： ア

解説：

  • ア）正解。TOCTOUはチェック時点と使用時点の間の「隙間（レースウィンドウ）」を突き、シンボリックリンク差し替えなどによって検証済みのはずの対象を別のものにすり替える攻撃です。代表例に access() でのチェック後に open() を行うシンボリックリンク攻撃があります。
  • イ）不正解。これは鍵長不足の暗号強度の問題であり、TOCTOUとは無関係です。
  • ウ）不正解。これはXSSの説明です。
  • エ）不正解。これは平文通信による盗聴の説明であり、TOCTOUとは無関係です。
用語ポイント
TOCTOUチェックと使用の間の時間差を悪用
レースウィンドウ攻撃可能な時間差の区間
アトミック操作チェックと使用を不可分な1操作にまとめる対策

午後問題

E社が運営するECサイトでは、在庫確認と注文確定処理を以下の流れで実装している。

1. SELECT stock FROM products WHERE id = :product_id;  -- 在庫数を確認（Check）
2. アプリケーション側で stock > 0 を判定
3. INSERT INTO orders (...) VALUES (...);               -- 注文を登録（Use）
4. UPDATE products SET stock = stock - 1 WHERE id = :product_id;

セキュリティ診断の結果、以下の指摘を受けた。

  • 在庫数が残り1個の商品に対し、同一ユーザが複数の端末から同時に注文リクエストを送信したところ、いずれのリクエストも手順2の判定を通過し、在庫数が -1（マイナス）になる不整合が発生した。
  • また、ポイント残高の消費処理でも同様の設計となっており、短時間に連続してリクエストを送ることでポイント残高以上の商品を購入できる不正利用（二重使用）の可能性が指摘された。

設問1

この脆弱性の種類を答え、なぜ手順1〜4の実装で在庫数がマイナスになり得るのかを、“Check” と “Use” という語を用いて50字以内で説明せよ。

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

正解例：

  • 脆弱性の種類：レースコンディション（TOCTOU脆弱性）
  • 説明：在庫確認（Check）から注文確定・在庫更新（Use）までの間に他リクエストが割り込み、複数リクエストが同時に在庫ありと判定されるため。

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

採点項目キーワード配点
脆弱性の種類レースコンディション／TOCTOU5点
説明にCheckとUseの間の時間差への言及チェックと更新の間に別リクエストが割り込む7点
「同時に在庫ありと判定される」旨の記述複数リクエストが同一の在庫数を参照3点（部分点）

解説： 手順2でのアプリケーション側判定（Check）と手順3・4でのDB更新（Use）が分離しているため、複数リクエストがほぼ同時に手順1・2を通過し、いずれも「在庫あり」と誤判定してしまいます。これがTOCTOU型レースコンディションの典型例です。

設問2

この脆弱性に対する対策を2つ、実装レベルで具体的に述べよ。

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

正解例：

  1. 在庫の確認と減算を1つのSQL文にまとめ、UPDATE products SET stock = stock - 1 WHERE id = :product_id AND stock > 0 のようにアトミックな条件付き更新を行い、更新件数が0件なら在庫切れとしてロールバックする。
  2. SELECT ... FOR UPDATE による行ロック（悲観的ロック）や、バージョン番号を用いた楽観的ロックを利用し、確認から更新までの間、他トランザクションによる同一行への並行更新を防ぐ。

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

採点項目キーワード配点
対策1アトミックな条件付きUPDATE／WHERE stock > 07点
対策2行ロック／FOR UPDATE／楽観的ロック／トランザクション分離レベル7点
具体性SQL構文や実装手段が具体的に示されている1点（部分点）

解説： レースコンディション対策の本質は「チェックと使用を1つの不可分な操作にする」ことです。条件付きUPDATEによるアトミック化、または明示的な排他制御（行ロック・楽観的ロック）のいずれかで、確認から更新までの間に他リクエストが割り込めないようにします。ポイント残高消費処理にも同様の対策が必要です。

重要キーワード

用語説明
レースコンディション（TOCTOU）チェック時点と使用時点の間の時間差を突いて処理結果を不正に操作する脆弱性
レースウィンドウチェックから使用までの間に存在する、攻撃者が割り込み可能な時間的隙間
アトミック操作チェックと更新を不可分な単一操作として実行し、割り込みを排除する手法
悲観的ロック更新前に対象行をロックし、他トランザクションの並行アクセスを禁止する方式
楽観的ロックバージョン番号等で更新時に競合を検知し、あれば処理を失敗させる方式
シンボリックリンク攻撃チェック対象のパスをシンボリックリンクに差し替え、使用時点で別ファイルを操作させる攻撃

まとめ

  • 午前I視点： デッドロック・レースコンディション・セマフォ・ミューテックスなど並行処理の基礎用語を正確に区別する
  • 午前II視点： TOCTOUは「Check」と「Use」の時間差がキーワード。ファイルシステムだけでなくDB処理でも発生する点を押さえる
  • 午後視点： 在庫確認や残高消費のような「確認→更新」の2段階処理は典型的な出題パターン。アトミックな条件付き更新やロックによる対策を具体的に説明できるようにする