• DASTによるアプリケーションのスキャン方法
  • アプリケーションのクロール
  • パッシブスキャン
  • アクティブスキャン
• 利用を開始
  • DAST CI/CDジョブの作成
  • 認証
  • 利用可能な CI/CD 変数
• スコープの管理
  • スコープの種類
    • 範囲内
    • スコープ外
    • スコープから除外
  • 認証時のスコープの動作は異なります
  • DASTがHTTPリクエストをブロックする方法
  • スコープの設定方法
• 脆弱性の検出
• スキャン時間の管理
• タイムアウト
• トラブルシューティング

DASTブラウザベースアナライザー

• GitLab 13.12でベータ機能として導入されました。
• GitLab 15.7 (GitLab DAST v3.0.50)で一般的に利用可能。

DASTブラウザベースのアナライザは、現代のウェブアプリケーションの脆弱性をスキャンするためにGitLabによって構築されました。スキャンはブラウザ上で実行され、シングルページのアプリケーションなど、JavaScriptに大きく依存するアプリケーションのテストを最適化します。詳しくは、DASTによるアプリケーションのスキャン方法をご覧ください。

アナライザをCI/CDパイプラインに追加するには、始めるを参照してください。

DASTによるアプリケーションのスキャン方法

スキャンは以下のステップを実行します：

1. 設定されている場合は、認証します。
2. ターゲットアプリケーションをクロールし、リンクをたどる、ボタンをクリックする、フォームに入力するなどのユーザーアクションを実行することで、アプリケーションの表面領域を発見します。
3. パッシブスキャンクロール中に発見された HTTP メッセージやページの脆弱性を検索します。
4. クロール中に記録されたHTTPリクエストにペイロードを注入して脆弱性を探索するアクティブスキャン。

アプリケーションのクロール

ナビゲーション」とは、ボタンをクリックしたり、アンカーリンクをクリックしたり、メニュー項目を開いたり、フォームに入力したりするような、ユーザーがページ上で取る可能性のあるアクションのことです。ナビゲーションパス」とは、ユーザーがどのようにアプリケーションを横断するかを表す、一連のナビゲーションアクションのことです。DAST は、ページやコンテンツをクロールし、ナビゲーションパスを特定することで、アプリケーションの表面領域を発見します。

クロールは、特別に計測された Chromium ブラウザでターゲットアプリケーションの URL をロードする 1 つのナビゲーションを含むナビゲーションパスで初期化されます。その後、DASTはナビゲーションパスをすべてクロールするまでクロールします。

ナビゲーションパスをクロールするには、DASTはブラウザウィンドウを開き、ナビゲーションパス内のすべてのナビゲーションアクションを実行するように指示します。ブラウザが最後のアクションの結果をロードし終わると、DASTはユーザーが取る可能性のあるアクションについてページを検査し、見つかったそれぞれについて新しいナビゲーションを作成し、それらをナビゲーションパスに追加して新しいナビゲーションパスを形成します。例えば

