DAST認証

caution
本番システム、本番サーバ、または本番データを含むサーバで有効な認証情報は使用しないでください。
caution
本番サーバに対して認証スキャンを実行しないでください。認証されたスキャンは、データの変更または削除、フォームの送信、リンクの追跡など、認証されたユーザーが実行できるあらゆる機能を実行できます。認証スキャンは、本番環境以外のシステムまたはサーバーに対してのみ実行してください。

認証スキャンは、DASTスキャンの前にユーザーをログインさせ、脆弱性を検索する際にアナライザが可能な限り多くのアプリケーションをテストできるようにします。

DAST はブラウザを使ってユーザーを認証し、ログインフォームにフォームを送信するために必要な JavaScript とスタイルを持たせます。DAST はユーザ名とパスワードのフィールドを見つけ、それぞれの値を入力します。ログインフォームが送信され、レスポンスが返されると、認証が成功したかどうかを確認する一連のチェックが行われます。DAST はターゲットアプリケーションをクロールする際に再利用できるように認証情報を保存します。

DAST が認証に失敗すると、スキャンは停止し、CI ジョブは失敗します。

認証は、シングルステップログインフォーム、マルチステップログインフォーム、シングルサインオン、および設定されたターゲットURL以外のURLへの認証に対応しています。

利用を開始

note
定期的にアナライザーの認証が機能していることを確認する必要があります。

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

前提条件

  • スキャン中に認証したいユーザーのユーザー名とパスワードを持っていること。
  • DASTがお客様のアプリケーションを認証できるように、既知の制限を確認しました。
  • フォーム認証と HTTP認証のどちらを使用するかに応じて、前提条件を満たしています。
  • 認証が成功したかどうかを確認する方法を考えました。

フォーム認証

HTTP 認証

利用可能な CI/CD 変数

CI/CD 変数種類説明
DAST_AUTH_COOKIES文字列です。認証に使用するクッキーを指定するために、コンマで区切られたクッキー名のリストを設定します。
DAST_AUTH_REPORTboolean true に設定すると、認証プロセス中に実行されたステップの詳細を記したレポーターを生成します。また、生成されたレポートにアクセスできるようにするには、CIジョブのアーティファクトとしてgl-dast-debug-auth-report.html を定義する必要があります。レポートの内容は、認証失敗のデバッグ時に役立ちます。
DAST_AUTH_TYPE 2 文字列です。使用する認証タイプ。例:basic-digest.
DAST_AUTH_URL 1 URL DAST_USERNAMEDAST_PASSWORD は、認証スキャンを作成するためにログインフォームと共に送信されます。例:https://login.example.com.
DAST_AUTH_VERIFICATION_LOGIN_FORMbooleanログインフォームが送信された後、ログインフォームが存在しないことをチェックすることで、認証が成功したことを確認します。
DAST_AUTH_VERIFICATION_SELECTORセレクタログインフォームが送信された後、セレクタの存在をチェックすることで、認証が成功したことを確認します。例:css:.user-photo.
DAST_AUTH_VERIFICATION_URL 1 URLログインフォームが送信された後、ブラウザの URL をチェックすることで、認証が成功したことを確認します。例:"https://example.com/loggedin_page".GitLab 13.8 で導入されました
DAST_BROWSER_PATH_TO_LOGIN_FORM 1 セレクタログインフォームにDAST_USERNAMEDAST_PASSWORD を入力する前に選択されるセレクタのカンマ区切りリスト。例:"css:.navigation-menu,css:.login-menu-item".GitLab 14.1 で導入されました
DAST_EXCLUDE_URLS 1 URL認証スキャン中にスキップするURL。カンマ区切り。正規表現構文を使用して、複数の URL に一致させることができます。例えば、.* は任意の文字列にマッチします。
DAST_FIRST_SUBMIT_FIELD文字列です。複数ページのログインプロセスで、選択されたときにユーザ名フォームを送信する要素のid またはname.例えば、css:button[type='user-submit'] 。 GitLab 12.4で導入されました
DAST_PASSWORD 1 文字列です。ウェブサイトで認証するためのパスワード。例P@55w0rd!
DAST_PASSWORD_FIELD文字列です。サインイン HTML フォームのパスワードフィールドのセレクタ。例id:password
DAST_SUBMIT_FIELD文字列です。選択されたときに、複数ページのログインプロセスのログインフォームまたはパスワードフォームを送信する要素のid またはname.例えば、css:button[type='submit'] 。 GitLab 12.4で導入されました
DAST_USERNAME 1 文字列です。ウェブサイトで認証するユーザー名。例admin
DAST_USERNAME_FIELD 1 文字列です。サインイン HTML フォームの username フィールドのセレクタ。例name:username
DAST_AUTH_DISABLE_CLEAR_FIELDSboolean手動ログインを試みる前にユーザー名とパスワードフィールドをクリアしないようにします。デフォルトではfalse に設定されています。
  1. オンデマンドプロキシベースの DAST スキャンで利用可能です。
  2. プロキシベースのスキャンでは利用できません。

