Webアプリケーションのタイミング攻撃をテストするにはどうすればよいですか？
タイミング攻撃 競合状態（CWE-362） 脆弱性はWebアプリケーションではあまり一般的ではありません。これらは主に低レベル言語の問題です。たとえば、 CVE-2006-5178 の場合、競合状態はPHPインタープリター自体の不適切な実装が原因でした。しかし、これらの関数に依存するアプリケーションも脆弱になります。
タイミングの問題と特定の環境のニーズにより、このような脆弱性を再現しようとするのは困難な場合があります。自動化された脆弱性スキャナーでは、そのようなテストを実行することは現実的ではありません-人間であっても、そのような脆弱性を見つけることは容易ではありません。
私の意見では、開発者はメインプロセスが中断される可能性がある場合に留意する必要があるだけです。原子性は、一連のアクションを中断できないようにする必要がある場合に提供する必要があります。主にデータベースアクションは、このような攻撃の影響を受けます。 DBMSがトランザクションをサポートし、安全な同期のための手段を提供する場合でも、それらをアトミックにするためにDBMSの制御下にあるよりグローバルなアクションが存在する可能性があります。スレッドが使用される状況にも注意が必要です。
CWE-362へのリンクには、参考になる論文のリストがあります。これらは、ここで提供したよりもはるかに多くの情報を提供します。
ここでの議論と回答は、競合条件の周りにあるようで、通常はその名前で参照されます。
あなたが本当にタイミング攻撃を意味するのであれば、おそらく実行時間の不一致による情報漏えいについて話しているでしょう。 タイミング攻撃のレッスン は、これに対する優れた、アクセス可能な導入です。
これらの発見に特に役立つツールについては知りませんが、一般的なWeb評価ツールでは、タイミング攻撃によって悪化する可能性のある他の問題が明らかになる可能性があります。
外部のパーティがデータベースに対してSQLコードを実行できる脆弱性があるとします-従来のSQLインジェクション。いくつかの予防策を講じたとしましょう。データを取り戻したり、データベースに任意の情報を書き込んだりすることはできません。何らかの一般的なエラーメッセージを返すだけです。外部の関係者が「select」ステートメントを使用してデータベースのスキーマを調査し、応答を受信するのにかかった時間を計ることは可能です。バックエンドシステムが実行している作業量を監視するだけで、他の方法では得られない可能性があることについて特定のことを学んでいます（特定のテーブルが実際に存在するかどうか、テーブルに多くのレコードがあるかどうかなど）。