문제 해결

N 시간 후에 API 보안 테스트 작업 시간 초과

더 큰 리포지토리의 경우, API 보안 테스트 작업이 기본적으로 설정된 Linux의 작은 호스팅 러너에서 시간 초과될 수 있습니다. 이 문제가 작업에서 발생하면 더 큰 러너로 확장해야 합니다.

다음 문서 섹션에서 도움을 받으세요:

API 보안 테스트 작업이 완료되는 데 너무 오랜 시간이 걸림

성능 조정 및 테스트 속도를 참조하세요.

오류: Error waiting for DAST API 'http://127.0.0.1:5000' to become available

v1.6.196 이전의 API 보안 테스트 분석기 버전에서 특정 조건에서 백그라운드 프로세스가 실패할 수 있는 버그가 존재합니다. 해결 방법은 API 보안 테스트 분석기를 최신 버전으로 업데이트하는 것입니다.

버전 정보는 dast_api 작업의 작업 세부정보에서 확인할 수 있습니다.

v1.6.196 이상 버전에서 이 문제가 발생하는 경우, 지원팀에 문의하고 다음 정보를 제공하세요:

  1. 이 문제 해결 섹션을 참조하고 문제를 동적 분석 팀으로 에스컬레이션해달라고 요청하세요.
  2. 작업의 전체 콘솔 출력.
  3. 작업 아티팩트로 제공되는 gl-api-security-scanner.log 파일. 작업 세부정보 페이지의 오른쪽 패널에서 찾아보기 버튼을 선택하세요.
  4. .gitlab-ci.yml 파일의 dast_api 작업 정의.

오류 메시지

  • GitLab 15.6 및 이후 버전에서는 Error waiting for DAST API '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 scanner session (version header not found)

API 보안 테스트 엔진은 스캐너 애플리케이션 구성 요소와 연결을 설정할 수 없을 때 오류 메시지를 출력합니다. 오류 메시지는 dast_api 작업의 작업 출력 창에 표시됩니다. 이 문제의 일반적인 원인은 기본값에서 APISEC_API 변수를 변경한 것입니다.

오류 메시지

  • Failed to start scanner session (version header not found).

해결 방법

  • .gitlab-ci.yml 파일에서 APISEC_API 변수를 제거하세요. 이 값은 API 보안 테스트 CI/CD 템플릿에서 상속됩니다. 수동으로 값을 설정하는 것보다 이 방법을 권장합니다.
  • 변수를 제거할 수 없는 경우, 이 값이 API 보안 테스트 CI/CD 템플릿에서 최근 버전으로 변경되었는지 확인하세요. 그렇다면 .gitlab-ci.yml 파일에서 값을 업데이트하세요.

스캐너와 세션 시작 실패. 다시 시도하고, 문제가 지속되면 지원 팀에 연락하십시오.

API 보안 테스트 엔진은 스캐너 애플리케이션 구성 요소와 연결을 설정할 수 없을 때 오류 메시지를 출력합니다. 이 오류 메시지는 dast_api 작업의 작업 출력 창에 표시됩니다. 이 문제의 일반적인 원인은 백그라운드 구성 요소가 선택한 포트를 사용할 수 없기 때문에 발생합니다. 포트가 이미 사용 중인 경우에 발생합니다. 타이밍에 따라 간헐적으로 이 오류가 발생할 수 있습니다(경쟁 조건). 이 문제는 다른 서비스가 컨테이너에 매핑되어 포트 충돌을 일으키는 Kubernetes 환경에서 가장 자주 발생합니다.

