DAST認証
認証スキャンは、DASTスキャンの前にユーザーをログインさせ、脆弱性を検索する際にアナライザが可能な限り多くのアプリケーションをテストできるようにします。
DAST はブラウザを使ってユーザーを認証し、ログインフォームにフォームを送信するために必要な JavaScript とスタイルを持たせます。DAST はユーザ名とパスワードのフィールドを見つけ、それぞれの値を入力します。ログインフォームが送信され、レスポンスが返されると、認証が成功したかどうかを確認する一連のチェックが行われます。DAST はターゲットアプリケーションをクロールする際に再利用できるように認証情報を保存します。
DAST が認証に失敗すると、スキャンは停止し、CI ジョブは失敗します。
認証は、シングルステップログインフォーム、マルチステップログインフォーム、シングルサインオン、および設定されたターゲットURL以外のURLへの認証に対応しています。
利用を開始
DAST認証スキャンを実行するには
- 認証の前提条件をお読みください。
- 認証されたユーザーのランディングページにターゲットウェブサイトを更新します。
- ログインフォームにユーザー名、パスワード、送信ボタンが1つのページにある場合、CI/CD変数を使用してシングルステップのログインフォーム認証を設定します。
- ログインフォームのユーザー名とパスワードフィールドが異なるページにある場合、CI/CD変数を使用してマルチステップログインフォーム認証を設定してください。
- スキャン中にユーザーがログアウトしていないことを確認してください。
前提条件
- スキャン中に認証したいユーザーのユーザー名とパスワードを持っていること。
- DASTがお客様のアプリケーションを認証できるように、既知の制限を確認しました。
- フォーム認証と HTTP認証のどちらを使用するかに応じて、前提条件を満たしています。
- 認証が成功したかどうかを確認する方法を考えました。
フォーム認証
- DAST プロキシベースアナライザまたはDAST ブラウザベースアナライザを使用しています。
- アプリケーションのログインフォームの URL を知っています。または、認証URLからログインフォームに移動する方法を知っている場合(ログインフォームに移動するためのクリックを参照)。
- DASTがそれぞれの値を入力するために使用する、ユーザ名とパスワードのHTMLフィールドのセレクタを知っていること。
- 選択されたときにログインフォームを送信する要素のセレクタを知っています。
HTTP 認証
- DASTブラウザベースのアナライザを使用している必要があります。
利用可能な CI/CD 変数
CI/CD 変数 | 種類 | 説明 |
---|---|---|
DAST_AUTH_COOKIES | 文字列です。 | 認証に使用するクッキーを指定するために、コンマで区切られたクッキー名のリストを設定します。 |
DAST_AUTH_REPORT | boolean |
true に設定すると、認証プロセス中に実行されたステップの詳細を記したレポーターを生成します。また、生成されたレポートにアクセスできるようにするには、CIジョブのアーティファクトとしてgl-dast-debug-auth-report.html を定義する必要があります。レポートの内容は、認証失敗のデバッグ時に役立ちます。 |
DAST_AUTH_TYPE 2
| 文字列です。 | 使用する認証タイプ。例:basic-digest . |
DAST_AUTH_URL 1
| URL |
DAST_USERNAME とDAST_PASSWORD は、認証スキャンを作成するためにログインフォームと共に送信されます。例:https://login.example.com . |
DAST_AUTH_VERIFICATION_LOGIN_FORM | boolean | ログインフォームが送信された後、ログインフォームが存在しないことをチェックすることで、認証が成功したことを確認します。 |
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_USERNAME とDAST_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_FIELDS | boolean | 手動ログインを試みる前にユーザー名とパスワードフィールドをクリアしないようにします。デフォルトではfalse に設定されています。 |
- オンデマンドプロキシベースの DAST スキャンで利用可能です。
- プロキシベースのスキャンでは利用できません。
対象ウェブサイトの更新
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_USERNAME
とDAST_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_USERNAME
とDAST_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_USERNAME
とDAST_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は型に基づいた検索文字列を使ってセレクタを検索します。
セレクタの種類 | 物件例 | 説明 |
---|---|---|
css | css:.password-field | 指定された CSS セレクタを持つ HTML 要素を検索します。パフォーマンス上の理由から、セレクタはできるだけ具体的であるべきです。 |
id | id:element | 指定された要素 ID を持つ HTML 要素を検索します。 |
name | name:element | 指定された要素名の HTML 要素を検索します。 |
xpath | xpath://input[@id="my-button"]/a | 指定された XPath で HTML 要素を検索します。XPath による検索は、他の検索よりもパフォーマンスが落ちることが予想されます。 |
指定なし | a.click-me | デフォルトは CSS セレクタを使った検索です。警告非推奨GitLab 15.8で廃止予定。セレクタタイプを明示的に宣言することで置き換えられます。 |
Google Chromeでセレクタを探す
Chrome DevToolsの要素セレクタツールは、セレクタを検索する効果的な方法です。
- Chromeを開き、セレクタを探したいページ(例えば、サイトのログインページなど)に移動します。
- Chrome DevToolsの
Elements
タブを、MacOSの場合はキーボードショートカットCommand + Shift + c
、Windowsの場合はCtrl + Shift + c
。 -
Select an element in the page to select it
ツールを選択します。 - セレクタを知りたいページのフィールドを選択します。
- ツールがアクティビティになった後、詳細を表示したいフィールドをハイライトします。
- ハイライトされると、セレクタの候補となる属性を含む要素の詳細を見ることができます。
この例では、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-10
やdark-grey
のような一般的なクラス名。 - XPath検索は、他のセレクタ検索よりもパフォーマンスが低いため、使用しないでください。
-
css:*
やxpath://*
で始まるような、スコープのない検索。
認証が成功したことの確認
DAST がログインフォームを送信した後、認証が成功したかどうかを判断するための検証プロセスが行われます。認証に失敗した場合、スキャンはエラーで停止します。
ログインフォームの送信後、認証が失敗したと判断されるのは以下の場合です:
検証チェック
検証チェックは、認証が完了するとブラウザの状態をチェックし、認証が成功したかどうかをさらに判断します。
検証チェックが設定されていない場合、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"
認証レポートの設定
認証レポートはCI/CDジョブのアーティファクトとして保存することができ、認証失敗の原因を理解するのに役立ちます。
レポートには、ログインプロセス中に実行されたステップ、HTTP リクエストとレスポンス、Document Object Model(DOM) およびスクリーンショットが含まれます。
認証デバッグ・レポートがエクスポートされる設定例は、以下のようになります:
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_FIELD
、DAST_PASSWORD_FIELD
、DAST_FIRST_SUBMIT_FIELD
、DAST_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 submit
のRequest
が正しいことを確認します。 - 認証レポート
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 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
のスクリーンショットを見て、ログインが期待通りに機能したことを確認してください。 - ブラウザの開発者ツールを使って、ログイン中に作成されたクッキーとローカル/セッションストレージオブジェクトを調べてください。十分にランダムな値の認証トークンが作成されていることを確認してください。
- 認証トークンの保存にクッキーを使用している場合は、
DAST_AUTH_COOKIES
を使用して認証トークンクッキーの名前を設定します。