DAST（動的アプリセキュリティテスト）とは？

DAST（動的アプリセキュリティテスト）とは？

動的アプリセキュリティテスト（DAST）の定義は、ある特定のアプリや ホワイトボックステスト（アプリセキュリティテスト）の一種で、試験中のシステムが実際に使用されている状態で解析される一方、テスターはアプリのソースコードや内部通信、設計図などにアクセスできない点にあります。 

この「ブラックボックス」テストは、外部からシステムを観察し、動作状態やテストツールによるシミュレーション攻撃に対する反応を検証します。アプリの反応が、本当の攻撃に対して脆弱かどうかの手がかりとなります。

‍

DASTはどのように機能するか？

DAST攻撃に対する脆弱性を調べるため、ツールはまず問題のある入力フィールドを探し出し、さまざまな予期せぬまたは悪意あるデータを投入します。これには、SQLインジェクションやクロスサイトスクリプティング（XSS）のような一般的手法から、入力検証やメモリ管理の問題を浮き彫りにするまれなケースまで含まれます。

DASTツールは、連続して与えた入力に対するアプリの反応を見て、その攻撃ベクトルに対し脆弱か否かを判断します。たとえば、SQLインジェクション攻撃で情報に無制限にアクセスできたり、不正な入力のためにアプリが正常に動作しなかった場合、セキュリティホールがあると見なされます。

‍

DASTが重要な理由は？

アプリの脆弱性がすぐになくなる見込みは低く、セキュリティテストは欠かせません。CNBCの調査では、75%以上のアプリが何らかの形で脆弱であるとされています。

開発者は、ユーザ入力の十分な検証不足やサーババージョンの情報漏洩、古いまたは安全でないライブラリの利用など、シンプルなミスが大きな問題を引き起こすことがあります。

従来のペネトレーションテストや静的アプリセキュリティテストと比べ、DASTテストは常に進化している点が異なります。実際のアプリ動作を即時に模倣してテストが実施されるため、通常、稼働中の環境（プロダクション環境）で行われます。

‍

DASTの種類

DASTに公式なサブタイプはありませんが、セキュリティ専門家は技術を「モダン」と「レガシー」の2つに大別しています。主な違いは以下のとおりです。

自動化と連携: 従来のDASTツールは、手動でオンデマンドに実行することを前提に作られていました。スキャン自体は自動化されていますが、追加の自動化機能はなく、DASTによるセキュリティ脆弱性の一覧を表示するだけです。しかし、最新のDASTソリューションはJenkinsなどの自動化サーバで起動され、開発プロセス（SDLC）の裏側で動作するよう設計されています。スキャン後、結果は開発者向けのチケットシステムに転送されます。

脆弱性の確認・検証: レガシーなDASTツールは、リクエスト送信とレスポンス受信による単純な検証のみ可能で、他の確認手法はありません。一方、最新のDASTツールは手動検証の必要がなく、100%の確実性で脆弱性を確認し、攻撃の証拠を提示するチェックを行います。

動的アプリセキュリティテスト：メリットとデメリット

運用中のアプリを対象としたスキャンには、DASTならではの利点と課題があります。ここでは、DASTツール利用のメリットとデメリットを詳しく説明します。

＜メリット＞

• アプリコードに触れない

DASTツールはアプリのソースコードに手を加えないため、どんなプラットフォームや言語でも利用できます。異なるアプリ間でも1つのツールで対処でき、コストパフォーマンスにも優れ、広範なセキュリティチェックに適しています。

• セットアップの問題がない

実稼働中のアプリから脆弱性を検出するため、他のツールで見逃しがちな設定ミスも発見できます。コード上からは分かりにくい設定エラーも洗い出すことが可能です。

• 誤検出が少ない

OWASP Benchmark Projectの調査によれば、DASTツールの誤検出率は平均より低く、信頼性が高いとされています。

• 効果的なペネトレーションテスト機能

手動でペネトレーションテストを実施する際、DASTスキャナーを活用すると、システムの侵入反応や攻撃ペイロードの捕捉状況を自動化して確認できます。この効果はオペレーターのスキルに依存するため、セキュリティ専門家や開発管理者が有効に運用することが求められます。

＜デメリット＞

