正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

認証

完全にカバレッジを行うには、テスト対象のアプリケーションでDASTアナライザーを認証する必要があります。これには、DAST CI/CDジョブで認証認証情報と認証方式を設定する必要があります。

DASTで認証が必要な理由:

  • 実際の攻撃者をシミュレートし、攻撃者が悪用する可能性のある脆弱性を特定するため。
  • 認証後にのみ表示される可能性のある、ユーザー固有の機能とカスタム動作をテストするため。

DASTジョブは、ブラウザーでログインフォームに入力して送信することにより、アプリケーションに対して自身を認証します。フォームが送信されると、DASTジョブは、認証が成功したことを確認します。認証に成功した場合、DASTジョブは続行し、ターゲットアプリケーションのクロール時に再利用できるように、認証情報を保存します。そうでない場合、DASTジョブは停止します。

DASTでサポートされている認証方法:

  • シングルステップのログインフォーム
  • マルチステップのログインフォーム
  • 設定されたターゲットURLの外部にあるURLへの認証

認証認証情報を選択する際:

  • （運用環境）システム、本番環境サーバー、または本番環境データへのアクセスに使用される認証情報はDO NOT（使用しないでください）。
  • （本番環境）サーバーに対して認証されたスキャンを実行DO NOT（しないでください）。認証されたスキャンは、認証されたユーザーが実行できる任意の機能（データの変更や削除、フォームの送信、リンクのクリックなど）を実行する可能性があります。認証されたスキャンは、本番環境以外のシステムまたはサーバーに対してのみ実行してください。
  • DASTがアプリケーション全体をテストできるように、認証情報を提供します。
  • 将来の参照のために、認証情報の有効期限（もしあれば）をメモしておいてください。たとえば、1Passwordなどのパスワードマネージャーを使用します。

次の図は、認証のさまざまな段階での認証変数の使用法を示しています:

%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
    accTitle: Authentication variables
    accDescr: A sequence diagram showing authentication variables at different stages of authentication.
    participant DAST
    participant Browser
    participant Target

    Note over DAST,Target: Initialization
    DAST->>Browser: Initialize browser with proxy
    DAST->>Browser: Navigate to DAST_AUTH_URL
    Browser->>Target: Load initial page
    Target-->>Browser: Return page content (may not contain login form)

    Note over DAST,Target: Process before-login actions
    DAST->>Browser: Click elements specified in DAST_AUTH_BEFORE_LOGIN_ACTIONS
    Browser->>Target: Send click actions
    Target-->>Browser: Render login form (modal/page)

    Note over DAST,Target: Authentication
    DAST->>Browser: Fill DAST_AUTH_USERNAME & DAST_AUTH_PASSWORD
    DAST->>Browser: Click "submit"
    Browser->>Target: Submit form
    Target-->>Browser: Process authentication
    Target-->>Browser: Set auth tokens

    Note over DAST,Target: Process after-login actions (if specified)
    DAST->>Browser: Execute DAST_AUTH_AFTER_LOGIN_ACTIONS
    Browser->>Target: Actions after login but before login verification

    Note over DAST,Target: Verification
    DAST->>Browser: Check URL matches DAST_AUTH_SUCCESS_IF_AT_URL (if configured)
    DAST->>Browser: Check element exists DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND (if configured)
    DAST->>Browser: Check login form absent DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORM (default is true)

はじめに

アプリケーションの変更により、アナライザーの認証が機能しなくなる傾向があるため、定期的にアナライザーの認証がまだ機能していることを確認する必要があります。

DASTの認証済みスキャンを実行するには:

前提要件

  • スキャン中に認証するユーザーのユーザー名とパスワードが必要です。
  • DASTがアプリケーションに対して認証できることを確認するために、既知の問題を確認しました。
  • フォーム認証を使用している場合は、前提条件を満たしている必要があります。
  • フォーム認証フローに時間ベースのワンタイムパスワードが含まれている場合は、追加の前提条件を満たしている必要があります。
  • 認証が成功したかどうかを確認する方法を検討しました。

フォーム認証

  • アプリケーションのログインフォームのURLを知っている必要があります。または、認証URLからログインフォームに移動する方法を知っている必要があります（ログインフォームに移動するためにクリックするを参照）。
  • DASTがそれぞれの入力に使用するユーザー名とパスワードのHTMLフィールドのセレクターを知っている必要があります。
  • 選択時にログインフォームを送信する要素のセレクターを知っている必要があります。

