チェックアウトフローの自動セキュリティスキャンでは、SQLインジェクションやクロスサイトスクリプティングのような従来の脆弱性は発見されませんでした。ジュニアペンテスターは、スキャナーの結果に基づいて、このエンゲージメントに重大な発見はないと判断する準備ができていました。しかし、チームメンバーが、割引コードを適用するエンドポイントが、注文確認後までコードを無効化しないことに気づきました。この設計上の欠陥により、一度しか使用できないコードが同時に複数回利用される可能性がありました。同じリクエストを同時に送信することで、一度しか使用できない50%割引コードが数秒以内に40回利用されました。このタイプの脆弱性、つまり競合状態は、コードの有効性をチェックしてから使用済みとしてマークするまでの間に発生するギャップによって引き起こされます。自動スキャナーは、リクエストを逐次的にテストし、同時にテストしないため、競合状態を検出できません。脆弱なエンドポイントは、クーポンを redemption する、または資金を引き出すといった、「チェックしてから実行する」パターンを伴うことがよくあります。競合状態を悪用するには、ネットワークジッターを最小限に抑えるために、リクエストを単に迅速にではなく、同時に送信する必要があります。Burpの競合状態タブやTurbo Intruderのようなツールは、この目的のために設計されています。競合状態の証拠は、単に成功したレスポンスコードだけでなく、コードが適用された回数といったシステムの最終状態にあります。この種のビジネスロジックの欠陥はスキャナーでは見逃され、同時アプリケーションの動作に関する手動調査が必要です。Codelivlyのリソースとラボは、自動スキャン機能を越えたこれらの高度な脆弱性に焦点を当てています。