해결책을 진행하기 전에 오류 메시지가 포트가 이미 사용 중이기 때문에 발생했음을 확인하는 것이 중요합니다. 이것이 원인인지 확인하려면:

  1. 작업 콘솔로 이동합니다.

  2. 아티팩트 gl-api-security-scanner.log를 찾습니다. Download를 선택하여 모든 아티팩트를 다운로드한 후 파일을 검색하거나 Browse를 선택하여 직접 검색을 시작할 수 있습니다.

  3. 텍스트 편집기에서 gl-api-security-scanner.log 파일을 엽니다.

  4. 포트가 이미 사용 중이기 때문에 오류 메시지가 발생했다면, 파일에서 다음과 같은 메시지를 확인할 수 있습니다:

    • GitLab 15.5 및 이후 버전에서는:

      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 및 이후 버전에서는 스캐너 백그라운드 구성 요소에 대한 고정 포트 번호를 설정할 수 있는 구성 변수 APISEC_API_PORT를 도입했습니다.

해결책

  1. .gitlab-ci.yml 파일에 구성 변수 APISEC_API_PORT가 정의되어 있는지 확인합니다.

  2. APISEC_API_PORT의 값을 1024보다 큰 사용 가능한 포트 번호로 업데이트합니다. 새 값이 GitLab에서 사용 중이지 않은지 확인하는 것이 좋습니다. 패키지 기본값에서 GitLab에서 사용 중인 포트 목록을 참조하세요.

애플리케이션이 대상 API의 기본 URL을 결정할 수 없습니다

API 보안 테스트 엔진은 OpenAPI 문서를 검사한 후 대상 API를 결정할 수 없을 때 오류 메시지를 출력합니다. 이 오류 메시지는 .gitlab-ci.yml 파일에 대상 API가 설정되지 않았거나 environment_url.txt 파일에서 사용할 수 없거나 OpenAPI 문서를 사용하여 계산할 수 없을 때 표시됩니다.

API 보안 테스트 엔진이 다양한 소스를 확인하면서 대상 API를 가져오는 우선 순서가 있습니다. 먼저 APISEC_TARGET_URL을 사용하려고 시도합니다. 환경 변수가 설정되지 않은 경우, API 보안 테스트 엔진은 environment_url.txt 파일을 사용하려고 시도합니다. environment_url.txt 파일이 없으면, API 보안 테스트 엔진은 OpenAPI 문서 내용과 제공된 URL(APISEC_OPENAPI에 URL이 제공된 경우)을 사용하여 대상 API를 계산하려고 시도합니다.

가장 적합한 해결책은 배포마다 대상 API가 변경되는지 여부에 따라 다릅니다. 정적 환경에서는 각 배포마다 대상 API가 동일합니다. 이 경우 정적 환경 솔루션을 참조하세요. 배포마다 대상 API가 변경되는 경우 동적 환경 솔루션을 적용해야 합니다.

API 보안 테스트 작업이 일부 경로를 작업에서 제외합니다

일부 경로가 작업에서 제외되고 있는 경우, 다음을 확인하십시오:

  • 변수 DAST_API_EXCLUDE_URLS가 테스트하려는 작업을 제외하도록 구성되어 있지 않은지 확인합니다.

  • consumes 배열이 정의되어 있고 대상 정의 JSON 파일에서 유효한 유형을 가지고 있는지 확인합니다.

    예제 정의에 대한 내용은 예제 프로젝트 대상 정의 파일을 참조하십시오.

정적 환경 솔루션

이 솔루션은 대상 API URL이 변경되지 않는(static) 파이프라인에 대한 것입니다.

환경 변수 추가

대상 API가 동일한 환경의 경우, APISEC_TARGET_URL 환경 변수를 사용하여 대상 URL을 지정하는 것이 좋습니다. .gitlab-ci.yml 파일에 변수 APISEC_TARGET_URL을 추가하십시오. 이 변수는 API 테스트 대상의 기본 URL로 설정해야 합니다. 예를 들어:

stages:
  - dast

include:
  - template: API-Security.gitlab-ci.yml

variables:
  APISEC_TARGET_URL: http://test-deployment/
  APISEC_OPENAPI: test-api-specification.json

동적 환경 솔루션

동적 환경에서는 각기 다른 배포마다 대상 API가 변경됩니다. 이 경우 가능한 솔루션이 여러 가지가 있으며, 동적 환경을 처리할 때는 environment_url.txt 파일을 사용하는 것을 권장합니다.