DASTには多くの利点がある一方、すべての問題を解決するツールではありません。主な課題は以下のとおりです。

• SDLCでの遅い導入

実行中のプログラムが必要なため、ソフトウェア開発ライフサイクルの後半で実施され、脆弱性修正が高コストになる可能性があります。

• 脆弱性の位置特定が困難

アプリ内に脆弱性があることは確認できても、ソースコードにアクセスできないため、具体的な箇所の特定は困難です。

• コードカバレッジの不足

稼働中のプログラムを解析するため、コード全体を網羅できず、一部の脆弱性を見逃す可能性があります。

DASTとSASTの違い

動的アプリセキュリティテスト（DAST）は、実際の攻撃を模倣する点で、静的アプリセキュリティテスト（SAST）とは異なります。DASTスキャナーが攻撃を行い、その結果の異常から潜在的な脆弱性を探し出します。

一方、SASTはアプリのソースコード内部を解析し、対応する言語やWEBフレームワークが必要です。対して、DASTはプログラムの外側からHTTP通信を利用して検査します。

セキュリティ向上のためには、SASTとDASTの両方を組み合わせることが推奨されます。両者のギャップを埋めるため、グレーボックス的手法であるインタラクティブアプリセキュリティテスト（IAST）の導入も検討されます。

‍

DASTの使い方と活用タイミング

DASTはWEBアプリのセキュリティを即時に監視し、サーバやデータベースの設定ミスを検出するのに有効です。SASTと異なり、認証や暗号化の不備による不正アクセスの脆弱性も見逃しません。

さらに、WEBアプリが利用するネットワークやデータ保管などのITインフラも検証できるため、アプリやWEBサービスだけでなく、それらが組み込まれている環境全体のテストが可能です。

‍

DASTの導入

DASTは、アプリが実行されている状態が必要なため、SASTほどテストパイプラインへの統合が容易ではありません。自動化は可能ですが、まず自動化準備の手動工程を記録する必要があります。ツールをパイプラインに組み込んだ後は、一定の手順を踏むことになります。

• 利用者の意見を聞く

DASTテスト導入の第一歩として、利用者がソフトとどのように関わるかを観察することは非常に有益です。単に行動を記録するだけでなく、その理由も聞くようにします。

アプリ内での操作が頻繁になると、利用者は自分の行動に無頓着になりがちです。操作にあまり意識を払わなくなると、後々問題が発生する可能性も否めません。

• 利用者の操作を自動化する

次のステップは、オートメーションツールを用いて利用者の操作をスクリプト化することです。GUIよりも、コマンドラインやAPIを利用する方が容易な場合がありますが、いずれも実現可能です。

• テストスクリプトをCI/CDパイプラインに組み込む

アプリの主要な操作の自動化が完了したら、DASTツールでテスト中にこれらのスクリプトを実行します。初回のスキャンの結果をもとに、脆弱性への対応を開始できます。

• 回帰テストをテストスイートに追加する

日常の利用で発生したセキュリティホールについて、実際のシナリオを模したスクリプトをテストスイートに加えることで修正し、再発を防止できます。

‍

Wallarm DAST

Wallarmの脆弱性・インシデント検出モジュールは、アプリ固有の脆弱性を見つけ出し、脅威を積極的に評価して高リスクの事象を抽出します。

Wallarm NG-WAFモジュールは攻撃データも収集し、これをWallarm DASTで解析します。Wallarmは悪意あるリクエストのペイロード、攻撃種類、アプリのエンドポイントを解析し、これらの情報をもとにスキャナーテストを生成します。既存の脆弱性が攻撃対象であった場合、その問題を検出し、修正チケットを発行します。

まとめ

既存または今後のDevOpsでは、開発スピードを損なわないセキュリティ技術の導入が求められます。静的アプリセキュリティテスト（SAST）に次いで、DASTが広く利用されています。従来型のみならず新興企業も、新規ソフト作成時のワークフローにDASTを組み込む動きが強まっています。

動的アプリセキュリティテストは、実行時に現れる脆弱性を発見するのに有効ですが、すべてのセキュリティホールを検出できるわけではありません。このツールに全体の守りを求めるのは適切ではありません。

そのため、一部の企業では複数のASTツールを併用し、ソフトウェアの脆弱性検出に幅広い対策を講じています。