状態機械を叩き壊す：Webレースコンディションが持つ「本当の」攻撃可能性

本記事は、PortSwigger Research の「Smashing the state machine: the true potential of web race conditions」（https://portswigger.net/research/smashing-the-state-machine）を元ソースとして、その要点と周辺の公式解説・関連研究を、提供された範囲の出典のみで補足しながらまとめたものです。

概要

Webのレースコンディション攻撃は、複数リクエストを「ほぼ同時」に処理させることで、アプリケーションが想定しない順序・重なり方で状態を更新してしまう隙を突く手法です。一般には“タイミングが難しくて不安定”という課題が強調され、結果として議論や検証はごく一部のシナリオに集中しがちでした。

しかし元ソースが指摘するのは、問題の本質が単なる同時実行の偶然ではなく、アプリケーションが持つ状態遷移（ステートマシン）と、その遷移を支えるチェック・更新の分割、そして実装上の前提の崩れにある、という点です。つまり「状態がどう進むべきか」という設計と実装の境界で、タイミング衝突が“意図しない遷移”を発生させ、そこにより広い攻撃可能性が眠っている、という見立てです。

詳細

レースコンディション攻撃は「注意深くタイミング調整したリクエストで意図的な衝突を起こし、その副作用を悪用する」ものだと整理できます。典型的には、同じ資源（残高、在庫、権限、状態フラグなど）に対する検証と更新が別々に行われたり、複数の工程に分かれたワークフローの途中で“本来は一度しか起きないはずの遷移”が重複実行されたりすると、矛盾した状態が生まれます。Web Security Academyの解説は、この「衝突を作る」こと自体が難しく、時間制約やネットワーク要因が再現性を下げる点、そしてツール支援が重要になる点を示します。

元ソースが強調する「真の潜在力が隠れてきた」理由のひとつが、実運用のワークフローの複雑さです。Webアプリの重要な処理ほど、画面遷移・API呼び出し・トークン更新・バックグラウンド処理などが折り重なり、どこで状態が確定し、どの条件で遷移が拒否されるのかが見えにくくなります。この見えにくさは、脆弱性の有無を曖昧にするだけでなく、テスト設計を「よくある数パターン」に矮小化しやすくします。

もうひとつが、ネットワークジッタ（遅延の揺れ）による“たまたま成功/失敗”の混入です。狙いはサーバ側での処理順序の競合ですが、リクエストがサーバに届くまでの揺れや、同時送信が完全に揃わないことが、検証者にとって大きなノイズになります。PortSwiggerのブログ記事も、この不確実性がテストを本質的に信頼しにくくし、時間制約と相まって難易度を上げることを問題として扱っています。

こうした障害に対し、関連研究として提示されているのが「remote race-conditions を 'local' にする」発想です。たとえば「single-packet attack」は、HTTP/2の複数リクエストを単一TCPパケットで完了させることでジッタの影響を事実上小さくし、衝突の再現性を高める、と説明されています。ここで重要なのは、特定のテクニック名そのものよりも、「競合を偶然に頼らず、サーバ側の並行処理へ確実に“同時の入力”を押し込む」方向へ検証技術が進化している点です。

さらに、攻撃可能性を広げるためには、単発の“同時リクエスト芸”ではなく、状態機械としてのアプリを観察し、どの遷移が原子的でないか、どの境界で検証と更新が分離しているか、どこに再入可能性（同じ工程の二重実行）があるか、といった観点で探索する必要があります。Web Security Academyが触れるように、タイミング調整を補助するツールがあることで、ようやくこの探索が実用的になり、複雑なワークフローに潜む競合を体系的に検出しやすくなります。

研究発表の文脈としては、DEF CON 31で同名テーマの講演が行われており、レースコンディションを「限られたケースの珍技」ではなく、状態遷移の破綻として捉え直す問題提起が、コミュニティに向けて共有されていることがうかがえます。元ソースの主張に沿えば、今後の実務的なポイントは、(1) ワークフローを状態機械として分解して観測する、(2) ジッタを抑えて衝突を安定生成する、(3) ツールと自動化で“再現性のある検証”に寄せる、の3点に収れんします。