DASTは、実行中のWebアプリケーションに外部からアクセスし、応答や挙動を見て脆弱性を検査する手法です。SG試験で迷いやすい静的解析やファジングとの違いを整理します。

sg sg-security-overview threat_vulnerability sg-security-measures unauthorized_access

まず結論

  • DASTとは、実行中のアプリケーションに外部からアクセスし、応答や挙動を見て脆弱性を検査する手法です。
  • SG試験では、「ソースコードを見る」のではなく「動いているアプリを外側から検査する」点で判断します。

直感的な説明

DASTは、Webアプリケーションを外から操作して、安全性を確認する検査です。

たとえば、利用者としてログイン画面や入力フォームにアクセスし、次のような動きを確認します。

  • 不正な入力をしたときにエラー処理ができるか
  • 認証を回避できないか
  • 本来見えない情報が表示されないか
  • 想定外の操作で異常な応答にならないか

イメージとしては、完成した建物に外から入って、ドアや窓の弱点を確認するようなものです。

設計図を読むのではなく、実際に使える状態のアプリを動かして確認します。

そのため、DASTは動的解析の一種として整理できます。

定義・仕組み

DASTは、Dynamic Application Security Testing の略です。

日本語では、動的アプリケーションセキュリティテストと説明されることがあります。

DASTでは、アプリケーションを実行した状態で、外部からリクエストを送り、その応答を確認します。

基本の流れは次のとおりです。

  1. 検査対象のWebアプリケーションを実行する
  2. 外部から画面やURLにアクセスする
  3. 入力フォームやパラメータに検査用データを送る
  4. 応答、エラー、画面表示、通信内容などを確認する
  5. 脆弱性の可能性がある挙動を洗い出す

DASTで見つけやすいものには、次のような例があります。

  • 入力値チェックの不備
  • 認証や認可の不備
  • セッション管理の不備
  • エラー画面からの情報漏えい
  • Webアプリケーション特有の脆弱性

IPAでは、Webアプリケーションの安全な作り方や脆弱性対策について資料を公開しています。Webアプリケーションの脆弱性対策を確認する場合は、IPAの安全なウェブサイトの作り方が参考になります。

DASTの重要な特徴は、ソースコードを直接確認しなくても検査できることです。

ただし、外部から見える挙動をもとに判断するため、コード内部のすべての問題を見つけられるわけではありません。

どんな場面で使う？

DASTは、Webアプリケーションを実際に動かせる状態で、外部からの攻撃に近い観点で確認したい場面に向いています。

たとえば、次のような場面です。

  • Webサービスを公開する前に安全性を確認したい
  • テスト環境で脆弱性を検査したい
  • 外部から見える弱点を確認したい
  • 認証や入力フォームの挙動を確認したい
  • リリース前に実行時の問題を見つけたい

DASTは、実際にアプリケーションを動かして確認するため、利用者や攻撃者から見える問題を見つけやすいです。

一方で、ソースコードの中にある危険な書き方を網羅的に見つけるのは得意ではありません。

そのような場合は、SASTのような静的解析の考え方が使われます。

つまり、次のように整理できます。

  • ソースコードを見て確認する → SAST・静的解析
  • 実行中のアプリを外部から確認する → DAST・動的解析
  • 多様な入力を大量に与えて挙動を見る → ファジング

SG試験では、「動いているアプリに外からアクセスして検査する」という表現があれば、DASTを疑います。

よくある誤解・混同

DASTは、静的解析、SAST、ファジング、ペネトレーションテストと混同しやすいです。

混同しやすい用語 判断ポイント
DAST 実行中のアプリを外部から検査し、応答や挙動を見る
SAST ソースコードを実行せずに解析し、危険な書き方を見つける
静的解析 プログラムを動かさずに、ソースコードなどを確認する
ファジング 問題を起こしそうなデータを大量に入力し、異常動作を探す
ペネトレーションテスト 攻撃者視点で侵入や権限昇格が可能かを検証する

SG試験では、次のような表現に注意します。

  • 「実行中のWebアプリケーションにアクセスする」
    → DASTを疑います。

  • 「外部からリクエストを送り、応答を確認する」
    → DASTです。

  • 「ソースコードを実行せずに解析する」
    → SASTや静的解析です。

  • 「多様なデータを自動生成して入力する」
    → ファジングに近い説明です。

  • 「攻撃シナリオに沿って侵入できるか確認する」
    → ペネトレーションテストに近い説明です。

よくあるひっかけは、DASTをソースコードレビューの一種だと思うことです。

DASTは、ソースコードを読む検査ではありません。

実行中のアプリケーションに対して、外部からアクセスし、応答や挙動を見て問題を探します。

また、DASTはペネトレーションテストと似ていますが、DASTはアプリケーションの脆弱性検査に焦点を当てることが多く、ペネトレーションテストは攻撃シナリオ全体で侵入や被害拡大を検証する点が違います。

まとめ（試験直前用）

  • DASTは、実行中のアプリを外部から検査する手法です。
  • ソースコードを読むのではなく、応答や挙動を見ることがポイントです。
  • 静的解析・SASTは、実行せずにソースコードなどを確認する方法です。
  • ファジングは、大量の入力データで異常動作を探す方法です。
  • SG試験では、実行中・外部からアクセス・応答確認の3点で判断します。

確認問題

DASTの説明として、最も適切なものはどれか。

ア. ソースコードを実行せずに解析し、危険な関数やコーディング規約違反を検出する。
イ. 実行中のWebアプリケーションに外部からアクセスし、応答や挙動を確認して脆弱性を検査する。
ウ. 社内ネットワークへ接続する端末の状態を確認し、条件を満たす端末だけ接続を許可する。
エ. 攻撃者の視点で侵入シナリオを作成し、重要情報へ到達できるかを検証する。

回答と解説を表示 正解は **イ** です。 DASTは、実行中のアプリケーションに外部からアクセスし、入力に対する応答や挙動を確認して脆弱性を検査する手法です。 アはSASTや静的解析、ウは検疫ネットワーク、エはペネトレーションテストに近い説明です。

🔗 関連記事

🏠 情報セキュリティマネジメントトップに戻る