문제 해결

API 보안 테스트 작업이 N 시간 후에 타임 아웃됨

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

도움이 필요한 경우 다음 설명서 섹션을 참조하세요.

API 보안 테스트 작업이 완료하는 데 너무 오래 걸림

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

오류: DAST API 'http://127.0.0.1:5000'의 사용 가능 여부를 기다리는 중 오류 발생

1.6.196 이전의 API 보안 테스트 분석기 버전에서는 특정 조건에서 백그라운드 프로세스가 실패할 수 있는 버그가 있습니다. 이 문제의 해결책은 더 최신 버전의 API 보안 테스트 분석기로 업데이트하는 것입니다.

버전 정보는 dast_api 작업의 작업 세부 정보에서 찾을 수 있습니다.

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

  1. 이 문제를 Troubleshooting 섹션으로 참조하고 문제 해결을 Dynamic Analysis 팀으로 향상시킬 것을 요청합니다.
  2. 작업의 전체 콘솔 출력.
  3. 작업 세부 정보 페이지의 오른쪽 패널에서 찾아보기 버튼을 선택해 사용 가능한 gl-api-security-scanner.log 파일.
  4. .gitlab-ci.yml 파일에서 dast_api 작업 정의.

오류 메시지

  • GitLab 15.6 및 이후 버전에서 DAST API 'http://127.0.0.1:5000'의 사용 가능 여부를 기다리는 중 오류 발생
  • GitLab 15.5 및 이전 버전에서 API Security 'http://127.0.0.1:5000'의 사용 가능 여부를 기다리는 중 오류 발생.

스캐너 세션 시작 실패 (버전 헤더를 찾을 수 없음)

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

오류 메시지

  • 스캐너 세션 시작 실패 (버전 헤더를 찾을 수 없음).

해결책

  • .gitlab-ci.yml 파일에서 APISEC_API 변수를 제거합니다. 이 값을 수동으로 설정하는 대신 API 보안 테스트 CI/CD 템플릿에서 상속되는 값을 추천합니다.
  • 변수를 제거할 수 없는 경우 최신 버전의 API 보안 테스트 CI/CD 템플릿에서 이 값이 변경되었는지 확인하세요. 변경되었다면 .gitlab-ci.yml 파일에서 값을 업데이트하세요.

스캐너와의 세션 시작에 실패했습니다. 다시 시도하고 문제가 지속되면 지원팀에 문의하세요.

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

해결책을 진행하기 전에 포트가 이미 사용 중이라는 것을 확인하는 것이 중요합니다. 확인하는 방법은 다음과 같습니다.

  1. 작업 콘솔로 이동합니다.
  2. gl-api-security-scanner.log 아티팩트를 찾습니다. 모든 아티팩트를 선택하여 모두 다운로드하거나 찾아보기를 선택하여 직접 검색할 수 있습니다.
  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를 확인하는 경우 API 보안 테스트 엔진은 다양한 소스를 확인하는 우선 순위가 있습니다. 먼저 APISEC_TARGET_URL을 사용하려고 시도합니다. 환경 변수가 설정되지 않은 경우 API 보안 테스트 엔진은 environment_url.txt 파일을 사용하려고 시도합니다. environment_url.txt 파일이 없는 경우 API 보안 테스트 엔진은 OpenAPI 문서 내용과 APISEC_OPENAPI에서 제공된 URL(제공된 경우)을 사용하여 대상 API를 계산하려고 합니다.

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

API 보안 테스트 작업에서 일부 경로 제외

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

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

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

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

정적 환경 솔루션

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

환경 변수 추가

대상 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 보안 테스트 엔진은 environment_url.txt 파일을 지원합니다. 이 파일은 저장소에 체크아웃되지 않고 대상을 배포하는 작업에 의해 만들어진 후 파이프라인에서 수집되는 artifact입니다. environment_url.txt 파일을 생성하는 작업은 API 보안 테스트 엔진 작업보다 먼저 실행되어야 합니다.

  1. 테스트 대상 배포 작업 수정하여 프로젝트 루트에 environment_url.txt 파일에 기본 URL 추가
  2. environment_url.txt를 artifact으로 수집하도록 테스트 대상 배포 작업 수정

예: 

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. 로그 파일을 지원 티켓에 첨부하십시오.

오류: 작업 실패: 이미지를 받아오지 못함

이 오류 메시지는 인증이 필요한 컨테이너 레지스트리에서 이미지를 가져올 때 발생합니다(공개되어 있지 않음).