environment_url.txt 사용

각 파이프라인 동안 대상 API URL이 변경되는 동적 환경을 지원하기 위해, API 보안 테스트 엔진은 사용할 URL이 포함된 environment_url.txt 파일의 사용을 지원합니다. 이 파일은 저장소에 체크인되지 않으며, 대신 테스트 대상을 배포하는 작업에서 파이프라인 중에 생성되고, 후속 작업에서 사용할 수 있는 아티팩트로 수집됩니다. environment_url.txt 파일을 생성하는 작업은 API 보안 테스트 엔진 작업 전에 실행되어야 합니다.

  1. 테스트 대상 배포 작업을 수정하여 프로젝트의 루트에 environment_url.txt 파일에 기본 URL을 추가합니다.
  2. 테스트 대상 배포 작업을 수정하여 environment_url.txt를 아티팩트로 수집하게 합니다.

예시:

deploy-test-target:
  script:
    # 배포 단계 수행
    # environment_url.txt 생성 (예)
    - echo http://${CI_PROJECT_ID}-${CI_ENVIRONMENT_SLUG}.example.org > environment_url.txt

  artifacts:
    paths:
      - environment_url.txt

잘못된 스키마로 OpenAPI 사용

문서가 유효하지 않은 스키마로 자동 생성되거나 적시에 수동으로 편집할 수 없는 경우가 있습니다. 이러한 경우, API 보안 테스트는 변수 APISEC_OPENAPI_RELAXED_VALIDATION을 설정하여 완화된 검증을 수행할 수 있습니다. 예기치 않은 동작을 방지하기 위해 완전히 호환되는 OpenAPI 문서를 제공하는 것을 권장합니다.

비합격 OpenAPI 파일 수정

OpenAPI 사양을 준수하지 않는 요소를 감지하고 수정하기 위해 편집기를 사용하는 것을 권장합니다. 편집기는 일반적으로 문서 검증과 스키마 준수 OpenAPI 문서를 생성하기 위한 제안을 제공합니다. 추천하는 편집기는 다음과 같습니다:

편집기 OpenAPI 2.0 OpenAPI 3.0.x OpenAPI 3.1.x
Stoplight Studio YAML, JSON YAML, JSON YAML, JSON
Swagger Editor YAML, JSON YAML, JSON YAML, JSON

OpenAPI 문서가 수동으로 생성된 경우, 문서를 편집기에 로드하고 비준수 사항을 수정합니다. 문서가 자동으로 생성된 경우, 편집기에 로드하여 스키마의 문제를 식별한 다음, 애플리케이션으로 이동하여 사용하는 프레임워크에 따라 수정을 수행합니다.

OpenAPI 느슨한 검증 활성화

느슨한 검증은 OpenAPI 문서가 OpenAPI 사양을 충족하지 못하는 경우에 해당하나, 다양한 도구에서 소비할 수 있을 정도로 충분한 내용을 포함하는 경우에 사용됩니다. 문서 스키마와 관련하여 덜 엄격하게 검증이 수행됩니다.

API 보안 테스트는 OpenAPI 사양을 완전히 준수하지 않는 OpenAPI 문서를 여전히 소비할 수 있습니다. API 보안 테스트가 느슨한 검증을 수행하도록 지시하려면 변수 APISEC_OPENAPI_RELAXED_VALIDATION을 임의의 값으로 설정합니다. 예를 들면:

stages:
  - dast

include:
  - template: API-Security.gitlab-ci.yml

variables:
  APISEC_PROFILE: Quick
  APISEC_TARGET_URL: http://test-deployment/
  APISEC_OPENAPI: test-api-specification.json
  APISEC_OPENAPI_RELAXED_VALIDATION: 'On'

OpenAPI 문서의 모든 작업이 지원되는 미디어 타입을 소비하지 않습니다

API 보안 테스트는 OpenAPI 문서에 명시된 미디어 타입을 사용하여 요청을 생성합니다. 지원되는 미디어 타입이 없어서 요청을 생성할 수 없으면 오류가 발생합니다.

