競合状態と TOCTOU（CWE-362、CWE-367）：並列リクエストがチェックを破る仕組みと直し方

主要な概念と専門用語

TOCTOU（確認時点と使用時点のずれ）

確認した状態が、使う前に変わってしまうことがあります。Web のコードでは確認はたいてい SELECT で、使用はその後の UPDATE であり、その間にほかのリクエストが実行されます。

競合の窓と並列リクエスト

窓はたいてい数ミリ秒ですが、攻撃者は数十のリクエストを同時に届くように揃えられます。PortSwigger の 2023 年の研究では、多数の HTTP/2 リクエストの最後の数バイトを 1 つのパケットで送ると、約 1 ミリ秒以内にまとめて届くことが示されました。

アトミックな条件付き更新

UPDATE ... WHERE code = %s AND NOT redeemed RETURNING ... は 1 つの文で行の確認と変更を行います。行を受け取れるのは 1 つの呼び出し元だけで、ほかは何も受け取りません。

Read Committed での行ロック

PostgreSQL では、同じ行への 2 つ目の UPDATE は最初のトランザクションを待ち、その後コミット済みの行に対して WHERE 句を評価し直します。この再確認があるので、分離レベルを上げなくても条件付き更新は安全です。

制約と冪等キー

UNIQUE インデックスや CHECK (balance_cents >= 0) があれば、競合に負けた処理は二重に使われる代わりにはっきりエラーになります。Idempotency-Key を一意インデックス付きで保存すれば、クライアントは支払いを二重実行せずに再試行できます。

ステップ・バイ・ステップの攻撃フロー

ソースコード比較：脆弱 vs 堅牢化

# gift_cards.py: 確認と使用が別々の文になっている
from .db import pool


# どれかが書き込む前に、並列の各リクエストが redeemed = false を見られる
def redeem_gift_card(user_id: int, code: str) -> int:
    with pool.connection() as conn:
        card = conn.execute("SELECT id, balance_cents, redeemed FROM gift_cards WHERE code = %s", (code,)).fetchone()
        if card is None or card[2]:
            raise ValueError("invalid or used card")
        conn.execute("UPDATE accounts SET balance_cents = balance_cents + %s WHERE user_id = %s", (card[1], user_id))
        conn.execute("UPDATE gift_cards SET redeemed = true WHERE id = %s", (card[0],))
        return card[1]

# gift_cards.py: 確認と使用を 1 つの文で行う
from .db import pool


# 行を受け取るのは 1 件だけ。残りはロックを待ち、NOT redeemed が成り立たなくなる
def redeem_gift_card(user_id: int, code: str) -> int:
    with pool.connection() as conn, conn.transaction():
        card = conn.execute(
            "UPDATE gift_cards SET redeemed = true, redeemed_by = %s, redeemed_at = now() "
            "WHERE code = %s AND NOT redeemed RETURNING balance_cents",
            (user_id, code),
        ).fetchone()
        if card is None:
            raise ValueError("invalid or used card")
        # 同じトランザクションで加算するので、両方の変更がそろってコミットされるか、どちらもされない
        conn.execute("UPDATE accounts SET balance_cents = balance_cents + %s WHERE user_id = %s", (card[0], user_id))
        return card[0]

エンジニアリング＆システム堅牢化チェックリスト

• お金、在庫、クーポン、利用枠に対する「読む・確認する・書く」の手順を、1 つの条件付き UPDATE ... WHERE ... RETURNING か、トランザクション内の SELECT ... FOR UPDATE に置き換える。
• 1 回限りの操作はデータベースの制約（UNIQUE、CHECK (balance_cents >= 0)）で裏付け、競合に負けた処理が 2 回成功せずに失敗するようにする。
• 支払いと利用のエンドポイントで Idempotency-Key を受け付け、一意インデックス付きで保存する。
• 複数のワーカーやサーバーがリクエストを処理する場合、プロセス内のロックやフラグに頼らない。
• 1 枚のテスト用カードに対して 20 件の利用を並列に送り、成功がちょうど 1 件であることを確認する並行性テストを追加する。

参考資料

• CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
• PostgreSQL docs — Read Committed isolation level
• PortSwigger Research — Smashing the state machine (2023)
• Sakurity — Hacking Starbucks for unlimited coffee (2015)