작업 콘솔 출력에서 해당 오류는 다음과 같이 나타납니다: 

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입니다.

  1. DOCKER_AUTH_CONFIG 데이터 확인을 위해 DOCKER_AUTH_CONFIG 데이터 확인 문서를 참조하여 DOCKER_AUTH_CONFIG 변수 값의 계산 방법을 이해합니다. 구성 변수 DOCKER_AUTH_CONFIG에는 적절한 인증 정보를 제공하기 위한 Docker JSON 구성이 포함되어 있습니다. 예를 들어, 인증이 필요한 컨테이너 레지스트리 registry.example.com에 대한 자격 증명 abcdefghijklmn을 사용하는 경우 Docker JSON은 다음과 같습니다: 

    {
    "auths": {
        "registry.example.com": {
            "auth": "abcdefghijklmn"
        }
    }
}
  2. DOCKER_AUTH_CONFIG를 CI/CD 변수로 추가하십시오. 구성 변수를 .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)...

연이은 스캔 간의 취약점 결과 차이

코드나 구성 변경이 없는 상황에서 연이은 스캔이 다른 취약점 결과를 반환할 수 있습니다. 이는 주로 대상 환경 및 상태의 예측할 수 없는 특성, 그리고 스캐너에 의해 병렬로 전송된 요청들로 인한 것입니다. 스캐너는 스캔 시간을 최적화하기 위해 병렬로 다수의 요청을 보내며, 따라서 대상 서버가 요청에 응답하는 정확한 순서는 미리 결정되어 있지 않습니다.

요청과 응답 사이의 시간 길이에 의해 감지되는 Timing Attack 취약점(예: OS 명령 또는 SQL 삽입)은 서버가 부하 상태이고 테스트의 제한 시간 내에 응답을 제공할 수 없을 때 감지될 수 있습니다. 서버가 부하 상태가 아닐 때는 같은 스캔 실행이 이러한 취약점에 대해 양성 결과를 반환하지 않을 수 있으며, 결과적으로 다른 결과가 나타날 수 있습니다. 대상 서버의 프로파일링, 퍼포먼스 튜닝 및 테스트 속도, 그리고 테스트 중에 최적 서버 성능에 대한 기준을 설정하는 것은 상기 요소로 인한 잘못된 양성 결과가 나타날 수 있는 곳을 식별하는 데 도움이 될 수 있습니다.

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

분석기의 v5부터는 기본적으로 root가 아닌 사용자가 사용됩니다. 이는 특권이 필요한 작업을 수행할 때 sudo를 사용해야 함을 의미합니다.

이 오류는 콘테이너 데몬 설정에서 특정 컨테이너에서 새 권한을 획들하는 것을 방지하는 것과 관련이 있습니다. 대부분의 설정에서 이것은 기본 구성이 아니며, 보안 강화 안내서의 일환으로 특별히 구성되는 것입니다.

오류 메시지

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

$ sudo apk add nodejs

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

sudo: 만약 sudo가 컨테이너에서 실행 중이라면, 플래그를 비활성화하도록 컨테이너 구성을 조정해야 합니다.

해결 방법

다음과 같은 방법으로 이 문제를 해결할 수 있습니다:

  • root 사용자로 콘테이너 실행. 모든 경우에 작동하지 않을 수 있으므로 이 구성에 대해 테스트한 후, whoami이 root가 아닌 gitlab을 반환하는지 확인하는 것이 중요합니다. gitlab이 표시된 경우 다른 해결 방법을 사용하십시오. 변경 사항이 성공적으로 확인되었을 때 before_script를 제거할 수 있습니다. 

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

    작업 콘솔 출력 예: 

    작업 스크립트 단계를 실행 중
registry.gitlab.com/security-products/api-security:5에 대한 digest registry.gitlab.com/security-products/api-security@sha256:092909baa2b41db8a7e3584f91b982174772abdfe8ceafc97cf567c3de3179d1을 사용하여 registry.gitlab.com/security-products/api-security:5에서 사용하는 docker 이미지 sha256:8b95f188b37d6b342dc740f68557771bb214fe520a5dc78a88c7a9cc6a0f9901...
$ 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

  • 콘테이너를 래핑하고 빌드 시에 종속성을 추가합니다. 이 옵션은 일부 고객에게 필요한 root보다 낮은 권한으로 실행하는 이점이 있습니다.

    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_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. 레지스트리의 임시 콘테이너를 제거합니다. 컨테이너 이미지 제거 정보는 이 문서 페이지를 참조하십시오.

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

배열 경계를 벗어난 인덱스입니다. 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> 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.

해결 방법

이 문제는 잘못된 APISEC_REQUEST_HEADERS 또는 APISEC_REQUEST_HEADERS_BASE64 변수로 인해 발생합니다. 예상 형식은 쉼표로 구분된 헤더: 값 구성의 하나 이상의 헤더입니다. 해결 방법은 예상과 일치하도록 구문을 정정하는 것입니다.

유효한 예시:

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

유효하지 않은 예시:

  • 헤더:,값
  • 헤더A: 값,헤더B:,헤더C: 값
  • 헤더