TOTP

  • Base32でエンコードされた、テストユーザーのTOTP登録用のシークレットキーが必要です。
  • 認証プロバイダーが、次のTOTP設定（Google Authenticatorと同じ）をサポートしていることを確認済みである必要があります:
    • HMACアルゴリズム: SHA-1
    • タイムステップ: 30秒
    • トークンの長さ: 6
  • 生成されたTOTPトークンを入力するためにDASTが使用するTOTPフィールドのセレクターを知っている必要があります。
  • パスワードとは別にTOTPトークンを送信する場合、TOTPトークンを送信する要素のセレクターを知っている必要があります。

利用可能なCI/CD変数

DAST認証CI/CD変数のリストについては、認証変数を参照してください。

DAST CI/CD変数テーブルは、Rakeタスクbundle exec rake gitlab:dast_variables:compile_docsによって生成されます。これは、lib/gitlab/security/dast_variables.rbで定義された変数メタデータを使用します。

ターゲットWebサイトをアップデートする

CI/CD変数DAST_TARGET_URLを使用して定義されたターゲットWebサイトは、DASTがアプリケーションのクロールを開始するために使用するURLです。

認証されたスキャンで最適なクロール結果を得るには、ターゲットWebサイトは、ユーザーが認証された後にのみアクセスできるURLである必要があります。多くの場合、これはユーザーがログイン後にアクセスするページのURLです。

例:

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com/dashboard/welcome"
    DAST_AUTH_URL: "https://example.com/login"

HTTP認証の設定

基本認証などのHTTP認証スキームを使用するには、DAST_AUTH_TYPEの値をbasic-digestに設定します。ネゴシエートやNTLMなどの他のスキームも機能する可能性がありますが、自動テストカバレッジが現在不足しているため、公式にはサポートされていません。

構成には、CI/CD変数DAST_AUTH_TYPE、DAST_AUTH_URL、DAST_AUTH_USERNAME、DAST_AUTH_PASSWORDがDASTジョブに定義されている必要があります。一意のログインURLがない場合は、DAST_AUTH_URLをDAST_TARGET_URLと同じURLに設定します。

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_TYPE: "basic-digest"
    DAST_AUTH_URL: "https://example.com"

DAST_AUTH_USERNAMEおよびDAST_AUTH_PASSWORDをYAMLジョブ定義ファイルに定義not（しないでください）。これは、セキュリティ上のリスクをもたらす可能性があるためです。代わりに、GitLab UIを使用して、マスクされたCI/CD変数として作成します。詳細については、カスタムCI/CD変数を参照してください。

シングルステップログインフォームの設定

シングルステップログインフォームには、すべてのログインフォーム要素が1つのページにあります。構成には、CI/CD変数DAST_AUTH_URL、DAST_AUTH_USERNAME、DAST_AUTH_USERNAME_FIELD、DAST_AUTH_PASSWORD、DAST_AUTH_PASSWORD_FIELD、DAST_AUTH_SUBMIT_FIELDがDASTジョブに定義されている必要があります。

たとえば、ジョブ定義YAMLでフィールドのURLとセレクターをセットアップする必要があります:

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
    DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
    DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"

DAST_AUTH_USERNAMEおよびDAST_AUTH_PASSWORDをYAMLジョブ定義ファイルに定義not（しないでください）。これは、セキュリティ上のリスクをもたらす可能性があるためです。代わりに、GitLab UIを使用して、マスクされたCI/CD変数として作成します。詳細については、カスタムCI/CD変数を参照してください。

マルチステップログインフォームの設定

マルチステップログインフォームには、2つのページがあります。最初のページには、ユーザー名と次の送信ボタンがあるフォームがあります。ユーザー名が有効な場合、後続の2番目のフォームにはパスワードとフォーム送信ボタンがあります。

構成では、DASTジョブに対してCI/CD変数を定義する必要があります:

  • DAST_AUTH_URL
  • DAST_AUTH_USERNAME
  • DAST_AUTH_USERNAME_FIELD
  • DAST_AUTH_FIRST_SUBMIT_FIELD
  • DAST_AUTH_PASSWORD
  • DAST_AUTH_PASSWORD_FIELD
  • DAST_AUTH_SUBMIT_FIELD。

