APIファジングジョブのトラブルシューティング
APIファジングジョブがN時間後にタイムアウトします
大規模なリポジトリの場合、APIファジングジョブはLinux上の小規模なホストされたランナーでタイムアウトする可能性があります。これはデフォルトで設定されています。ジョブでこれが発生する場合は、より大規模なランナーにスケールアップする必要があります。
支援が必要な場合は、次のドキュメントのセクションを参照してください:
APIファジングジョブの完了に時間がかかりすぎる
パフォーマンスの調整とテスト速度を参照してください
エラー: Error waiting for API fuzzing 'http://127.0.0.1:5000' to become available
特定の条件下でバックグラウンドプロセスが失敗する可能性のある、v1.6.196以前のバージョンのAPIファジングアナライザーにはバグが存在します。解決策は、APIファジングアナライザーの新しいバージョンにアップデートすることです。
バージョン情報は、apifuzzer_fuzzジョブのジョブ詳細にあります。
v1.6.196以降のバージョンで問題が発生している場合は、サポートに連絡して、次の情報を提供してください:
- このトラブルシューティングセクションを参照し、問題を動的解析チームにエスカレーションするように依頼してください。
- ジョブの完全なコンソール出力。
- ジョブアーティファクトとして利用可能な
gl-api-security-scanner.logファイル。ジョブ詳細ページの右側のパネルで、閲覧ボタンを選択します。 .gitlab-ci.ymlファイルからのapifuzzer_fuzzジョブ定義。
エラーメッセージ
- GitLab 15.6以降では、
Error waiting for API Fuzzing 'http://127.0.0.1:5000' to become available - GitLab 15.5以前、
Error waiting for API Security 'http://127.0.0.1:5000' to become available。
Failed to start session with scanner. Please retry, and if the problem persists reach out to support.
APIファジングエンジンは、スキャナーアプリケーションコンポーネントとの接続を確立できない場合に、エラーメッセージを出力します。エラーメッセージは、apifuzzer_fuzzジョブのジョブ出力ウィンドウに表示されます。この問題の一般的な原因は、バックグラウンドコンポーネントが選択されたポートを既に使用中のため使用できないことです。このエラーは、タイミングが関係している場合(参照条件)に断続的に発生する可能性があります。この問題は、他のサービスがコンテナにマップされてポートの競合が発生している場合に、Kubernetes環境で最も頻繁に発生します。
解決策に進む前に、ポートが既に使用されていたためにエラーメッセージが生成されたことを確認することが重要です。これが原因であることを確認するには:
ジョブコンソールに移動します。
アーティファクト
gl-api-security-scanner.logを探します。ダウンロードを選択してすべてのアーティファクトをダウンロードしてからファイルを検索するか、閲覧を選択して直接検索を開始できます。テキストエディターでファイル
gl-api-security-scanner.logを開きます。ポートが既に使用されていたためにエラーメッセージが生成された場合は、ファイルに次のようなメッセージが表示されます:
Failed to bind to address http://127.0.0.1:5500: address already in use.GitLab 15.4以前:
Failed to bind to address http://[::]:5000: address already in use.
前のメッセージのテキストhttp://[::]:5000は、場合によっては異なり、たとえばhttp://[::]:5500またはhttp://127.0.0.1:5500になる可能性があります。エラーメッセージの残りの部分が同じである限り、ポートが既に使用されていると見なしても問題ありません。
ポートが既に使用されているという証拠が見つからない場合は、ジョブコンソール出力に表示される同じエラーメッセージに対処する他のトラブルシューティングセクションを確認してください。他にオプションがない場合は、適切なチャンネルを通じて、遠慮なくサポートを受けるか、改善をリクエストしてください。
問題がポートが既に使用されていたために発生したことを確認したら。次に、GitLab 15.5以降は、設定変数FUZZAPI_API_PORTを導入しました。この設定変数を使用すると、スキャナーバックグラウンドコンポーネントの固定ポート番号を設定できます。
解決策:
.gitlab-ci.ymlファイルが、設定変数FUZZAPI_API_PORTを定義していることを確認してください。FUZZAPI_API_PORTの値を、1024より大きい使用可能なポート番号に更新します。新しい値がGitLabで使用されていないことを確認することをお勧めします。GitLabで使用するポートの完全なリストについては、パッケージのデフォルトを参照してください。
エラー: Errors were found during validation of the document using the published OpenAPI schema
APIファジングジョブの開始時に、OpenAPI仕様は公開されたスキーマに対して検証されます。このエラーは、提供されたOpenAPI仕様に検証エラーがある場合に表示されます:
Error, the OpenAPI document is not valid.
Errors were found during validation of the document using the published OpenAPI schemaOpenAPI仕様を手動で作成するとき、およびスキーマを生成するときにエラーが発生する可能性があります。
自動的に生成されるOpenAPI仕様の場合、検証エラーは、多くの場合、コード注釈の欠落が原因です。
エラーメッセージ
Error, the OpenAPI document is not valid. Errors were found during validation of the document using the published OpenAPI schemaOpenAPI 2.0 schema validation error ...OpenAPI 3.0.x schema validation error ...
解決策:
For generated OpenAPI Specifications(生成されたOpenAPI仕様の場合)
- 検証エラーを特定します。
- Swaggerエディターを使用して、仕様の検証の問題を特定します。Swaggerエディターの視覚的な性質により、変更する必要がある内容を理解しやすくなります。
- または、ログ出力をチェックして、スキーマの検証の警告を探すこともできます。それらには、
OpenAPI 2.0 schema validation errorやOpenAPI 3.0.x schema validation errorなどのメッセージがプレフィックスとして付いています。失敗した各検証は、locationとdescriptionに関する追加情報を提供します。JSONスキーマ検証メッセージは複雑になる可能性があり、エディターはスキーマドキュメントの検証に役立ちます。
- フレームワーク/ 技術スタックが使用しているOpenAPI生成のドキュメントをレビューします。正しいOpenAPIドキュメントを作成するために必要な変更を特定します。
- 検証の問題が解決されたら、パイプラインを再実行します。
For manually created OpenAPI Specifications(手動で作成されたOpenAPI仕様の場合)
- 検証エラーを特定します。
- 最も簡単な解決策は、視覚的なツールを使用してOpenAPIドキュメントを編集および検証することです。たとえば、Swaggerエディターは、スキーマエラーと可能な解決策を強調表示します。
- または、ログ出力をチェックして、スキーマの検証の警告を探すこともできます。それらには、
OpenAPI 2.0 schema validation errorやOpenAPI 3.0.x schema validation errorなどのメッセージがプレフィックスとして付いています。失敗した各検証は、locationとdescriptionに関する追加情報を提供します。検証の失敗をそれぞれ修正してから、OpenAPIドキュメントを再送信します。JSONスキーマ検証メッセージは複雑になる可能性があり、エディターはスキーマドキュメントの検証に役立ちます。
- 検証の問題が解決されたら、パイプラインを再実行します。
Failed to start scanner session (version header not found)
APIファジングエンジンは、スキャナーアプリケーションコンポーネントとの接続を確立できない場合に、エラーメッセージを出力します。エラーメッセージは、apifuzzer_fuzzジョブのジョブ出力ウィンドウに表示されます。この問題の一般的な原因は、FUZZAPI_API変数をデフォルトから変更することです。
エラーメッセージ
Failed to start scanner session (version header not found).
解決策:
.gitlab-ci.ymlファイルからFUZZAPI_API変数を削除します。値は、APIファジングCI/CDテンプレートから継承されます。手動で値を設定する代わりに、この方法をお勧めします。- 変数の削除が不可能な場合は、APIファジングCI/CDテンプレートの最新バージョンでこの値が変更されたかどうかを確認してください。その場合は、
.gitlab-ci.ymlファイル内の値を更新します。
Application cannot determine the base URL for the target API
APIファジングアナライザーは、OpenAPIドキュメントを調べた後、ターゲットAPIを判別できない場合にエラーメッセージを出力します。このエラーメッセージは、ターゲットAPIが.gitlab-ci.ymlファイルに設定されていない場合、environment_url.txtファイルで使用できない場合、およびOpenAPIドキュメントを使用して計算できなかった場合に表示されます。
APIファジングアナライザーがさまざまなソースをチェックするときに、ターゲットAPIを取得しようとする優先順位があります。最初に、FUZZAPI_TARGET_URLを使用しようとします。環境変数が設定されていない場合、APIファジングアナライザーはenvironment_url.txtファイルの使用を試みます。environment_url.txtファイルがない場合、APIファジングアナライザーは、OpenAPIドキュメントの内容と、FUZZAPI_OPENAPIで提供されるURL(URLが提供されている場合)を使用して、ターゲットAPIを計算しようとします。
最適な解決策は、ターゲットAPIがデプロイごとに変更されるかどうかによって異なります:
- ターゲットAPIが各デプロイで同じ(静的環境)場合は、静的環境ソリューションを使用します。
- ターゲットAPIがデプロイごとに変更される場合は、動的環境ソリューションを使用します。
静的環境ソリューション
このソリューションは、ターゲットAPI URLが変更されない(静的)パイプライン用です。
Add environmental variable(環境変数を追加)
ターゲットAPIが同じままである環境の場合は、FUZZAPI_TARGET_URL環境変数を使用してターゲットURLを指定することをお勧めします。.gitlab-ci.ymlファイルで、変数FUZZAPI_TARGET_URLを追加します。変数は、APIテストターゲットのベースURLに設定する必要があります。次に例を示します:
stages:
- fuzz
include:
- template: API-Fuzzing.gitlab-ci.yml
variables:
FUZZAPI_TARGET_URL: http://test-deployment/
FUZZAPI_OPENAPI: test-api-specification.json動的環境ソリューション
動的環境では、ターゲットAPIはデプロイごとに変更されます。この場合、複数の可能な解決策があります。動的環境を扱う場合は、environment_url.txtファイルを使用することをお勧めします。
Use environment_url.txt(environment_url.txtを使用)
各パイプライン中にターゲットAPI URLが変更される動的環境をサポートするために、APIファジングは、使用するURLを含むenvironment_url.txtファイルの使用をサポートします。このファイルはリポジトリにチェックインされませんが、テストターゲットをデプロイするジョブによってパイプライン中に作成され、パイプライン内の以降のジョブで使用できるアーティファクトとして収集されます。environment_url.txtファイルを作成するジョブは、APIファジングジョブの前に実行する必要があります。
- プロジェクトのルートにある
environment_url.txtファイルにベースURLを追加して、テストターゲットデプロイメントジョブを変更します。 - アーティファクトとして
environment_url.txtを収集するテストターゲットデプロイメントジョブを変更します。
例:
deploy-test-target:
script:
# Perform deployment steps
# Create environment_url.txt (example)
- echo http://${CI_PROJECT_ID}-${CI_ENVIRONMENT_SLUG}.example.org > environment_url.txt
artifacts:
paths:
- environment_url.txt無効なスキーマでOpenAPIを使用する
ドキュメントが無効なスキーマで自動生成される場合、またはタイムリーに手動で編集できない場合があります。これらのシナリオでは、APIファジングは、変数FUZZAPI_OPENAPI_RELAXED_VALIDATIONを設定することにより、緩和された検証を実行できます。予期しない動作を防ぐために、完全に準拠したOpenAPIドキュメントを提供することをお勧めします。
非準拠のOpenAPIファイルを編集する
OpenAPI仕様に準拠していない要素を検出して修正するには、エディターを使用することをお勧めします。エディターは通常、ドキュメントの検証、およびスキーマ準拠のOpenAPIドキュメントを作成するための提案を提供します。推奨されるエディターは次のとおりです:
| エディター | OpenAPI 2.0 | OpenAPI 3.0.x | OpenAPI 3.1.x |
|---|---|---|---|
| Swaggerエディター | YAML、JSON | YAML、JSON | YAML、JSON |
| Stoplight Studio | YAML、JSON | YAML、JSON | YAML、JSON |
OpenAPIドキュメントが手動で生成される場合は、エディターにドキュメントを読み込むみ、準拠していないものをすべて修正します。ドキュメントが自動的に生成される場合は、エディターに読み込むんでスキーマの問題を特定し、アプリケーションに移動して、使用しているフレームワークに基づいて修正を実行します。
OpenAPIの緩和された検証を有効にする
緩和された検証は、OpenAPIドキュメントがOpenAPI仕様を満たすことができないが、異なるツールで使用するのに十分なコンテンツがまだある場合を対象としています。検証は実行されますが、ドキュメントスキーマに関しては厳密ではありません。
APIファジングは、OpenAPI仕様に完全に準拠していないOpenAPIドキュメントも消費しようとすることができます。緩和された検証を実行するようにAPIファジングアナライザーに指示するには、変数FUZZAPI_OPENAPI_RELAXED_VALIDATIONに任意の値(たとえば、以下)を設定します:
stages:
- fuzz
include:
- template: API-Fuzzing.gitlab-ci.yml
variables:
FUZZAPI_PROFILE: Quick-10
FUZZAPI_TARGET_URL: http://test-deployment/
FUZZAPI_OPENAPI: test-api-specification.json
FUZZAPI_OPENAPI_RELAXED_VALIDATION: 'On'No operation in the OpenAPI document is consuming any supported media type
APIファジングは、OpenAPIドキュメントで指定されたメディアタイプを使用してリクエストを生成します。サポートされているメディアタイプがないためにリクエストを作成できない場合は、エラーがスローされます。
エラーメッセージ
Error, no operation in the OpenApi document is consuming any supported media type. Check 'OpenAPI Specification' to check the supported media types.
解決策:
- OpenAPI仕様セクションで、サポートされているメディアタイプをレビューします。
- OpenAPIドキュメントを編集して、サポートされているメディアタイプのいずれかを許可するように、少なくとも特定の操作を許可します。または、サポートされているメディアタイプをOpenAPIドキュメントレベルで設定し、すべての操作に適用することもできます。このステップでは、サポートされているメディアタイプがアプリケーションで受け入れられるように、アプリケーションを変更する必要がある場合があります。
エラー: The SSL connection could not be established, see inner exception.
APIファジングは、古いプロトコルや暗号など、幅広いTLS設定と互換性があります。広範なサポートにもかかわらず、次のような接続エラーが発生する可能性があります:
Error, error occurred trying to download `<URL>`:
There was an error when retrieving content from Uri:' <URL>'.
Error:The SSL connection could not be established, see inner exception.このエラーは、APIファジングが、指定されたURLのサーバーとの安全な接続を確立できなかったために発生します。
この問題を解決するには:
エラーメッセージのホストが非TLS接続をサポートしている場合は、設定でhttps://をhttp://に変更します。たとえば、次の設定でエラーが発生した場合:
stages:
- fuzz
include:
- template: API-Fuzzing.gitlab-ci.yml
variables:
FUZZAPI_TARGET_URL: https://test-deployment/
FUZZAPI_OPENAPI: https://specs/openapi.jsonFUZZAPI_OPENAPIのプレフィックスをhttps://からhttp://に変更します:
stages:
- fuzz
include:
- template: API-Fuzzing.gitlab-ci.yml
variables:
FUZZAPI_TARGET_URL: https://test-deployment/
FUZZAPI_OPENAPI: http://specs/openapi.jsonURLにアクセスするために非TLS接続を使用できない場合は、サポートチームに連絡して支援を求めてください。
testssl.shツールを使用して調査を迅速化できます。bashシェルと、影響を受けるサーバーへの接続を備えたマシンから:
- 最新リリースの
zipファイルまたはtar.gzファイルをダウンロードし、https://github.com/drwetter/testssl.sh/releasesから抽出します。 ./testssl.sh --log https://specsを実行します。- ログファイルをサポートチケットに添付してください。
ERROR: Job failed: failed to pull image
このエラーメッセージは、アクセスするために認証が必要なコンテナレジストリからイメージをプルするときに発生します(公開されていません)。
ジョブコンソール出力では、エラーは次のようになります:
Running with gitlab-runner 15.6.0~beta.186.ga889181a (a889181a)
on blue-2.shared.runners-manager.gitlab.com/default XxUrkriX
Resolving secrets
00:00
Preparing the "docker+machine" executor
00:06
Using Docker executor with image registry.gitlab.com/security-products/api-security:2 ...
Starting service registry.example.com/my-target-app:latest ...
Pulling docker image registry.example.com/my-target-app:latest ...
WARNING: Failed to pull image with policy "always": Error response from daemon: Get https://registry.example.com/my-target-app/manifests/latest: unauthorized (manager.go:237:0s)
ERROR: Job failed: failed to pull image "registry.example.com/my-target-app:latest" with specified policies [always]: Error response from daemon: Get https://registry.example.com/my-target-app/manifests/latest: unauthorized (manager.go:237:0s)エラーメッセージ
- GitLab 15.9以前では、
ERROR: Job failed: failed to pull imageの後にError response from daemon: Get IMAGE: unauthorizedが続きます。
解決策:
認証情報は、プライベートコンテナレジストリからイメージにアクセスするドキュメントセクションで概説されている方法を使用して提供されます。使用される方法は、コンテナレジストリプロバイダーとその設定によって決定されます。クラウドプロバイダー(Azure, Google Could(GCP)、AWSなど)が提供するコンテナレジストリを使用している場合は、プロバイダーのドキュメントで、認証方法を確認してください。
次の例では、静的に定義された認証情報を使用しています。この例では、コンテナレジストリはregistry.example.comで、イメージはmy-target-app:latestです。
DOCKER_AUTH_CONFIGの変数の値を計算する方法については、DOCKER_AUTH_CONFIGデータを特定する方法をお読みください。設定変数DOCKER_AUTH_CONFIGには、適切な認証情報を提供するためのDocker JSON設定が含まれています。たとえば、プライベートコンテナレジストリregistry.example.comに認証情報abcdefghijklmnでアクセスするには、Docker JSONは次のようになります:{ "auths": { "registry.example.com": { "auth": "abcdefghijklmn" } } }DOCKER_AUTH_CONFIGをCI/CD変数として追加します。.gitlab-ci.ymlファイルに設定変数を直接追加する代わりに、プロジェクトのCI/CD変数を作成する必要があります。ジョブを再実行すると、静的に定義された認証情報を使用して、プライベートコンテナレジストリ
registry.example.comにサインインし、イメージmy-target-app:latestをプルできます。成功した場合、ジョブコンソールに次のような出力が表示されます:Running with gitlab-runner 15.6.0~beta.186.ga889181a (a889181a) on blue-4.shared.runners-manager.gitlab.com/default J2nyww-s Resolving secrets 00:00 Preparing the "docker+machine" executor 00:56 Using Docker executor with image registry.gitlab.com/security-products/api-security:2 ... Starting service registry.example.com/my-target-app:latest ... Authenticating with credentials from $DOCKER_AUTH_CONFIG Pulling docker image registry.example.com/my-target-app:latest ... Using docker image sha256:139c39668e5e4417f7d0eb0eeb74145ba862f4f3c24f7c6594ecb2f82dc4ad06 for registry.example.com/my-target-app:latest with digest registry.example.com/my-target- app@sha256:2b69fc7c3627dbd0ebaa17674c264fcd2f2ba21ed9552a472acf8b065d39039c ... Waiting for services to be up and running (timeout 30 seconds)...
エラー: sudo: The "no new privileges" flag is set, which prevents sudo from running as root.
アナライザーのv5以降では、デフォルトでroot以外のユーザーが使用されます。これにより、特権操作を実行するときにsudoを使用する必要があります。
このエラーは、新しい権限の取得をコンテナの実行時に阻止する特定のコンテナデーモン設定で発生します。ほとんどの設定では、これはデフォルトの設定ではなく、通常はセキュリティ強化ガイドの一部として、特別に設定されたものです。
エラーメッセージ
このイシューは、before_scriptまたはFUZZAPI_PRE_SCRIPTの実行時に生成されるエラーメッセージで識別できます:
$ sudo apk add nodejs
sudo: The "no new privileges" flag is set, which prevents sudo from running as root.
sudo: If sudo is running in a container, you may need to adjust the container configuration to disable the flag.解決策:
このイシューは、次の方法で回避できます:
コンテナを
rootユーザーとして実行します。すべての場合で動作するとは限らないため、この設定をテストすることをお勧めします。これは、CICD設定を変更し、ジョブの出力をチェックして、whoamiがrootを返し、gitlabを返さないことを確認することで実行できます。gitlabが表示されている場合は、別の回避策を使用してください。テストが完了すると、before_scriptは削除できます。apifuzzer_fuzz: image: name: $SECURE_ANALYZERS_PREFIX/$FUZZAPI_IMAGE:$FUZZAPI_VERSION$FUZZAPI_IMAGE_SUFFIX docker: user: root before_script: - whoamiジョブコンソールの出力例:
Executing "step_script" stage of the job script Using docker image sha256:8b95f188b37d6b342dc740f68557771bb214fe520a5dc78a88c7a9cc6a0f9901 for registry.gitlab.com/security-products/api-security:5 with digest registry.gitlab.com/security-products/api-security@sha256:092909baa2b41db8a7e3584f91b982174772abdfe8ceafc97cf567c3de3179d1 ... $ whoami root $ /peach/analyzer-api-fuzzing 17:17:14 [INF] API Security: Gitlab API Security 17:17:14 [INF] API Security: ------------------- 17:17:14 [INF] API Security: 17:17:14 [INF] API Security: version: 5.7.0コンテナをラップし、ビルド時に依存関係を追加します。このオプションには、一部のお客様の要件である可能性がある、rootよりも低い権限で実行できるという利点があります。
既存のイメージをラップする新しい
Dockerfileを作成します。ARG SECURE_ANALYZERS_PREFIX ARG FUZZAPI_IMAGE ARG FUZZAPI_VERSION ARG FUZZAPI_IMAGE_SUFFIX FROM $SECURE_ANALYZERS_PREFIX/$FUZZAPI_IMAGE:$FUZZAPI_VERSION$FUZZAPI_IMAGE_SUFFIX USER root RUN pip install ... RUN apk add ... USER gitlabAPIファジングジョブの開始前に、新しいイメージをプッシュしてローカルコンテナレジストリにプッシュします。イメージは、ジョブが完了した後に削除する必要があります。
TARGET_NAME=apifuzz-$CI_COMMIT_SHA docker build -t $TARGET_IMAGE \ --build-arg "SECURE_ANALYZERS_PREFIX=$SECURE_ANALYZERS_PREFIX" \ --build-arg "FUZZAPI_IMAGE=$APISEC_IMAGE" \ --build-arg "FUZZAPI_VERSION=$APISEC_VERSION" \ --build-arg "FUZZAPI_IMAGE_SUFFIX=$APISEC_IMAGE_SUFFIX" \ . docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY docker push $TARGET_IMAGEapifuzzer_fuzzジョブを拡張し、新しいイメージ名を使用します。apifuzzer_fuzz: image: apifuzz-$CI_COMMIT_SHA一時コンテナをレジストリから削除します。コンテナイメージの削除については、このドキュメントページを参照してください。
GitLab Runnerの設定を変更し、no-new-privilegesフラグを無効にします。これはセキュリティに影響を与える可能性があるため、運用チームとセキュリティチームに相談する必要があります。
Index was outside the bounds of the array at Peach.Web.Runner.Services.RunnerOptions.GetHeaders()
このエラーメッセージは、APIファジングアナライザーがFUZZAPI_REQUEST_HEADERSまたはFUZZAPI_REQUEST_HEADERS_BASE64設定変数の値を解析中できないことを示しています。
エラーメッセージ
このイシューは、2つのエラーメッセージで識別できます。1つ目のエラーメッセージはジョブコンソールの出力に表示され、2つ目はgl-api-security-scanner.logファイルに表示されます。
ジョブコンソールからのエラーメッセージ:
05:48:38 [ERR] API Security: Testing failed: An unexpected exception occurred: Index was outside the bounds of the array.gl_api_security-scanner.logからのエラーメッセージ:
08:45:43.616 [ERR] <Peach.Web.Core.Services.WebRunnerMachine> Unexpected exception in WebRunnerMachine::Run()
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at Peach.Web.Runner.Services.RunnerOptions.GetHeaders() in /builds/gitlab-org/security-products/analyzers/api-fuzzing-src/web/PeachWeb/Runner/Services/[RunnerOptions.cs:line 362
at Peach.Web.Runner.Services.RunnerService.Start(Job job, IRunnerOptions options) in /builds/gitlab-org/security-products/analyzers/api-fuzzing-src/web/PeachWeb/Runner/Services/RunnerService.cs:line 67
at Peach.Web.Core.Services.WebRunnerMachine.Run(IRunnerOptions runnerOptions, CancellationToken token) in /builds/gitlab-org/security-products/analyzers/api-fuzzing-src/web/PeachWeb/Core/Services/WebRunnerMachine.cs:line 321
08:45:43.634 [WRN] <Peach.Web.Core.Services.WebRunnerMachine> * Session failed: An unexpected exception occurred: Index was outside the bounds of the array.
08:45:43.677 [INF] <Peach.Web.Core.Services.WebRunnerMachine> Finished testing. Performed a total of 0 requests.解決策:
このイシューは、不正な形式のFUZZAPI_REQUEST_HEADERSまたはFUZZAPI_REQUEST_HEADERS_BASE64変数が原因で発生します。予期される形式は、コンマで区切られたHeader: value構造の1つまたは複数のヘッダーです。解決策は、予期される内容に合わせて構文を修正することです。
有効な例:
Authorization: Bearer XYZX-Custom: Value,Authorization: Bearer XYZ
無効な例:
Header:,valueHeaderA: value,HeaderB:,HeaderC: valueHeader