対象ウェブサイトの更新

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

認証されたスキャンで最良のクロール結果を得るためには、ターゲットウェブサイトはユーザーが認証された後にのみアクセスできる URL であるべきです。多くの場合、これはユーザーがログインした後に表示されるページの URL です。

使用例:

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

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

HTTP認証の設定

Basic 認証のようなHTTP 認証スキームを使用するには、DAST_AUTH_TYPE の値をbasic-digest に設定します。Negotiate や NTLM などの他のスキームも動作するかもしれませんが、自動化されたテストカバレッジが不足しているため、公式にはサポートされていません。

設定には、CI/CD 変数DAST_AUTH_TYPE,DAST_AUTH_URL,DAST_USERNAME,DAST_PASSWORD が DAST ジョブに定義されている必要があります。固有のログイン URL を持っていない場合は、DAST_WEBSITE と同じ URL をDAST_AUTH_URL に設定してください。

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

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

セキュリティリスクがあるため、YAMLジョブ定義ファイルでDAST_USERNAMEDAST_PASSWORD を定義しないでください。代わりに、GitLab UI を使ってマスクされた CI/CD 変数として作成してください。詳細はカスタム CI/CD 変数を参照してください。プロキシベースのアナライザーは、認証メカニズムとしてBasic認証をサポートしていません。回避策として、DAST_REQUEST_HEADERS をマスクされた CI/CD 変数として設定し、適切なAuthorization ヘッダを含む値、例えばAuthorization: Basic dXNlcm5hbWU6cGFzc3dvcmQKを設定することができます。

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

シングルステップログインフォームはすべてのログインフォーム要素を1つのページに持ちます。設定にはCI/CD変数DAST_AUTH_URL,DAST_USERNAME,DAST_USERNAME_FIELD,DAST_PASSWORD,DAST_PASSWORD_FIELD,DAST_SUBMIT_FIELD がDASTジョブに対して定義されている必要があります。

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

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

dast:
  variables:
    DAST_WEBSITE: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_USERNAME_FIELD: "css:[name=username]"
    DAST_PASSWORD_FIELD: "css:[name=password]"
    DAST_SUBMIT_FIELD: "css:button[type=submit]"

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

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

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

設定には CI/CD 変数が DAST ジョブに定義されている必要があります:

  • DAST_AUTH_URL
  • DAST_USERNAME
  • DAST_USERNAME_FIELD
  • DAST_FIRST_SUBMIT_FIELD
  • DAST_PASSWORD
  • DAST_PASSWORD_FIELD
  • DAST_SUBMIT_FIELD.

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

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

dast:
  variables:
    DAST_WEBSITE: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_USERNAME_FIELD: "css:[name=username]"
    DAST_FIRST_SUBMIT_FIELD: "css:button[name=next]"
    DAST_PASSWORD_FIELD: "css:[name=password]"
    DAST_SUBMIT_FIELD: "css:button[type=submit]"

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