たとえば、ジョブ定義YAMLでフィールドのURLとセレクターをセットアップする必要があります:

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
    DAST_AUTH_FIRST_SUBMIT_FIELD: "css:button[name=next]"
    DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
    DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"

DAST_AUTH_USERNAMEおよびDAST_AUTH_PASSWORDをYAMLジョブ定義ファイルに定義not（しないでください）。これは、セキュリティ上のリスクをもたらす可能性があるためです。代わりに、GitLab UIを使用して、マスクされたCI/CD変数として作成します。詳細については、カスタムCI/CD変数を参照してください。

時間ベースのワンタイムパスワード（TOTP）の設定

TOTPの設定には、次のCI/CD変数をDASTジョブに定義する必要があります:

  • DAST_AUTH_OTP_FIELD
  • DAST_AUTH_OTP_KEY

パスワードの送信後にTOTPトークンが独自のフォームで送信される場合は、次の変数も定義する必要があります:

  • DAST_AUTH_OTP_SUBMIT_FIELD

_FIELDセレクター変数は、ジョブ定義YAMLで定義できます（例:

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
    DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
    DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"
    DAST_AUTH_OTP_FIELD: "name:otp"
    DAST_AUTH_OTP_SUBMIT_FIELD: "css:input[type=submit]"

DAST_AUTH_OTP_KEYをYAMLジョブ定義ファイルに定義not（しないでください）。これは、セキュリティ上のリスクをもたらす可能性があるためです。代わりに、GitLab UIを使用して、マスクされたCI/CD変数として作成します。詳細については、カスタムCI/CD変数を参照してください。

シングルサインオン（SSO）の設定

ユーザーがアプリケーションにサインインできる場合、ほとんどの場合、DASTもサインインできます。アプリケーションがシングルサインオンを使用している場合でも同様です。SSOソリューションを使用するアプリケーションでは、シングルステップまたはマルチステップログインフォーム設定ガイドを使用してDAST認証を設定する必要があります。

DASTは、ユーザーが外部のIdentity Providerのサイトにリダイレクトされてサインインする認証プロセスをサポートしています。お使いのSSO認証プロセスがサポートされているかどうかを確認するには、DAST認証の既知の問題を確認してください。

Windows統合認証（Kerberos）の設定

Windows統合認証（Kerberos）は、Windowsドメイン内でホストされている基幹業務（LOB）アプリケーションの一般的な認証メカニズムです。ユーザーのコンピューターログインを使用して、プロンプトなしの認証を提供します。

この形式の認証を構成するには、次の手順を実行します:

  1. IT/運用チームの支援を受けて、必要な情報を収集します。
  2. .gitlab-ci.ymlファイルでdastジョブ定義を作成またはアップデートします。
  3. 収集した情報を使用して、サンプルのkrb5.confファイルを入力された状態にします。
  4. 必要なジョブ変数を設定します。
  5. プロジェクトの設定ページを使用して、必要なシークレット変数を設定します。
  6. テストし、認証が機能していることを確認します。

IT/運用部門からの支援を得て、次の情報を収集します:

  • WindowsドメインまたはKerberosレルムの名前（EXAMPLE.COMのように、名前にピリオドが含まれている必要があります）
  • Windows/Kerberosドメインコントローラーのホスト名
  • Kerberosの場合、AuthNサーバー名。Windowsドメインの場合、これはドメインコントローラーです。

krb5.confファイルを作成する:

[libdefaults]
  # Realm is another name for domain name
  default_realm = EXAMPLE.COM
  # These settings are not needed for Windows Domains
  # they support other Kerberos implementations
  kdc_timesync = 1
  ccache_type = 4
  forwardable = true
  proxiable = true
  rdns = false
  fcc-mit-ticketflags = true
[realms]
  EXAMPLE.COM = {
    # Domain controller or KDC
    kdc = kdc.example.com
    # Domain controller or admin server
    admin_server = kdc.example.com
  }
[domain_realm]
  # Mapping DNS domains to realms/Windows domain
  # DNS domains provided by DAST_AUTH_NEGOTIATE_DELEGATION
  # should also be represented here (but without the wildcard)
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM

この設定では、DAST_AUTH_NEGOTIATE_DELEGATION変数を使用します。この変数は、統合認証を許可するために必要な次のChromiumポリシーを設定します:

この変数の設定は、WindowsドメインまたはKerberosレルムに関連付けられているDNSドメインです。それらを指定する必要があります:

  • 小文字と大文字の両方で。
  • ワイルドカードパターンとドメイン名のみを使用します。

この例では、WindowsドメインはEXAMPLE.COMで、DNSドメインはexample.comです。これにより、DAST_AUTH_NEGOTIATE_DELEGATIONの値は*.example.com,example.com,*.EXAMPLE.COM,EXAMPLE.COMになります。

すべてをまとめてジョブ定義にまとめます:

# This job will extend the dast job defined in
# the DAST template which must also be included.
dast:
  image:
    name: "$SECURE_ANALYZERS_PREFIX/dast:$DAST_VERSION$DAST_IMAGE_SUFFIX"
    docker:
      user: root
  variables:
    DAST_TARGET_URL: https://target.example.com
    DAST_AUTH_URL: https://target.example.com
    DAST_AUTH_TYPE: basic-digest
    DAST_AUTH_NEGOTIATE_DELEGATION: '*.example.com,example.com,*.EXAMPLE.COM,EXAMPLE.COM'
    # Not shown -- DAST_AUTH_USERNAME, DAST_AUTH_PASSWORD set via Settings -> CI -> Variables
  before_script:
    - KRB5_CONF='
[libdefaults]
  default_realm = EXAMPLE.COM
  kdc_timesync = 1
  ccache_type = 4
  forwardable = true
  proxiable = true
  rdns = false
  fcc-mit-ticketflags = true
[realms]
  EXAMPLE.COM = {
    kdc = ad1.example.com
    admin_server = ad1.example.com
  }
[domain_realm]
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM
'
    - cat "$KRB5_CONF" > /etc/krb5.conf
    - echo '$DAST_AUTH_PASSWORD' | kinit $DAST_AUTH_USERNAME
    - klist

期待される出力:

ジョブコンソール出力には、beforeスクリプトからの出力が含まれています。認証に成功した場合、次のようになります。ジョブは、スキャンを実行せずに失敗した場合に失敗します。

Password for mike@EXAMPLE.COM:
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: mike@EXAMPLE.COM

Valid starting       Expires              Service principal
11/11/2024 21:50:50  11/12/2024 07:50:50  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 11/12/2024 21:50:50

DASTスキャナーは、成功を示す次の出力も出力します:

2024-11-08T17:03:09.226 INF AUTH  attempting to authenticate find_auth_fields="basic-digest"
2024-11-08T17:03:09.226 INF AUTH  loading login page LoginURL="https://target.example.com"
2024-11-08T17:03:10.619 INF AUTH  verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (auto-detected)"
2024-11-08T17:03:10.619 INF AUTH  requirement is satisfied, HTTP login request returned status code 200 want="HTTP status code < 400" url="https://target.example.com/"
2024-11-08T17:03:10.623 INF AUTH  requirement is satisfied, did not detect a login form want="no login form found (auto-detected)"
2024-11-08T17:03:10.623 INF AUTH  authentication token cookies names=""
2024-11-08T17:03:10.623 INF AUTH  authentication token storage events keys=""
2024-11-08T17:03:10.623 INF AUTH  requirement is satisfied, basic authentication detected want="has authentication token"
2024-11-08T17:03:11.230 INF AUTH  login attempt succeeded

ログインフォームに移動するためにクリックする

DASTがログインフォームにアクセスできるように、DAST_AUTH_URLからクリックする要素のパスを提供するようにDAST_AUTH_BEFORE_LOGIN_ACTIONSを定義します。この方法は、ポップアップ（モーダル）ウィンドウでログインフォームを表示するアプリケーションや、ログインフォームに一意のURLがない場合に適しています。

例:

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_BEFORE_LOGIN_ACTIONS: "css:.navigation-menu,css:.login-menu-item"

ログインフォームの送信後に追加のアクションを実行する

サインインフォームの送信後、検証前、認証の詳細が記録されるときに実行するアクションのシーケンスを提供するようにDAST_AUTH_AFTER_LOGIN_ACTIONSを定義します。これは、「サインインしたままにする」ダイアログを過ぎて進むために使用できます。

アクション形式
要素をクリックしますclick(on=<selector>)
ドロップダウンからオプションを選択しますselect(option=<selector>)

アクションはコンマで区切られます。セレクターの詳細については、要素のセレクターを見つけるを参照してください。

