レースコンディション(競合状態)の仕組みと対策。チェックと使用の隙を原子性で塞ぐ

レースコンディション(競合状態)は、複数の処理が同じ資源に並行してアクセスするとき、実行の順序やタイミングによって結果が変わってしまう状態です。単発で動かす限り正しく見えるコードが、同時に何本も走った瞬間に破綻します。セキュリティの文脈でとくに問題になるのは、ある値を検査してから実際に使うまでの短い隙に、その値が別の処理によって変わってしまう場合です。この検査(check)と使用(use)のずれを突く典型が、TOCTOU(time-of-check to time-of-use)と呼ばれる欠陥です。

この記事は、WebアプリケーションとバックエンドAPIの開発者に向けて、なぜ並行アクセスが残高の二重引き出しやクーポンの多重適用、在庫超過といった不整合を生むのかを機構レベルで整理し、データベースの原子性やファイル操作の設計で塞ぐ方法をまとめます。攻撃の再現手順は扱わず、仕組みと防御実装に力点を置きます。

レースコンディションが成立する機構#

問題の核心は一文で言えます。ある処理が「値を検査する」ことと「その値に基づいて状態を変える」ことを別々のステップに分けて行い、その二つが原子的でないため、間に別の処理が割り込んで状態を変えてしまうのです。

MITREのCWE-362は、この欠陥を、共有資源に一時的な排他アクセスを必要とする処理に、並行して動く別の処理がその資源を変更できる時間の窓が存在する状態と定義しています。正しく動くには、対象の資源へ排他的にアクセスできること(排他性)と、その一連の操作が途中で割り込まれないこと(原子性)の二つが要りますが、レースコンディションではこのどちらかが崩れています。

CWE-367は、その中でもとくに多い形として、資源の状態を検査してから使用するまでの間に状態が変わり、検査結果が無効になる欠陥をTOCTOUとして定義しています。攻撃者が検査と使用の間に資源の状態へ介入できるとき、検査は「その時点では正しかった」だけの意味しか持たなくなり、実際に使われるのは変化した後の資源になります。

MITREのCWE-362は、並行実行される処理が共有資源への一時的な排他アクセスを必要とするにもかかわらず、別の処理がその資源を変更できる時間の窓が存在する欠陥と定義しています。排他性と原子性という二つの性質が守られないことが原因で、割り込む処理は内部の信頼できるコードのこともあれば、外部の信頼できない発信元のこともあると説明しています。

Webアプリで起きる並行リクエストの不整合#

Webアプリケーションでは、同じ利用者やセッションからのリクエストがサーバーで並行に処理されるときに、この隙が顔を出します。PortSwiggerのWeb Security Academyは、この種の欠陥をビジネスロジックの不備と密接に関連する脆弱性として整理し、アプリケーションが十分な保護なしにリクエストを並行処理すると、複数の処理が同じデータへ同時に触れて衝突(コリジョン)を起こすと説明しています。

分かりやすい例が、残高からの引き出しです。処理を「1. 残高が足りるか検査する」「2. 商品を渡す、または送金する」「3. 残高を減らす」の三段に分けて実装したとします。単発なら問題ありませんが、同じ利用者が残高ぎりぎりのリクエストをほぼ同時に二本送ると、両方が段階1を残高が減る前に通過し、二本とも段階2へ進んでしまいます。結果として残高以上の引き出しが成立します。同じ構図が、単回限りのギフトカードやクーポンの多重適用、招待コードの再利用、在庫数や定員の超過にもそのまま当てはまります。検査と更新の間に開いた窓へ、二本目のリクエストが滑り込む形です。

PortSwiggerのWeb Security Academyは、レースコンディションをリクエストの並行処理で生じる脆弱性と位置づけ、検査と変更と記録が別々のステップに分かれていると、最後の更新が完了する前の窓に重複リクエストが入り込むと説明しています。単回限りのギフトカードの複数回利用、割引コードの多重適用、残高を超える引き出し、レート制限の回避といった限度超過(limit overrun)を代表例として挙げています。

認可の判定も、状態の変化と組み合わさると同じ問題を抱えます。権限やアクセス対象の所有者を検査してから操作を実行するまでの間に対象が変わると、検査を通った操作が別の資源に効いてしまいます。認可の設計そのものの考え方は、次の記事で整理しています。

あわせて読みたい

IDORとアクセス制御の不備、識別子を差し替えられても守れる認可の作り方

ファイルと権限操作のTOCTOU#

同じ機構は、Webの外側、ファイルや権限を扱うシステムプログラムでも起きます。CWE-367が挙げる古典的な例が、シンボリックリンクを使った差し替えです。特権を持つプログラムが、あるファイル名について「アクセスしてよいか」を検査し、その後で同じ名前を開いて読み書きするとします。検査と使用が別々のシステムコールに分かれていると、その隙に攻撃者がそのファイル名を機微なファイルへのシンボリックリンクに差し替えられます。プログラムは検査を通った安全なファイルのつもりで、実際には差し替え後のリンク先を操作してしまい、権限昇格やファイル改ざんにつながります。