오류 메시지

  • 오류, OpenAPI 문서의 어떤 작업도 지원되는 미디어 타입을 소비하지 않습니다. 지원되는 미디어 타입을 확인하려면 'OpenAPI Specification'을 확인하세요.

해결 방법

  1. OpenAPI Specification 섹션에서 지원되는 미디어 타입을 검토하세요.
  2. OpenAPI 문서를 수정하여 적어도 하나의 작업이 지원되는 미디어 타입을 허용하도록 하세요. 또는 지원되는 미디어 타입을 OpenAPI 문서 수준에서 설정하여 모든 작업에 적용할 수 있습니다. 이 단계에서는 응용 프로그램에서 지원되는 미디어 타입이 수용될 수 있도록 변경이 필요할 수 있습니다.

오류: SSL 연결을 설정할 수 없습니다. 내부 예외를 참조하십시오.

API 보안 테스트는 오래된 프로토콜 및 암호를 포함한 광범위한 TLS 구성과 호환됩니다.

광범위한 지원에도 불구하고 다음과 같은 연결 오류가 발생할 수 있습니다:

오류, `<URL>`를 다운로드하는 동안 오류가 발생했습니다:
Uri:' <URL>'에서 콘텐츠를 가져오는 동안 오류가 발생했습니다.
오류: SSL 연결을 설정할 수 없었습니다. 내부 예외를 참조하십시오.

이 오류는 API 보안 테스트가 주어진 URL의 서버와 보안 연결을 설정할 수 없기 때문에 발생합니다.

문제를 해결하려면:

오류 메시지의 호스트가 비TLS 연결을 지원하는 경우, 구성에서 https://를 http://로 변경하세요.

예를 들어, 다음 구성에서 오류가 발생하는 경우:

stages:
  - dast

include:
  - template: API-Security.gitlab-ci.yml

variables:
  APISEC_TARGET_URL: https://test-deployment/
  APISEC_OPENAPI: https://specs/openapi.json

APISEC_OPENAPI의 접두사를 https://에서 http://로 변경하세요:

stages:
  - dast

include:
  - template: API-Security.gitlab-ci.yml

variables:
  APISEC_TARGET_URL: https://test-deployment/
  APISEC_OPENAPI: http://specs/openapi.json

URL에 접근하기 위해 비TLS 연결을 사용할 수 없는 경우, 지원팀에 도움을 요청하세요.

조사를 신속하게 진행하려면 testssl.sh 도구를 사용할 수 있습니다. 영향을 받는 서버에 연결할 수 있는 bash 셸이 있는 머신에서:

  1. 최신 릴리스 zip 또는 tar.gz 파일을 다운로드하고 https://github.com/drwetter/testssl.sh/releases에서 압축을 푸세요.
  2. ./testssl.sh --log https://specs를 실행하세요.
  3. 로그 파일을 지원 티켓에 첨부하세요.

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가 표시됩니다.

해결책

인증 자격 증명은 Access an image from a private container registry 문서 섹션에 설명된 방법을 사용하여 제공됩니다. 사용되는 방법은 컨테이너 레지스트리 제공업체 및 해당 구성에 따라 달라집니다. Azure, Google Cloud(GCP), AWS 등과 같은 제3자에서 제공하는 컨테이너 레지스트리를 사용하는 경우, 해당 제공업체의 문서를 확인하여 컨테이너 레지스트리에 인증하는 방법에 대한 정보를 참조하십시오.