例:

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_AFTER_LOGIN_ACTIONS: "select(option=id:accept-yes),click(on=id:continue-button)"

ログアウトURLの除外

認証されたスキャンの実行中にDASTがログアウトURLをクロールすると、ユーザーはログアウトされ、スキャンの残りの部分が認証されなくなります。したがって、CI/CD変数DAST_SCOPE_EXCLUDE_URLSを使用してログアウトURLを除外することをお勧めします。DASTは除外されたURLにアクセスしないため、ユーザーはログインしたままになります。

指定されたURLは、絶対URL、またはDAST_TARGET_URLのベースパスに対するURLパスの正規表現にすることができます。例:

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com/welcome/home"
    DAST_SCOPE_EXCLUDE_URLS: "https://example.com/logout,/user/.*/logout"

要素のセレクターを見つける

セレクターは、ブラウザーのページに表示される要素の場所を指定するために、CI/CD変数によって使用されます。セレクターの形式は、type:search stringです。DASTは、タイプに基づいて検索文字列を使用してセレクターを検索します。

セレクタータイプ例説明
csscss:.password-field提供されたCSSセレクターを持つHTML要素を検索します。セレクターは、パフォーマンス上の理由から、できる限り具体的にする必要があります。
idid:element指定された要素IDを持つHTML要素を検索します。
namename:element指定された要素名を持つHTML要素を検索します。
xpathxpath://input[@id="my-button"]/a指定されたXPathを持つHTML要素を検索します。XPath検索は、他の検索よりもパフォーマンスが低いと予想されます。

Google Chromeでセレクターを見つける

Chrome DevTools要素セレクターツールは、セレクターを見つける効果的な方法です。

  1. Chromeを開き、セレクターを見つけたいページ（たとえば、サイトのログインページ）に移動します。
  2. Chrome DevToolsのElementsタブを、macOSではキーボードショートカットCommand+Shift+C、WindowsまたはLinuxではControl+Shift+Cで開きます。
  3. Select an element in the page to select itツールを選択します。 search-elements
  4. セレクターを知りたいページ上のフィールドを選択します。
  5. ツールがアクティブになったら、詳細を表示したいフィールドをハイライトします。 highlight
  6. ハイライト表示されると、セレクターの適切な候補となる属性など、要素の詳細を確認できます。

この例では、id="user_login"が良い候補と思われます。DAST_AUTH_USERNAME_FIELD: "id:user_login"を設定することで、これをDASTのユーザー名フィールドとしてセレクターとして使用できます。

適切なselectorを選択してください

セレクターを適切に選択すると、アプリケーションの変更に強いスキャンになります。

優先順位に従って、セレクターとして次を選択する必要があります:

  • idフィールドこれらのフィールドは通常、ページ上で一意であり、めったに変更されません。
  • nameフィールドこれらのフィールドは通常、ページ上で一意であり、めったに変更されません。
  • フィールドに固有のclass値。たとえば、ユーザー名フィールドのusernameクラスの"css:.username"などのselectorです。
  • フィールド固有のデータ属性の存在。たとえば、ユーザー名フィールドにdata-usernameフィールドに値がある場合の"css:[data-username]"などのselectorです。
  • 複数のclass階層値。たとえば、クラスusernameを持つ要素が複数あるが、クラスlogin-formを持つ要素内にネストされた要素が1つしかない場合の"css:.login-form .username"などのselectorです。

特定のフィールドを特定するためにセレクターを使用する場合は、次の検索は避けてください:

  • 動的に生成されるid、name、attribute、class、またはvalue。
  • column-10やdark-greyなどの一般的なクラス名。
  • XPath検索は、他のselector検索よりもパフォーマンスが低いためです。
  • css:*やxpath://*で始まる検索などの、スコープ外検索。

認証が成功したかの検証

DASTがログインフォームを送信した後、認証が成功したかどうかを判断するための検証プロセスが実行されます。認証が成功しなかった場合、スキャンはエラーで停止します。

ログインフォームの送信後、次の場合に認証が失敗したと判断されます:

  • ログイン送信HTTPレスポンスのステータスコードが400または500シリーズである。
  • いずれかの検証チェックが失敗する。
  • 十分なランダム値を持つ認証トークンが、認証プロセス中に設定されていません。

検証チェック