1. DASTはナビゲーションパスLoadURL[https://example.com] を処理します。
2. DASTは2つのユーザーアクション、LeftClick[class=menu] とLeftClick[id=users]を見つけます。
3. DAST は 2 つの新しいナビゲーションパス、LoadURL[https://example.com] -> LeftClick[class=menu] とLoadURL[https://example.com] -> LeftClick[id=users]を作成します。
4. クロールは2つの新しいナビゲーションパス上で開始されます。

全てのページに表示されるメニューのように、HTML 要素がアプリケーションの複数の場所に存在することはよくあることです。要素が重複していると、クローラが同じページを再度クロールしたり、ループにはまり込んだりする可能性があります。DASTは、HTML属性に基づく要素の一意性計算を使って、以前にクロールした新しいナビゲーションアクションを破棄します。

パッシブスキャン

パッシブスキャンは、スキャンのクロールフェーズで発見されたページの脆弱性をチェックします。パッシブスキャンはデフォルトで有効になっています。

この検査では、HTTP メッセージ、Cookie、ストレージイベント、コンソールイベント、および DOM を検索して脆弱性を探します。パッシブ・チェックの例としては、公開されたクレジットカード、公開された秘密トークン、コンテンツ・セキュリティ・ポリシーの欠落、信頼できない場所へのリダイレクトの検索などがあります。

個々のチェックの詳細については、チェックを参照してください。

アクティブスキャン

アクティブスキャンは、スキャンのクロールフェーズで記録されたHTTPリクエストに攻撃ペイロードを注入して脆弱性をチェックします。アクティブ スキャンは、プロービング攻撃の性質上、デフォルトでは無効になっています。

DASTは、クエリ値、ヘッダ値、Cookie値、フォーム投稿、JSON文字列値などの注入場所を記録されたHTTPリクエストごとに分析します。攻撃ペイロードはインジェクション位置に注入され、新しいリクエストを形成します。DASTはリクエストをターゲットアプリケーションに送信し、HTTPレスポンスを使用して攻撃の成功を判断します。

アクティブスキャンは2種類のアクティブチェックを実行します：

• レスポンスの一致攻撃は、レスポンスの内容を分析して攻撃の成功を判断します。たとえば、攻撃がシステム パスワード ファイルの読み取りを試みる場合、レスポンス本文にパスワード ファイルの証拠が含まれていると、検出結果が作成されます。
• タイミング攻撃は、攻撃の成功を決定するために応答時間を使用します。例えば、ある攻撃がターゲットアプリケーションを強制的にスリープさせようとする場合、アプリケーションがスリープ時間より長く応答すると、ファインディングが作成されます。タイミング攻撃は、誤検出を最小限にするために、異なる攻撃ペイロードで複数回繰り返されます。

単純化したタイミング攻撃は以下のように動作します：

1. クロールフェーズは HTTP リクエストhttps://example.com?search=people を記録します。
2. DASTはURLを分析し、URLパラメータ注入場所を見つけますhttps://example.com?search=[INJECT] 。
3. アクティブチェックは、Linuxホストをスリープさせようとするペイロード（sleep 10 ）を定義します。
4. DAST は、注入されたペイロードhttps://example.com?search=sleep%2010 を持つ新しい HTTP リクエストをターゲットアプリケーションに送信します。
5. ターゲット・アプリケーションは、例えばクエリ・パラメータの値を検証せずにシステム・コマンドとして実行すると脆弱性 になります、system(params[:search])
6. 例えば、DAST は応答時間が 10 秒以上かかると発見します。

利用を開始

DASTスキャンを実行するには

• DAST スキャンを実行するための前提条件をお読みください。
• CI/CDパイプラインにDASTジョブを作成します。
• アプリケーションでユーザー認証が必要な場合は、ユーザー認証を行ってください。

DAST CI/CDジョブの作成

• このテンプレートは GitLab 14.0 で DAST_VERSION: 2 に更新されました。
• このテンプレートは GitLab 15.0 で DAST_VERSION: 3 に更新されました。

アプリケーションにDASTスキャンを追加するには、GitLab DAST CI/CDテンプレートファイルで定義されたDASTジョブを使用してください。テンプレートのアップデートはGitLabのアップグレードとともに提供され、改善や追加の恩恵を受けることができます。

CI/CDジョブを作成するには：

1. 適切な CI/CD テンプレートをインクルードしてください：

   • DAST.gitlab-ci.yml:DAST CI/CDテンプレートの安定版。
   • DAST.latest.gitlab-ci.yml:DASTテンプレートの最新バージョン。(GitLab 13.8で導入）。
   テンプレートの最新バージョンは変更を含んでいる可能性があります。最新のテンプレートにしかない機能が必要でない限り、安定版テンプレートを使ってください。

   テンプレートのバージョン管理について詳しくは、CI/CDのドキュメントを参照してください。

2. GitLabのCI/CDステージ設定にdast ステージを追加します。

3. 以下のいずれかの方法で、DASTがスキャンするURLを定義します：

   • DAST_WEBSITE CI/CD 変数を設定します。設定されている場合、この値が優先されます。

   • environment_url.txt プロジェクトのルートにあるファイルに environment_url.txtURL を追加すると、environment_url.txt 動的環境でのテストに最適 environment_url.txtです。environment_url.txt GitLab CI/CDパイプライン中に動的に作成されたアプリケーションに対してDASTを実行するには、アプリケーションのURLをファイルに記述 environment_url.txtします。DASTは自動的にURLを読み込んでスキャンターゲットを見つけます。

     この例はAuto DevOps CI YAMLで見ることができます。

4. CI/CD 変数 DAST_BROWSER_SCAN を"true"に設定してください。

使用例：

stages:
  - build
  - test
  - deploy
  - dast

include:
  - template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_WEBSITE: "https://example.com"
    DAST_BROWSER_SCAN: "true"

認証

ブラウザベースのアナライザでは、スキャン前にユーザーを認証できます。設定方法については、「認証」を参照してください。

利用可能な CI/CD 変数

これらのCI/CD変数は、ブラウザベースのDASTアナライザに特有のものです。これらの変数を使用して、DASTの動作を要件に合わせてカスタマイズすることができます。認証CI/CD変数については、認証を参照してください。

スコープの管理

スコープは、DAST がターゲットアプリケーションをクロールする際にどの URL をたどるかを制御します。スコープを適切に管理することで、スキャンの実行時間を最短にすると同時に、ターゲットアプリケーションの脆弱性のみを確実にチェックします。

スコープの種類

スコープには3種類あります：

• スコープ内
• 範囲外
• 対象外

範囲内

DASTはスコープ内のURLを追跡し、DOMを検索してクロールを継続するための後続アクションを探します。記録されたスコープ内のHTTPメッセージは、受動的に脆弱性をチェックし、フルスキャンを実行する際に攻撃を構築するために使用されます。

スコープ外

DASTは、画像、スタイルシート、フォント、スクリプト、AJAXリクエストなど、ドキュメント以外のコンテンツタイプについては、スコープ外のURLに従います。認証は別として、DASTは外部ウェブサイトへのリンクをクリックした場合など、全ページを読み込んだ場合にはスコープ外URLを追跡しません。情報漏えいを検索する受動的なチェックを除き、スコープ外URLの記録されたHTTPメッセージは脆弱性をチェックしません。

スコープから除外

DASTはスコープから除外されたURLを追跡しません。情報漏えいを検索する受動的なチェックを除き、スコープから除外されたURLの記録されたHTTPメッセージは脆弱性をチェックしません。

認証時のスコープの動作は異なります

多くのターゲットアプリケーションでは、シングルサインオン（(SSO) ）のために ID アクセス管理プロバイダを使用する場合など、認証プロセスが外部のウェブサイトに依存しています。DASTがこれらのプロバイダで確実に認証できるようにするため、DASTは認証時にフルページロードのスコープ外URLをたどります。DASTはスコープから除外されたURLには従いません。

DASTがHTTPリクエストをブロックする方法

DASTはスコープルールによってリクエストをブロックする場合、通常通りHTTP リクエストを行うようブラウザに指示します。リクエストはその後インターセプトされ、BlockedByClient という理由で拒否されます。この方法によって、DASTはHTTPリクエストを記録しながら、ターゲットサーバーに到達しないようにすることができます。200.1などのパッシブチェックでは、外部ホストに送信された情報を検証するために、記録された リクエストを使用します。

スコープの設定方法

デフォルトでは、ターゲットアプリケーションのホストに一致するURLはスコープ内とみなされます。それ以外のホストはスコープ外とみなされます。

スコープは以下の変数を使って設定します：

• DAST_BROWSER_ALLOWED_HOSTS を使ってスコープ内ホストを追加します。
• 対象外のホストに追加するにはDAST_BROWSER_IGNORED_HOSTS を使ってください。
• 対象外ホストに追加するにはDAST_BROWSER_EXCLUDED_HOSTS を使ってください。
• DAST_EXCLUDE_URLS を使用して、特定の URL を除外対象として設定します。

ルール

• ホストを除外することは、ホストを無視することよりも優先され、ホストを許可することよりも優先されます。
• ホストのスコープを設定しても、そのホストのサブドメインのスコープは設定されません。
• ホストにスコープを設定しても、そのホストのすべてのポートにスコープを設定することはできません。

典型的な設定は次のようなものです：

include:
  - template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_WEBSITE: "https://my.site.com"                   # my.site.com URLs are considered in-scope by default
    DAST_BROWSER_ALLOWED_HOSTS: "api.site.com:8443"       # include the API as part of the scan
    DAST_BROWSER_IGNORED_HOSTS: "analytics.site.com"      # explicitly disregard analytics from the scan
    DAST_BROWSER_EXCLUDED_HOSTS: "ads.site.com"           # don't visit any URLs on the ads subdomain
    DAST_EXCLUDE_URLS: "https://my.site.com/user/logout"  # don't visit this URL

脆弱性の検出

脆弱性検知は、デフォルトのZed Attack Proxy(ZAP) ソリューションからブラウザベースのアナライザに徐々にマイグレーションされています。すでにマイグレーションされた脆弱性検出の詳細については、ブラウザベースの脆弱性チェックを参照してください。

クローラーはDAST/ZAPをプロキシサーバーとして設定したブラウザでターゲットウェブサイトを実行します。これにより、ブラウザによるすべてのリクエストとレスポンスが DAST/ZAP によって受動的にスキャンされます。フルスキャンを実行する場合、DAST/ZAPが実行するアクティブ脆弱性チェックはブラウザを使用しません。この脆弱性のチェック方法の違いにより、スキャンが意図したとおりに動作するように、ターゲットウェブサイトの特定の機能を無効にする必要があるというイシューが発生する可能性があります。

例えば、Anti-CSRF トークンを使用したフォームを含むターゲット Web サイトの場合、ブラウザはページやフォームをユーザーがページを見ているかのように表示するため、パッシブスキャンは意図したとおりに動作します。しかし、フルスキャンで実行されるアクティブ脆弱性チェックでは、Anti-CSRF トークンを含むフォームを送信できません。このような場合は、フルスキャンを実行する際にAnti-CSRFトークンを無効にすることをお勧めします。

スキャン時間の管理

ブラウザベースのクローラーを実行することで、標準的なGitLab DASTソリューションと比較して、多くのウェブアプリケーションのカバレッジが向上することが期待されます。これはスキャン時間の増加という代償を払うことになります。

カバレッジとスキャン時間のトレードオフは、以下の方法で管理することができます：

• ランナーを垂直方向に拡大縮小し、変数 DAST_BROWSER_NUMBER_OF_BROWSERS でより多くのブラウ ザーを使用します。デフォルトは3 。
• ブラウザが実行するアクションの数を変数 DAST_BROWSER_MAX_ACTIONS で制限します。デフォルトは10,000 です。
• ブラウザベースのクローラーがカバレッジをチェックするページの深さを変数 DAST_BROWSER_MAX_DEPTH で制限します。クローラーは幅優先の検索戦略を使うので、深さの浅いページが最初にクロールされます。デフォルトは10 です。
• 変数 DAST_BROWSER_CRAWL_TIMEOUT でターゲットアプリケーションのクロールにかかる時間を制限します。デフォルトは24h です。クローラーがタイムアウトしても、スキャンはパッシブチェックとアクティブチェックで継続されます。
• DAST_BROWSER_CRAWL_GRAPH という変数でクロールグラフを作成し、どのページがクロールされているかを確認します。
• ページがクロールされないようにするには、変数 DAST_EXCLUDE_URLS を使います。
• 変数 DAST_BROWSER_EXCLUDED_ELEMENTS を使って、要素が選択されないようにします。この変数を定義すると、クロールされる各ページに余分なルックアップが発生するので、注意して使用してください。
• ターゲット・アプリケーションのレンダリングが最小限か高速の場合、変数 DAST_BROWSER_DOM_READY_AFTER_TIMEOUT をより小さな値にすることを検討してください。デフォルトは500ms です。

タイムアウト

ネットワークの状態が悪かったり、アプリケーションの負荷が高かったりすると、デフォルトのタイムアウトが適用されない場合があります。

ブラウザベースのスキャンは、1つのページから次のページへの遷移をスムーズに継続するために、様々なタイムアウトを調整する機能を提供します。これらの値はDuration文字列を使用して設定されます。Duration文字列は接頭辞で設定することができます: 分はm 、秒はs 、ミリ秒はms 。

Navigations、もしくは新しいページをロードする行為は、JavaScriptやCSSファイルのような複数の新しいリソースをロードするので、通常もっとも多くの時間を必要とします。これらのリソースのサイズや返される速度によっては、デフォルトのDAST_BROWSER_NAVIGATION_TIMEOUT では不十分な場合があります。

DAST_BROWSER_NAVIGATION_STABILITY_TIMEOUT,DAST_BROWSER_STABILITY_TIMEOUT,DAST_BROWSER_ACTION_STABILITY_TIMEOUT で設定可能なような安定タイムアウトも設定可能です。安定性タイムアウトは、ブラウザベースのスキャンがページを完全に読み込んだとみなすタイミングを決定します。ブラウザベースのスキャンは以下の場合にページがロードされたとみなします：

1. DOMContentLoadedイベントが発生したとき。
2. JavaScriptやCSSのような重要なリクエストはありません。メディアファイルは通常、重要ではないと判断されます。

3. ブラウザがナビゲーションを実行したか、強制的に遷移させられたか、アクションを実行したかによって異なります：

   • DAST_BROWSER_NAVIGATION_STABILITY_TIMEOUT 、DAST_BROWSER_STABILITY_TIMEOUT 、DAST_BROWSER_ACTION_STABILITY_TIMEOUT の期間の後には、新しい Document Object Model(DOM) の変更イベントはありません。

これらのイベントが発生した後、ブラウザベースのスキャンはページがロードされ準備ができたとみなし、次のアクションを試みます。

アプリケーションが遅延を経験したり、多くのナビゲーション失敗を返す場合、この例のようにタイムアウト値を調整することを検討してください：

include:
  - template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_WEBSITE: "https://my.site.com"
    DAST_BROWSER_NAVIGATION_TIMEOUT: "25s"
    DAST_BROWSER_ACTION_TIMEOUT: "10s"
    DAST_BROWSER_STABILITY_TIMEOUT: "15s"
    DAST_BROWSER_NAVIGATION_STABILITY_TIMEOUT: "15s"
    DAST_BROWSER_ACTION_STABILITY_TIMEOUT: "3s"

トラブルシューティング

詳しくはトラブルシューティングをご覧ください。