シングルサインオンの設定(SSO)

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

DAST は、ユーザーが外部の ID プロバイダのサイトにリダイレクトされてログインする認証プロセスをサポートしています。DAST 認証の既知の制限を確認して、SSO 認証プロセスがサポートされているかどうかを判断してください。

クリックするとログインフォームに移動します

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

使用例:

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

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

ログアウトURLの除外

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

指定された URL は絶対 URL、またはDAST_WEBSITE のベースパスからの相対 URL パスの正規表現です:

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

dast:
  variables:
    DAST_WEBSITE: "https://example.com/welcome/home"
    DAST_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 による検索は、他の検索よりもパフォーマンスが落ちることが予想されます。
指定なしa.click-meデフォルトは CSS セレクタを使った検索です。警告非推奨GitLab 15.8で廃止予定。セレクタタイプを明示的に宣言することで置き換えられます。

Google Chromeでセレクタを探す

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

  1. Chromeを開き、セレクタを探したいページ(例えば、サイトのログインページなど)に移動します。
  2. Chrome DevToolsのElements タブを、MacOSの場合はキーボードショートカットCommand + Shift + c 、Windowsの場合はCtrl + Shift + c
  3. Select an element in the page to select it ツールを選択します。search-elements
  4. セレクタを知りたいページのフィールドを選択します。
  5. ツールがアクティビティになった後、詳細を表示したいフィールドをハイライトします。highlight
  6. ハイライトされると、セレクタの候補となる属性を含む要素の詳細を見ることができます。

この例では、id="user_login" が良い候補のようです。これをDASTのユーザー名フィールドのセレクタとして使用するには、DAST_USERNAME_FIELD: "id:user_login".

正しいセレクタの選択

セレクタを慎重に選択することで、アプリケーションの変化に強いスキャンが可能になります。

優先順位の高い順に、セレクタとして選択してください:

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

特定のフィールドを見つけるためにセレクタを使用する場合は、検索を避ける必要があります:

  • id,name,attribute,class,value のうち、動的に生成されるもの。
  • column-10dark-grey のような一般的なクラス名。
  • XPath検索は、他のセレクタ検索よりもパフォーマンスが低いため、使用しないでください。
  • css:*xpath://* で始まるような、スコープのない検索。

認証が成功したことの確認

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

ログインフォームの送信後、認証が失敗したと判断されるのは以下の場合です:

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

検証チェック

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

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

URLに基づいて検証

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

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

使用例:

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

dast:
  variables:
    DAST_WEBSITE: "https://example.com"
    DAST_AUTH_VERIFICATION_URL: "https://example.com/user/welcome"

要素の有無による検証

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

使用例:

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

dast:
  variables:
    DAST_WEBSITE: "https://example.com"
    DAST_AUTH_VERIFICATION_SELECTOR: "css:.welcome-user"

ログインフォームがない場合の検証

DAST_AUTH_VERIFICATION_LOGIN_FORM"true" と定義すると、ログインフォームが正常に送信された後に表示されるページで、DAST がログインフォームを検索することを示します。ログイン後にログインフォームがまだ存在する場合、認証は失敗です。

使用例:

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

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

認証トークン

DASTは認証プロセス中に設定された認証トークンを記録します。認証トークンは、DASTが新しいブラウザを開いたときに読み込まれるため、ユーザーはスキャン中ずっとログインしたままにすることができます。

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

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

CI/CD 変数DAST_AUTH_COOKIES を使って認証クッキーの名前を指定し、DAST によって使われるランダム性チェックをバイパスすることができます。これは認証プロセスをより堅牢にするだけでなく、認証トークンを検査する検査の脆弱性検査の精度を高めることができます。

使用例:

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

dast:
  variables:
    DAST_WEBSITE: "https://example.com"
    DAST_AUTH_COOKIES: "sessionID,refreshToken"