検証チェックは、認証が完了するとブラウザーの状態に対してチェックを実行し、認証が成功したかどうかをさらに判断します。

検証チェックが設定されていない場合、DASTはログインフォームがないかどうかをテストします。

URLに基づいて検証

DAST_AUTH_SUCCESS_IF_AT_URLを、ログインフォームが正常に送信された後にブラウザータブに表示されるURLとして定義します。

DASTは、検証URLを認証後のブラウザーのURLと比較します。同じでない場合、認証は失敗します。

例:

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_SUCCESS_IF_AT_URL: "https://example.com/user/welcome"

要素の有無に基づいて検証

DAST_AUTH_SUCCESS_IF_ELEMENT_FOUNDを、ログインフォームが正常に送信された後に表示されるページ上の1つまたは複数の要素を検索するselectorとして定義します。要素が見つからない場合、認証は失敗します。ログインが失敗した場合に表示されるページでselectorを検索すると、要素は返されません。

例:

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND: "css:.welcome-user"

ログインフォームがないことに基づいて検証

DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORMを"true"として定義し、ログインフォームが正常に送信された後に表示されるページで、DASTがログインフォームを検索するように指示します。ログイン後もログインフォームが表示されている場合、認証は失敗します。

例:

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORM: "true"

認証トークン

DASTは、認証プロセス中に設定された認証トークンを記録します。認証トークンは、DASTが新しいブラウザーを開くときに読み込まれるため、スキャン全体を通して認証済みユーザーはログイン状態を維持できます。

トークンを記録するために、DASTは認証プロセス前にアプリケーションによって設定されたcookie、ローカルストレージ、およびセッションストレージの値のスナップショットを作成します。DASTは、認証後にも同じ操作を行い、その差を使用して、認証プロセスによって作成されたものを判断します。

DASTは、十分に「ランダム」な値で設定されたcookie、ローカルストレージ、およびセッションストレージの値を認証トークンと見なします。たとえば、sessionID=HVxzpS8GzMlPAc2e39uyIVzwACIuGe0Hは認証トークンと見なされますが、ab_testing_group=A1は見なされません。

CI/CD変数DAST_AUTH_COOKIE_NAMESを使用して、認証cookieの名前を指定し、DASTで使用されるランダム性チェックを回避することができます。これにより、認証プロセスがより堅牢になるだけでなく、認証トークンを検査するチェックの脆弱性チェックの精度も向上します。

例:

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

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_COOKIE_NAMES: "sessionID,refreshToken"

既知の問題

  • 認証フローにCAPTCHAが含まれている場合、DASTはCAPTCHAを回避できません。スキャン対象のアプリケーションのテスト環境で、設定されたユーザーに対してこれらをオフにします。
  • DASTは、SMSまたはバイオメトリクスを使用して、ワンタイムパスワード（OTP）で認証できません。スキャン対象のアプリケーションのテスト環境で、設定されたユーザーに対してこれらをオフにするか、ユーザーのMFAのタイプをTOTPに変更します。
  • ログイン時に認証トークンを設定しないアプリケーションには、DASTは認証できません。
  • DASTは、ユーザー名、パスワード、およびオプションのTOTPよりも多くのテキスト入力を必要とするアプリケーションには認証できません。

トラブルシューティング

ログは、認証プロセス中にDASTが何を行い、何を期待しているかについてのインサイトを提供します。詳細については、認証レポートを設定します。

特定のエラーメッセージまたは状況の詳細については、既知の問題を参照してください。

ブラウザーベースのアナライザーは、ユーザーを認証するために使用されます。高度なトラブルシューティングについては、ブラウザベースのトラブルシューティングを参照してください。

ログを読む

DAST CI/CDジョブのコンソール出力は、AUTHログモジュールを使用して、認証プロセスに関する情報を示します。たとえば、次のログは、複数ステップのログインフォームの認証が失敗したことを示しています。認証が失敗したのは、ログイン後にホームページが表示されるはずだったためです。代わりに、ログインフォームがまだ表示されていました。