다음 예제는 statically defined credentials 인증 방법을 사용합니다. 이 예제에서 컨테이너 레지스트리는 registry.example.com이고 이미지는 my-target-app:latest입니다.

  1. DOCKER_AUTH_CONFIG 데이터의 결정 방법을 읽어 DOCKER_AUTH_CONFIG의 변수 값을 계산하는 방법을 이해하십시오. 구성 변수 DOCKER_AUTH_CONFIG는 적절한 인증 정보를 제공하기 위한 Docker JSON 구성을 포함합니다. 예를 들어, 자격 증명 abcdefghijklmn으로 개인 컨테이너 레지스트리 registry.example.com에 접근하기 위해 Docker JSON은 다음과 같습니다:

    {
    "auths": {
        "registry.example.com": {
            "auth": "abcdefghijklmn"
        }
    }
}

  2. CI/CD 변수로 DOCKER_AUTH_CONFIG를 추가하십시오. 구성 변수를 .gitlab-ci.yml 파일에 직접 추가하는 대신 프로젝트 CI/CD 변수를 생성해야 합니다.

  3. 작업을 다시 실행하면, 이제 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)...

연속 스캔 간의 차이 있는 취약점 결과

연속 스캔이 코드나 구성 변경 없이 서로 다른 취약점 결과를 반환할 수 있습니다. 이는 주로 대상 환경과 그 상태와 관련된 예측 불가능성과 스캐너가 전송하는 요청의 병렬화 때문입니다. 스캐너는 스캔 시간을 최적화하기 위해 여러 요청을 병렬로 전송하며, 이는 대상 서버가 요청에 응답하는 정확한 순서가 미리 결정되지 않았음을 의미합니다.

OS 명령이나 SQL 인젝션과 같이 요청과 응답 간의 시간 차이에 의해 감지되는 타이밍 공격 취약점은 서버가 부하 상태에 있어 주어진 임계값 내에서 테스트에 대한 응답을 제공할 수 없을 경우 감지될 수 있습니다. 서버가 부하가 없을 때 동일한 스캔 실행은 이러한 취약점에 대한 긍정적인 결과를 반환하지 않을 수 있으며, 이는 서로 다른 결과로 이어집니다. 테스트 중 최적의 서버 성능을 위한 기준을 설정하고, 성능 조정 및 테스트 속도를 프로파일링하는 것이 이러한 요인으로 인해 발생할 수 있는 허위 긍정 결과를 식별하는 데 유용할 수 있습니다.

sudo: "no new privileges" 플래그가 설정되어 있어 sudo가 root로 실행되는 것을 방지합니다.

분석기(v5)부터 기본적으로 비루트 사용자 사용이 요구됩니다. 이로 인해 권한이 필요한 작업을 수행할 때 sudo 사용이 필요합니다.

이 오류는 새로운 권한을 얻는 것을 방지하는 특정 컨테이너 데몬 설정으로 인해 발생합니다. 대부분의 설정에서 이는 기본 구성은 아니며, 보통 보안 강화 가이드의 일환으로 특별히 구성됩니다.

오류 메시지

이 문제는 before_script 또는 APISEC_PRE_SCRIPT가 실행될 때 생성된 오류 메시지로 식별할 수 있습니다:

$ sudo apk add nodejs

sudo: "no new privileges" 플래그가 설정되어 있어 sudo가 root로 실행되는 것을 방지합니다.

sudo: sudo가 컨테이너에서 실행되고 있는 경우 플래그를 비활성화하도록 컨테이너 구성을 조정해야 할 수 있습니다.

해결 방법

이 문제는 다음 방법으로 우회할 수 있습니다:

  • 컨테이너를 root 사용자로 실행하세요. 모든 경우에 작동하지 않을 수 있으므로 이 구성을 테스트해야 합니다. 이는 CICD 구성 수정 및 whoami가 gitlab이 아닌 root를 반환하는지 확인하여 수행할 수 있습니다. gitlab이 표시되면 다른 우회 방법을 사용하세요. 변경이 성공적으로 확인되면 before_script를 제거할 수 있습니다.

    api_security:
  image:
    name: $SECURE_ANALYZERS_PREFIX/$APISEC_IMAGE:$APISEC_VERSION$APISEC_IMAGE_SUFFIX
    docker:
      user: root
 before_script:
   - whoami

    예제 작업 콘솔 출력:

    "step_script" 단계의 작업 스크립트 실행