共有された一時ファイルも同じ弱点を抱えます。予測できる名前で一時ファイルを作る前に「存在しないこと」を確認してから作成する実装では、確認と作成の間に攻撃者が同名のファイルやリンクを用意でき、意図しない書き込み先へ導かれます。ここでも、名前を検査してから名前で開くという二段構えが割り込みを許しています。

MITREのCWE-367は、資源の状態を検査してから使用するまでの間に状態が変わり、検査結果が無効になる欠陥をTOCTOU競合状態と定義し、CWE-362の子として位置づけています。緩和策としては、そもそも使用前の検査をしない、操作の途中で割り込まれないよう原子的に扱う、環境のロック機構で資源を保護してから検査する、使用後に資源を再確認する、といった方策を挙げています。検査と使用の時間差を小さくすることについては、問題を修正するものではなく攻撃の成立を難しくするだけだと明記しています。古典的な実例として access() で許可を確かめてから fopen() で開く実装を示し、両方がファイル名を扱うために隙が生まれると説明しています。ファイル名ではなくファイルディスクリプタに対して操作する設計は、この実例から導ける防御策です。

原子性で隙を塞ぐ対策#

対策の原理は一つです。検査と、それに基づく状態変更を分割せず、途中で割り込めない一つの操作にまとめます。Webのデータ操作とファイル操作で、具体的な手立ては次のように整理できます。

データベースを持つWebアプリでは、多くの場合データベースの原子性に寄せるのが確実です。アプリケーションのメモリ上で検査してから書き戻すと、その間はデータベースの外に状態があり、並行トランザクションから守れません。判定と更新を一つのSQL文にまとめる、あるいはトランザクションと適切な分離レベル、行ロックで囲むことで、検査と使用が一体になります。単回性は一意制約でデータベースに保証させるのが堅牢で、アプリ側の「使用済みか」の検査より取りこぼしがありません。

ファイル操作では、名前を検査してから同じ名前で開き直す二段構えをやめ、副作用のない方法でファイルディスクリプタを先に取得し、fstat() で所有者や種別を確かめてから同じディスクリプタに対して読み書きします。ただし通常の open() は途中のシンボリックリンクをたどり、O_TRUNC を付けると検証前にファイルが切り詰められ、O_NOFOLLOW はパス末尾のリンクしか防げません。Linux では、信頼済みのディレクトリFDを起点に openat() で開く、openat2() の RESOLVE_NO_SYMLINKS でリンク解決を禁じる、RESOLVE_BENEATH で指定ディレクトリの外へ出させない、といった手段でリンク差し替えの余地を狭められます。

複数プロセスやサーバーにまたがる処理では、データベースだけで守れない場合に分散ロックで排他区間を作る選択肢もあります。ただしロックは取得漏れや解放漏れ、保持時間の設計を誤ると別の不具合を招くため、まずはデータベースの原子性と一意制約で守れないかを先に検討します。入力の検証や認証と同じく、単一の対策に頼らず、原子的な設計を土台に据えたうえで最小権限や監視を重ねる姿勢が有効です。

外部入力を安全に扱う設計全般の考え方は、次の記事とあわせて読むと土台が固まります。

あわせて読みたい

入力バリデーションと出力エスケープの原則。入口で検証し、出口で文脈別にエスケープする

まとめ#

レースコンディション(CWE-362)は、共有資源への排他的で割り込まれないアクセスが必要な処理に、別の処理が入り込める時間の窓が開いている欠陥です。その代表であるTOCTOU(CWE-367)は、資源を検査してから使用するまでの隙に状態が変わり、検査結果が無意味になります。Webでは同一利用者の並行リクエストが残高やクーポンの検査を同時に通過して二重引き出しや多重適用を招き、システムではファイル名の検査と使用の隙にシンボリックリンクが差し替えられます。

対策の要点は、検査とそれに基づく状態変更を分割せず原子的に行うことです。データベースでは条件付きの原子的更新や行ロック、単回性を守る一意制約で隙をなくし、ファイル操作では名前ではなく安全に取得したファイルディスクリプタに対して操作します。決済のように副作用の大きい操作では、冪等性キーで通信再送やダブルクリックを吸収します。危険なタイミングを都度潰そうとするのではなく、そもそも割り込む窓を残さない設計にすることが出発点です。

認可の判定と状態変更が絡む不整合は、アクセス制御の設計そのものを見直すと根から減らせます。関連する考え方は次の記事で扱っています。

あわせて読みたい

認証と認可の違い。Authentication と Authorization を基礎から整理する