2022-11-16T13:43:02.000 INF AUTH  attempting to authenticate
2022-11-16T13:43:02.000 INF AUTH  loading login page LoginURL=https://example.com/login
2022-11-16T13:43:10.000 INF AUTH  multi-step authentication detected
2022-11-16T13:43:15.000 INF AUTH  verifying if user submit was successful true_when="HTTP status code < 400"
2022-11-16T13:43:15.000 INF AUTH  requirement is satisfied, no login HTTP message detected want="HTTP status code < 400"
2022-11-16T13:43:20.000 INF AUTH  verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (no element found when searching using selector css:[id=email] or css:[id=password] or css:[id=submit])"
2022-11-24T14:43:20.000 INF AUTH  requirement is satisfied, HTTP login request returned status code 200 url=https://example.com/user/login?error=invalid%20credentials want="HTTP status code < 400"
2022-11-16T13:43:21.000 INF AUTH  requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[id=email] or css:[id=password] or css:[id=submit])"
2022-11-16T13:43:21.000 INF AUTH  login attempt failed error="authentication failed: failed to authenticate user"

認証レポートを設定する

認証レポートには、ログインの実行に使用される認証情報などの機密情報が含まれる場合があります。

認証レポートは、認証の失敗の原因を理解するために役立つCI/CDジョブアーティファクトとして保存できます。

レポートには、ログインプロセス中に実行された手順、HTTPリクエストと応答、Document Object Model（DOM）とスクリーンショットが含まれています。

dast-auth-レポート

認証デバッグレポートがエクスポートされるサンプル設定は、次のようになります:

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_REPORT: "true"

既知の問題

ログインフォームが見つかりません

DASTは、ログインページを読み込むときにログインフォームを見つけることができませんでした。これは、認証URLを読み込むことができなかったことが原因であることがよくあります。ログには、次のような重大なエラーがレポートされます:

2022-12-07T12:44:02.838 INF AUTH  loading login page LoginURL=[authentication URL]
2022-12-07T12:44:11.119 FTL MAIN  authentication failed: login form not found

推奨されるアクション:

  • HTTP応答を検査するには、認証レポートを生成します。
  • ターゲットアプリケーションの認証がデプロイされ、実行されていることを確認します。
  • DAST_AUTH_URLが正しいことを確認します。
  • GitLab RunnerがDAST_AUTH_URLにアクセスできることを確認します。
  • 使用されている場合、DAST_AUTH_BEFORE_LOGIN_ACTIONSが有効であることを確認します。

スキャンが認証済みユーザーのページをクロールしない

DASTが認証プロセス中に誤った認証トークンを取得した場合、スキャンは認証済みユーザーのページをクロールできません。Cookieとストレージの認証トークンの名前がログに書き込まれます。例:

2022-11-24T14:42:31.492 INF AUTH  authentication token cookies names=["sessionID"]
2022-11-24T14:42:31.492 INF AUTH  authentication token storage events keys=["token"]

推奨されるアクション:

  • 認証レポートを生成し、Login submitのスクリーンショットを見て、ログインが期待どおりに機能したことを確認します。
  • ログに記録された認証トークンが、アプリケーションで使用されているものであることを確認します。
  • cookieを使用して認証トークンを保存する場合は、DAST_AUTH_COOKIE_NAMESを使用して認証トークンcookieの名前を設定します。

selectorで要素が見つかりません

DASTは、ユーザー名、パスワード、最初の送信ボタン、または送信ボタン要素を見つけることができませんでした。ログには、次のような重大なエラーがレポートされます:

2022-12-07T13:14:11.545 FTL MAIN  authentication failed: unable to find elements with selector: css:#username

推奨されるアクション:

  • 認証レポートを生成して、Login pageのスクリーンショットを使用して、ページが正しく読み込まれたことを確認します。
  • ブラウザーでログインページを読み込み、DAST_AUTH_USERNAME_FIELD、DAST_AUTH_PASSWORD_FIELD、DAST_AUTH_FIRST_SUBMIT_FIELD、およびDAST_AUTH_SUBMIT_FIELDで設定されたselectorが正しいことを確認します。

ユーザーの認証に失敗しました

認証検証チェックが失敗したため、DASTは認証に失敗しました。ログには、次のような重大なエラーがレポートされます:

2022-12-07T06:39:49.483 INF AUTH  verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"
2022-12-07T06:39:49.484 INF AUTH  requirement is satisfied, HTTP login request returned status code 303 url=http://auth-manual:8090/login want="HTTP status code < 400"
2022-12-07T06:39:49.513 INF AUTH  requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"
2022-12-07T06:39:49.589 INF AUTH  login attempt failed error="authentication failed: failed to authenticate user"
2022-12-07T06:39:53.626 FTL MAIN  authentication failed: failed to authenticate user