docker 이미지 sha256:8b95f188b37d6b342dc740f68557771bb214fe520a5dc78a88c7a9cc6a0f9901 사용: registry.gitlab.com/security-products/api-security:5, digest: registry.gitlab.com/security-products/api-security@sha256:092909baa2b41db8a7e3584f91b982174772abdfe8ceafc97cf567c3de3179d1 ...
$ whoami
root
$ /peach/analyzer-api-security
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

  • 컨테이너를 래핑하고 빌드 시 모든 종속성을 추가하세요. 이 옵션은 일부 고객에게 요구되는 경우에는 루트보다 낮은 권한으로 실행되는 장점이 있습니다.

    1. 기존 이미지를 래핑하는 새로운 Dockerfile을 생성합니다.

      ARG SECURE_ANALYZERS_PREFIX
ARG APISEC_IMAGE
ARG APISEC_VERSION
ARG APISEC_IMAGE_SUFFIX
FROM $SECURE_ANALYZERS_PREFIX/$APISEC_IMAGE:$APISEC_VERSION$APISEC_IMAGE_SUFFIX
USER root

RUN pip install ...
RUN apk add ...

USER gitlab

    2. API 보안 테스트 작업이 시작되기 전에 새 이미지를 빌드하고 로컬 컨테이너 레지스트리에 푸시합니다. api_security 작업이 완료된 후 이미지는 제거되어야 합니다.

      TARGET_NAME=apisec-$CI_COMMIT_SHA
docker build -t $TARGET_IMAGE \
  --build-arg "SECURE_ANALYZERS_PREFIX=$SECURE_ANALYZERS_PREFIX" \
  --build-arg "APISEC_IMAGE=$APISEC_IMAGE" \
  --build-arg "APISEC_VERSION=$APISEC_VERSION" \
  --build-arg "APISEC_IMAGE_SUFFIX=$APISEC_IMAGE_SUFFIX" \
  .
docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
docker push $TARGET_IMAGE

    3. api_security 작업을 확장하고 새 이미지 이름을 사용하세요.

      api_security:
  image: apisec-$CI_COMMIT_SHA

    4. 레지스트리에서 임시 컨테이너를 제거합니다. 컨테이너 이미지 삭제에 대한 정보는 이 문서 페이지를 참조하세요.

  • GitLab Runner 구성을 변경하여 no-new-privileges 플래그를 비활성화합니다. 이는 보안에 영향을 미칠 수 있으므로 운영 및 보안 팀과 논의해야 합니다.

배열의 경계를 벗어난 인덱스입니다. at Peach.Web.Runner.Services.RunnerOptions.GetHeaders()

이 오류 메시지는 API 보안 테스트 분석기가 APISEC_REQUEST_HEADERS 또는 APISEC_REQUEST_HEADERS_BASE64 구성 변수의 값을 구문 분석할 수 없음을 나타냅니다.

오류 메시지

이 문제는 두 개의 오류 메시지로 식별할 수 있습니다. 첫 번째 오류 메시지는 작업 콘솔 출력에서 볼 수 있고, 두 번째는 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> WebRunnerMachine::Run()에서 예기치 않은 예외 발생
System.IndexOutOfRangeException: 배열의 경계를 벗어난 인덱스입니다.
   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> * 세션 실패: 예기치 않은 예외 발생: 배열의 경계를 벗어난 인덱스입니다.
08:45:43.677 [INF] <Peach.Web.Core.Services.WebRunnerMachine> 테스트 완료. 총 0개의 요청 수행.

해결책

이 문제는 잘못된 APISEC_REQUEST_HEADERS 또는 APISEC_REQUEST_HEADERS_BASE64 변수로 인해 발생합니다. 예상 형식은 쉼표로 구분된 Header: value 구성의 하나 이상의 헤더입니다. 해결책은 기대되는 형식에 맞게 구문을 수정하는 것입니다.

유효한 예시:

  • Authorization: Bearer XYZ
  • X-Custom: Value,Authorization: Bearer XYZ

유효하지 않은 예시:

  • Header:,value
  • HeaderA: value,HeaderB:,HeaderC: value
  • Header