--- title: "DASTとは？実行中のアプリを検査する仕組み【SG試験】" description: "DASTは、実行中のWebアプリケーションに外部からアクセスし、応答や挙動を見て脆弱性を検査する手法です。SG試験で迷いやすい静的解析やファジングとの違いを整理します。 試験対策として重要語の定義・具体例・よくある誤解をまとめ、短時間で復習できるように整理しています。" last_modified_at: "2026-05-18" canonical_url: "https://stemtazoo.github.io/sg/dast/" section: "sg" --- ## まず結論 - **DAST**とは、実行中のアプリケーションに外部からアクセスし、応答や挙動を見て脆弱性を検査する手法です。 - SG試験では、**「ソースコードを見る」のではなく「動いているアプリを外側から検査する」**点で判断します。 ## 直感的な説明 DASTは、Webアプリケーションを外から操作して、安全性を確認する検査です。 たとえば、利用者としてログイン画面や入力フォームにアクセスし、次のような動きを確認します。 - 不正な入力をしたときにエラー処理ができるか - 認証を回避できないか - 本来見えない情報が表示されないか - 想定外の操作で異常な応答にならないか イメージとしては、**完成した建物に外から入って、ドアや窓の弱点を確認する**ようなものです。 設計図を読むのではなく、実際に使える状態のアプリを動かして確認します。 そのため、DASTは**動的解析**の一種として整理できます。 ## 定義・仕組み DASTは、Dynamic Application Security Testing の略です。 日本語では、**動的アプリケーションセキュリティテスト**と説明されることがあります。 DASTでは、アプリケーションを実行した状態で、外部からリクエストを送り、その応答を確認します。 基本の流れは次のとおりです。 1. 検査対象のWebアプリケーションを実行する 2. 外部から画面やURLにアクセスする 3. 入力フォームやパラメータに検査用データを送る 4. 応答、エラー、画面表示、通信内容などを確認する 5. 脆弱性の可能性がある挙動を洗い出す DASTで見つけやすいものには、次のような例があります。 - 入力値チェックの不備 - 認証や認可の不備 - セッション管理の不備 - エラー画面からの情報漏えい - Webアプリケーション特有の脆弱性 IPAでは、Webアプリケーションの安全な作り方や脆弱性対策について資料を公開しています。Webアプリケーションの脆弱性対策を確認する場合は、IPAの[安全なウェブサイトの作り方](https://www.ipa.go.jp/security/vuln/websecurity/about.html)が参考になります。 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や静的解析、ウは検疫ネットワーク、エはペネトレーションテストに近い説明です。