推奨されるアクション:

  • ログでrequirement is unsatisfiedを探します。適切なエラーに応答します。

要件が満たされていません。ログインフォームが見つかりました

アプリケーションは通常、ユーザーがログインするとダッシュボードを表示し、ユーザー名またはパスワードが正しくない場合、エラーメッセージとともにログインフォームを表示します。

このエラーは、DASTがユーザーを認証した後に表示されるページでログインフォームを検出した場合に発生し、ログイン試行が失敗したことを示します。

2022-12-07T06:39:49.513 INF AUTH  requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"

推奨されるアクション:

  • 使用されるユーザー名とパスワード/認証情報が正しいことを確認します。
  • 認証レポートを生成し、Login submitのRequestが正しいことを確認します。
  • 認証レポートLogin submitリクエストと応答が空である可能性があります。これは、HTMLフォームの送信時など、ページ全体の再読み込みにつながるリクエストがない場合に発生します。これは、websocketsまたはAJAXを使用してログインフォームを送信する場合に発生します。
  • 認証済みユーザーの後に表示されるページに、ログインフォームのselectorに一致する要素が実際に含まれている場合は、DAST_AUTH_SUCCESS_IF_AT_URLまたはDAST_AUTH_SUCCESS_IF_ELEMENT_FOUNDを設定して、ログイン試行を検証する代替メソッドを使用します。

要件が満たされていません。selectorが結果を返しませんでした

DASTは、ユーザーログイン後に表示されるページのDAST_AUTH_SUCCESS_IF_ELEMENT_FOUNDで提供されているselectorに一致する要素を見つけることができません。

2022-12-07T06:39:33.239 INF AUTH  requirement is unsatisfied, searching DOM using selector returned no results want="has element css:[name=welcome]"

推奨されるアクション:

  • 認証レポートを生成し、Login submitのスクリーンショットを見て、期待されるページが表示されることを確認します。
  • DAST_AUTH_SUCCESS_IF_ELEMENT_FOUNDselectorが正しいことを確認してください。

要件が満たされていません。ブラウザーがURLにありません

DASTは、ユーザーログイン後に表示されるページに、DAST_AUTH_SUCCESS_IF_AT_URLに従って予想されるものとは異なるURLがあることを検出しました。

2022-12-07T11:28:00.241 INF AUTH  requirement is unsatisfied, browser is not at URL browser_url="https://example.com/home" want="is at url https://example.com/user/dashboard"

推奨されるアクション:

  • 認証レポートを生成し、Login submitのスクリーンショットを見て、期待されるページが表示されることを確認します。
  • DAST_AUTH_SUCCESS_IF_AT_URLが正しいことを確認します。

要件が満たされていません。HTTPログインリクエストステータスコード

ログインフォームを読み込むとき、またはフォームを送信するときのHTTP応答のステータスコードは、400（クライアントエラー）または500（サーバーエラー）でした。

2022-12-07T06:39:53.626 INF AUTH  requirement is unsatisfied, HTTP login request returned status code 502 url="https://example.com/user/login" want="HTTP status code < 400"
  • 使用されるユーザー名とパスワード/認証情報が正しいことを確認します。
  • 認証レポートを生成し、Login submitのRequestが正しいことを確認します。
  • ターゲットアプリケーションが期待どおりに機能することを確認します。

要件が満たされていません。認証トークンがありません

DASTは、認証プロセス中に作成された認証トークンを検出できませんでした。

2022-12-07T11:25:29.010 INF AUTH  authentication token cookies names=[]
2022-12-07T11:25:29.010 INF AUTH  authentication token storage events keys=[]
2022-12-07T11:25:29.010 INF AUTH  requirement is unsatisfied, no basic authentication, cookie or storage event authentication token detected want="has authentication token"

提案アクション:

  • 認証レポートを生成し、Login submitのスクリーンショットを見て、ログインが期待どおりに機能したことを確認します。
  • ブラウザーの開発者ツールを使用して、ログイン中に作成されたcookieとローカル/セッションストレージオブジェクトを調査します。十分にランダムな値で作成された認証トークンがあることを確認します。
  • cookieを使用して認証トークンを保存する場合は、DAST_AUTH_COOKIE_NAMESを使用して認証トークンcookieの名前を設定します。