既知の制限

  • 認証フローにCAPTCHAが含まれている場合、DASTはCAPTCHAをバイパスできません。スキャンするアプリケーションのテスト環境では、これらをオフにしてください。
  • DASTは、SMS、生体認証、認証アプリを使用したワンタイムパスワード((OTP) )のような多要素認証を処理できません。スキャンするアプリケーションのテスト環境では、これらをオフにしてください。
  • ログイン時に認証トークンが設定されないアプリケーションでは、DASTは認証できません。
  • DASTは、2つ以上の入力が必要なアプリケーションに対しては認証できません。ユーザー名とパスワードの2つの入力が必要です。

トラブルシューティング

ログは、認証プロセス中に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"

認証レポートの設定

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

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

レポートには、ログインプロセス中に実行されたステップ、HTTP リクエストとレスポンス、Document Object Model(DOM) およびスクリーンショットが含まれます。

dast-auth-report

認証デバッグ・レポートがエクスポートされる設定例は、以下のようになります:

dast:
  variables:
    DAST_WEBSITE: "https://example.com"
    DAST_AUTH_REPORT: "true"
  artifacts:
    paths: [gl-dast-debug-auth-report.html]
    when: always

既知の問題

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

ログインページの読み込み時にDASTがログインフォームを見つけられませんでした。ログには次のような致命的なエラーがレポーターされます:

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_BROWSER_PATH_TO_LOGIN_FORM が使用されている場合は有効であることを確認します。

スキャンが認証されたページをクロールしません。

DASTが認証プロセス中に間違った認証トークンをキャプチャした場合、スキャンは認証されたページをクロールできません。クッキーとストレージ認証トークンの名前はログに書き込まれます。例えば

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 のスクリーンショットを見て、ログインが期待どおりに機能したことを確認します。
  • ログに記録された認証トークンが、アプリケーションで使用されているものであることを確認してください。
  • 認証トークンの保存にクッキーを使用している場合は、DAST_AUTH_COOKIES を使用して認証トークンクッキーの名前を設定します。

セレクタで要素が見つかりません。

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

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

推奨されるアクション:

  • Login page のスクリーンショットを使用して認証レポートを作成し、ページが正しく読み込まれたことを確認します。
  • ブラウザでログインページをロードし、DAST_USERNAME_FIELDDAST_PASSWORD_FIELDDAST_FIRST_SUBMIT_FIELDDAST_SUBMIT_FIELD で設定されたセレクタが正しいことを確認します。

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

ログイン確認チェックに失敗したため、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 submitRequest が正しいことを確認します。
  • 認証レポートLogin submit のリクエストとレスポンスが空である可能性があります。これは、HTML フォームを送信するときのリクエストなど、ページ全体をリロードするようなリクエストがない場合に Pages が発生します。これは、ウェブソケットまたはAJAXを使用してログインフォームを送信する場合に発生します。
  • 純粋にユーザー認証後に表示されるページにログインフォームのセレクタに一致する要素がある場合は、DAST_AUTH_VERIFICATION_URL またはDAST_AUTH_VERIFICATION_SELECTOR を設定して、ログイン試行を検証する別の方法を使用してください。

要件が満たされず、セレクタが結果を返しませんでした。

DAST は、ユーザーログイン後に表示されるページで、DAST_AUTH_VERIFICATION_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_VERIFICATION_SELECTORセレクタが正しいことを確認してください。

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

DAST は、ユーザーログイン後に表示されるページが、DAST_AUTH_VERIFICATION_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_VERIFICATION_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 submitRequest が正しいことを確認します。
  • ターゲット・アプリケーションが期待どおりに動作することを確認します。

要件が満たされていない、認証トークンがない

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 のスクリーンショットを見て、ログインが期待通りに機能したことを確認してください。
  • ブラウザの開発者ツールを使って、ログイン中に作成されたクッキーとローカル/セッションストレージオブジェクトを調べてください。十分にランダムな値の認証トークンが作成されていることを確認してください。
  • 認証トークンの保存にクッキーを使用している場合は、DAST_AUTH_COOKIES を使用して認証トークンクッキーの名前を設定します。