InfoGrab DocsInfoGrab Docs

API 보안 테스트 job 문제 해결

요약

대형 리포지터리의 경우, API 보안 테스트 job이 기본으로 설정된 Linux의 소형 호스팅 러너에서 타임아웃될 수 있습니다. 성능 튜닝 및 테스트 속도를 참조하세요. v1.6.196 이전 버전의 API 보안 테스트 분석기에는 특정 조건에서 백그라운드 프로세스가 실패할 수 있는 버그가 있습니다.

API 보안 테스트 job이 N시간 후 타임아웃됨#

대형 리포지터리의 경우, API 보안 테스트 job이 기본으로 설정된 Linux의 소형 호스팅 러너에서 타임아웃될 수 있습니다. job에서 이 문제가 발생하면 더 큰 러너로 확장해야 합니다.

다음 문서 섹션을 참조하세요:

API 보안 테스트 job 완료에 너무 오랜 시간이 걸림#

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

오류: DAST API 'http://127.0.0.1:5000'이 사용 가능해질 때까지 기다리는 중 오류 발생#

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

버전 정보는 dast_api job의 job 상세 정보에서 확인할 수 있습니다.

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

  • 이 문제 해결 섹션을 참조하고 Dynamic Analysis Team으로 에스컬레이션을 요청하세요.

  • job의 전체 콘솔 출력.

  • job 아티팩트로 제공되는 gl-api-security-scanner.log 파일. job 상세 정보 페이지의 우측 패널에서 Browse를 선택하세요.

  • .gitlab-ci.yml 파일의 dast_api job 정의.

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

API 보안 테스트 엔진은 스캐너 애플리케이션 컴포넌트와 연결을 수립할 수 없을 때 오류 메시지를 출력합니다. 이 오류 메시지는 dast_api job의 job 출력 창에 표시됩니다. 이 문제의 일반적인 원인은 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 파일의 값을 업데이트하세요.

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

API 보안 테스트 엔진은 스캐너 애플리케이션 컴포넌트와 연결을 수립할 수 없을 때 오류 메시지를 출력합니다. 이 오류 메시지는 dast_api job의 job 출력 창에 표시됩니다. 이 문제의 일반적인 원인은 백그라운드 컴포넌트가 이미 사용 중인 포트를 사용할 수 없는 경우입니다. 타이밍이 관여하는 경우(경쟁 조건) 이 오류는 간헐적으로 발생할 수 있습니다. 이 문제는 다른 서비스가 컨테이너에 매핑되어 포트 충돌이 발생하는 쿠버네티스 환경에서 가장 많이 발생합니다.

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

  • job 콘솔로 이동하세요.

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

  • 텍스트 편집기에서 gl-api-security-scanner.log 파일을 여세요.

  • 포트가 이미 사용 중이어서 오류 메시지가 발생했다면, 파일에서 다음과 같은 메시지를 볼 수 있습니다:

Failed to bind to address http://127.0.0.1:5500: address already in use.

이전 메시지의 http://[::]:5000 텍스트는 경우에 따라 다를 수 있습니다. 예를 들어 http://[::]:5500 또는 http://127.0.0.1:5500일 수 있습니다. 오류 메시지의 나머지 부분이 동일하다면, 포트가 이미 사용 중이었다고 가정해도 됩니다.

포트가 이미 사용 중이었다는 증거를 찾지 못했다면, job 콘솔 출력에 표시된 동일한 오류 메시지를 다루는 다른 문제 해결 섹션을 확인하세요. 더 이상 옵션이 없다면, 적절한 채널을 통해 지원을 받거나 개선을 요청하세요.

포트가 이미 사용 중이어서 문제가 발생했음을 확인할 수 있다면, CI/CD 변수 APISEC_API_PORT를 사용하여 스캐너 백그라운드 컴포넌트에 다른 포트를 지정하세요.

해결 방법

  • .gitlab-ci.yml 파일에 구성 변수 APISEC_API_PORT를 정의하세요.

  • APISEC_API_PORT 값을 1024보다 큰 사용 가능한 포트 번호로 업데이트하세요. 제안된 포트 번호가 GitLab에서 사용하지 않는지 확인하세요. GitLab에서 사용하는 전체 포트 목록은 패키지 기본값을 참조하세요.

애플리케이션이 타깃 API의 기본 URL을 확인할 수 없음#

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

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

가장 적합한 해결 방법은 타깃 API가 각 배포마다 변경되는지 여부에 따라 다릅니다. 정적 환경에서는 각 배포마다 타깃 API가 동일하므로, 이 경우 정적 환경 해결 방법을 참조하세요. 타깃 API가 각 배포마다 변경되는 경우 동적 환경 해결 방법을 적용해야 합니다.

API 보안 테스트 job이 일부 경로를 작업에서 제외함#

일부 경로가 작업에서 제외되고 있음을 발견한 경우, 다음을 확인하세요:

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

  • 타깃 정의 JSON 파일에서 consumes 배열이 정의되어 있고 유효한 타입이 있는지 확인하세요.

정의 예시는 예시 프로젝트 타깃 정의 파일을 참조하세요.

정적 환경 해결 방법#

이 해결 방법은 타깃 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 보안 테스트 엔진은 사용할 URL이 포함된 environment_url.txt 파일 사용을 지원합니다. 이 파일은 리포지터리에 체크인되지 않으며, 대신 테스트 타깃을 배포하는 job에 의해 파이프라인 중에 생성되고 파이프라인의 이후 job에서 사용할 수 있는 아티팩트로 수집됩니다. environment_url.txt 파일을 생성하는 job은 API 보안 테스트 엔진 job보다 먼저 실행되어야 합니다.

  • 프로젝트 루트의 environment_url.txt 파일에 기본 URL을 추가하도록 테스트 타깃 배포 job을 수정하세요.

  • environment_url.txt를 아티팩트로 수집하도록 테스트 타깃 배포 job을 수정하세요.

예시:

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 사용#

OpenAPI 문서는 때때로 유효하지 않은 스키마로 자동 생성되거나 적시에 수동으로 편집할 수 없는 경우가 있습니다. 이러한 시나리오에서 API 보안 테스트는 APISEC_OPENAPI_RELAXED_VALIDATION 변수를 설정하여 완화된 유효성 검사를 수행할 수 있습니다. 예상치 못한 동작을 방지하려면 완전히 준수하는 OpenAPI 문서를 제공하세요.

비준수 OpenAPI 파일 편집#

편집기를 사용하여 OpenAPI 사양을 준수하지 않는 요소를 감지하고 수정하세요. 편집기는 일반적으로 문서 유효성 검사와 스키마 준수 OpenAPI 문서를 만들기 위한 제안을 제공합니다. 권장 편집기는 다음과 같습니다:

편집기 OpenAPI 2.0 OpenAPI 3.0.x OpenAPI 3.1.x
Stoplight Studio check-circle YAML, JSON check-circle YAML, JSON check-circle YAML, JSON
Swagger Editor check-circle YAML, JSON check-circle YAML, JSON dotted-circle 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 문서에 지정된 미디어 타입을 사용하여 요청을 생성합니다. 지원되는 미디어 타입이 없어 요청을 생성할 수 없는 경우 오류가 발생합니다.

오류 메시지

  • 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 문서 수준에서 설정하여 모든 작업에 적용할 수 있습니다. 이 단계에서는 애플리케이션이 지원되는 미디어 타입을 수락하도록 애플리케이션을 변경해야 할 수 있습니다.

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

API 보안 테스트는 오래된 프로토콜과 암호를 포함하여 광범위한 TLS 구성과 호환됩니다. 광범위한 지원에도 불구하고 다음과 같은 연결 오류가 발생할 수 있습니다:

Error, error occurred trying to download ``:
There was an error when retrieving content from Uri:' '.
Error:The SSL connection could not be established, see inner exception.

이 오류는 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

비TLS 연결로 URL에 접근할 수 없는 경우, Support 팀에 도움을 요청하세요.

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

  • https://github.com/drwetter/testssl.sh/releases에서 최신 릴리즈의 zip 또는 tar.gz 파일을 다운로드하고 압축을 해제하세요.

  • ./testssl.sh --log https://specs를 실행하세요.

  • 로그 파일을 Support 티켓에 첨부하세요.

오류: Job failed: failed to pull image#

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

job 콘솔 출력의 오류는 다음과 같이 표시됩니다:

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 Cloud(GCP), AWS 등)와 같은 서드파티가 제공하는 컨테이너 레지스트리를 사용하는 경우, 해당 공급업체 문서에서 컨테이너 레지스트리 인증 방법에 대한 정보를 확인하세요.

다음 예시에서는 정적으로 정의된 자격 증명 인증 방법을 사용합니다. 이 예시에서 컨테이너 레지스트리는 registry.example.com이고 이미지는 my-target-app:latest입니다.

  • DOCKER_AUTH_CONFIG 데이터 확인 방법을 읽고 DOCKER_AUTH_CONFIG의 변수 값을 계산하는 방법을 이해하세요. 구성 변수 DOCKER_AUTH_CONFIG에는 적절한 인증 정보를 제공하는 Docker JSON 구성이 포함되어 있습니다. 예를 들어, 자격 증명 abcdefghijklmn으로 프라이빗 컨테이너 레지스트리 registry.example.com에 접근하려면 Docker JSON은 다음과 같습니다:
{
    "auths": {
        "registry.example.com": {
            "auth": "abcdefghijklmn"
        }
    }
}
  • DOCKER_AUTH_CONFIG를 CI/CD 변수로 추가하세요. 구성 변수를 .gitlab-ci.yml 파일에 직접 추가하는 대신 프로젝트 CI/CD 변수를 생성해야 합니다.

  • job을 다시 실행하면, 정적으로 정의된 자격 증명을 사용하여 프라이빗 컨테이너 레지스트리 registry.example.com에 로그인하고 이미지 my-target-app:latest를 가져올 수 있습니다. 성공하면 job 콘솔에 다음과 같은 출력이 표시됩니다:

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: 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 구성을 수정하고 job 출력을 확인하여 whoamigitlab이 아닌 root를 반환하는지 확인하세요. gitlab이 표시되면 다른 우회 방법을 사용하세요. 테스트에서 변경이 성공했음을 확인한 후 before_script를 제거할 수 있습니다.
api_security:
  image:
    name: $SECURE_ANALYZERS_PREFIX/$APISEC_IMAGE:$APISEC_VERSION$APISEC_IMAGE_SUFFIX
    docker:
      user: root
 before_script:
   - whoami

job 콘솔 출력 예시:

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-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보다 낮은 권한으로 실행할 수 있다는 이점이 있습니다.

기존 이미지를 래핑하는 새 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
  • API 보안 테스트 job이 시작되기 전에 새 이미지를 빌드하고 로컬 컨테이너 레지스트리에 푸시하세요. api_security job이 완료된 후 이미지를 제거해야 합니다.
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
  • api_security job을 확장하고 새 이미지 이름을 사용하세요.
api_security:
  image: apisec-$CI_COMMIT_SHA

인덱스가 배열 범위를 벗어났습니다. at Peach.Web.Runner.Services.RunnerOptions.GetHeaders()#

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

오류 메시지

이 문제는 두 가지 오류 메시지로 확인할 수 있습니다. 첫 번째 오류 메시지는 job 콘솔 출력에서, 두 번째는 gl-api-security-scanner.log 파일에서 확인됩니다.

job 콘솔의 오류 메시지:

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]  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]  * Session failed: An unexpected exception occurred: Index was outside the bounds of the array.
08:45:43.677 [INF]  Finished testing. Performed a total of 0 requests.

해결 방법

이 문제는 잘못된 형식의 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

API 보안 테스트 job 문제 해결

GitLab v19.1
원문 보기
요약

대형 리포지터리의 경우, API 보안 테스트 job이 기본으로 설정된 Linux의 소형 호스팅 러너에서 타임아웃될 수 있습니다. 성능 튜닝 및 테스트 속도를 참조하세요. v1.6.196 이전 버전의 API 보안 테스트 분석기에는 특정 조건에서 백그라운드 프로세스가 실패할 수 있는 버그가 있습니다.

API 보안 테스트 job이 N시간 후 타임아웃됨#

대형 리포지터리의 경우, API 보안 테스트 job이 기본으로 설정된 Linux의 소형 호스팅 러너에서 타임아웃될 수 있습니다. job에서 이 문제가 발생하면 더 큰 러너로 확장해야 합니다.

다음 문서 섹션을 참조하세요:

API 보안 테스트 job 완료에 너무 오랜 시간이 걸림#

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

오류: DAST API 'http://127.0.0.1:5000'이 사용 가능해질 때까지 기다리는 중 오류 발생#

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

버전 정보는 dast_api job의 job 상세 정보에서 확인할 수 있습니다.

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

  • 이 문제 해결 섹션을 참조하고 Dynamic Analysis Team으로 에스컬레이션을 요청하세요.

  • job의 전체 콘솔 출력.

  • job 아티팩트로 제공되는 gl-api-security-scanner.log 파일. job 상세 정보 페이지의 우측 패널에서 Browse를 선택하세요.

  • .gitlab-ci.yml 파일의 dast_api job 정의.

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

API 보안 테스트 엔진은 스캐너 애플리케이션 컴포넌트와 연결을 수립할 수 없을 때 오류 메시지를 출력합니다. 이 오류 메시지는 dast_api job의 job 출력 창에 표시됩니다. 이 문제의 일반적인 원인은 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 파일의 값을 업데이트하세요.

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

API 보안 테스트 엔진은 스캐너 애플리케이션 컴포넌트와 연결을 수립할 수 없을 때 오류 메시지를 출력합니다. 이 오류 메시지는 dast_api job의 job 출력 창에 표시됩니다. 이 문제의 일반적인 원인은 백그라운드 컴포넌트가 이미 사용 중인 포트를 사용할 수 없는 경우입니다. 타이밍이 관여하는 경우(경쟁 조건) 이 오류는 간헐적으로 발생할 수 있습니다. 이 문제는 다른 서비스가 컨테이너에 매핑되어 포트 충돌이 발생하는 쿠버네티스 환경에서 가장 많이 발생합니다.

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

  • job 콘솔로 이동하세요.

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

  • 텍스트 편집기에서 gl-api-security-scanner.log 파일을 여세요.

  • 포트가 이미 사용 중이어서 오류 메시지가 발생했다면, 파일에서 다음과 같은 메시지를 볼 수 있습니다:

Failed to bind to address http://127.0.0.1:5500: address already in use.

이전 메시지의 http://[::]:5000 텍스트는 경우에 따라 다를 수 있습니다. 예를 들어 http://[::]:5500 또는 http://127.0.0.1:5500일 수 있습니다. 오류 메시지의 나머지 부분이 동일하다면, 포트가 이미 사용 중이었다고 가정해도 됩니다.

포트가 이미 사용 중이었다는 증거를 찾지 못했다면, job 콘솔 출력에 표시된 동일한 오류 메시지를 다루는 다른 문제 해결 섹션을 확인하세요. 더 이상 옵션이 없다면, 적절한 채널을 통해 지원을 받거나 개선을 요청하세요.

포트가 이미 사용 중이어서 문제가 발생했음을 확인할 수 있다면, CI/CD 변수 APISEC_API_PORT를 사용하여 스캐너 백그라운드 컴포넌트에 다른 포트를 지정하세요.

해결 방법

  • .gitlab-ci.yml 파일에 구성 변수 APISEC_API_PORT를 정의하세요.

  • APISEC_API_PORT 값을 1024보다 큰 사용 가능한 포트 번호로 업데이트하세요. 제안된 포트 번호가 GitLab에서 사용하지 않는지 확인하세요. GitLab에서 사용하는 전체 포트 목록은 패키지 기본값을 참조하세요.

애플리케이션이 타깃 API의 기본 URL을 확인할 수 없음#

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

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

가장 적합한 해결 방법은 타깃 API가 각 배포마다 변경되는지 여부에 따라 다릅니다. 정적 환경에서는 각 배포마다 타깃 API가 동일하므로, 이 경우 정적 환경 해결 방법을 참조하세요. 타깃 API가 각 배포마다 변경되는 경우 동적 환경 해결 방법을 적용해야 합니다.

API 보안 테스트 job이 일부 경로를 작업에서 제외함#

일부 경로가 작업에서 제외되고 있음을 발견한 경우, 다음을 확인하세요:

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

  • 타깃 정의 JSON 파일에서 consumes 배열이 정의되어 있고 유효한 타입이 있는지 확인하세요.

정의 예시는 예시 프로젝트 타깃 정의 파일을 참조하세요.

정적 환경 해결 방법#

이 해결 방법은 타깃 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 보안 테스트 엔진은 사용할 URL이 포함된 environment_url.txt 파일 사용을 지원합니다. 이 파일은 리포지터리에 체크인되지 않으며, 대신 테스트 타깃을 배포하는 job에 의해 파이프라인 중에 생성되고 파이프라인의 이후 job에서 사용할 수 있는 아티팩트로 수집됩니다. environment_url.txt 파일을 생성하는 job은 API 보안 테스트 엔진 job보다 먼저 실행되어야 합니다.

  • 프로젝트 루트의 environment_url.txt 파일에 기본 URL을 추가하도록 테스트 타깃 배포 job을 수정하세요.

  • environment_url.txt를 아티팩트로 수집하도록 테스트 타깃 배포 job을 수정하세요.

예시:

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 사용#

OpenAPI 문서는 때때로 유효하지 않은 스키마로 자동 생성되거나 적시에 수동으로 편집할 수 없는 경우가 있습니다. 이러한 시나리오에서 API 보안 테스트는 APISEC_OPENAPI_RELAXED_VALIDATION 변수를 설정하여 완화된 유효성 검사를 수행할 수 있습니다. 예상치 못한 동작을 방지하려면 완전히 준수하는 OpenAPI 문서를 제공하세요.

비준수 OpenAPI 파일 편집#

편집기를 사용하여 OpenAPI 사양을 준수하지 않는 요소를 감지하고 수정하세요. 편집기는 일반적으로 문서 유효성 검사와 스키마 준수 OpenAPI 문서를 만들기 위한 제안을 제공합니다. 권장 편집기는 다음과 같습니다:

편집기 OpenAPI 2.0 OpenAPI 3.0.x OpenAPI 3.1.x
Stoplight Studio check-circle YAML, JSON check-circle YAML, JSON check-circle YAML, JSON
Swagger Editor check-circle YAML, JSON check-circle YAML, JSON dotted-circle 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 문서에 지정된 미디어 타입을 사용하여 요청을 생성합니다. 지원되는 미디어 타입이 없어 요청을 생성할 수 없는 경우 오류가 발생합니다.

오류 메시지

  • 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 문서 수준에서 설정하여 모든 작업에 적용할 수 있습니다. 이 단계에서는 애플리케이션이 지원되는 미디어 타입을 수락하도록 애플리케이션을 변경해야 할 수 있습니다.

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

API 보안 테스트는 오래된 프로토콜과 암호를 포함하여 광범위한 TLS 구성과 호환됩니다. 광범위한 지원에도 불구하고 다음과 같은 연결 오류가 발생할 수 있습니다:

Error, error occurred trying to download ``:
There was an error when retrieving content from Uri:' '.
Error:The SSL connection could not be established, see inner exception.

이 오류는 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

비TLS 연결로 URL에 접근할 수 없는 경우, Support 팀에 도움을 요청하세요.

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

  • https://github.com/drwetter/testssl.sh/releases에서 최신 릴리즈의 zip 또는 tar.gz 파일을 다운로드하고 압축을 해제하세요.

  • ./testssl.sh --log https://specs를 실행하세요.

  • 로그 파일을 Support 티켓에 첨부하세요.

오류: Job failed: failed to pull image#

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

job 콘솔 출력의 오류는 다음과 같이 표시됩니다:

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 Cloud(GCP), AWS 등)와 같은 서드파티가 제공하는 컨테이너 레지스트리를 사용하는 경우, 해당 공급업체 문서에서 컨테이너 레지스트리 인증 방법에 대한 정보를 확인하세요.

다음 예시에서는 정적으로 정의된 자격 증명 인증 방법을 사용합니다. 이 예시에서 컨테이너 레지스트리는 registry.example.com이고 이미지는 my-target-app:latest입니다.

  • DOCKER_AUTH_CONFIG 데이터 확인 방법을 읽고 DOCKER_AUTH_CONFIG의 변수 값을 계산하는 방법을 이해하세요. 구성 변수 DOCKER_AUTH_CONFIG에는 적절한 인증 정보를 제공하는 Docker JSON 구성이 포함되어 있습니다. 예를 들어, 자격 증명 abcdefghijklmn으로 프라이빗 컨테이너 레지스트리 registry.example.com에 접근하려면 Docker JSON은 다음과 같습니다:
{
    "auths": {
        "registry.example.com": {
            "auth": "abcdefghijklmn"
        }
    }
}
  • DOCKER_AUTH_CONFIG를 CI/CD 변수로 추가하세요. 구성 변수를 .gitlab-ci.yml 파일에 직접 추가하는 대신 프로젝트 CI/CD 변수를 생성해야 합니다.

  • job을 다시 실행하면, 정적으로 정의된 자격 증명을 사용하여 프라이빗 컨테이너 레지스트리 registry.example.com에 로그인하고 이미지 my-target-app:latest를 가져올 수 있습니다. 성공하면 job 콘솔에 다음과 같은 출력이 표시됩니다:

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: 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 구성을 수정하고 job 출력을 확인하여 whoamigitlab이 아닌 root를 반환하는지 확인하세요. gitlab이 표시되면 다른 우회 방법을 사용하세요. 테스트에서 변경이 성공했음을 확인한 후 before_script를 제거할 수 있습니다.
api_security:
  image:
    name: $SECURE_ANALYZERS_PREFIX/$APISEC_IMAGE:$APISEC_VERSION$APISEC_IMAGE_SUFFIX
    docker:
      user: root
 before_script:
   - whoami

job 콘솔 출력 예시:

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-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보다 낮은 권한으로 실행할 수 있다는 이점이 있습니다.

기존 이미지를 래핑하는 새 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
  • API 보안 테스트 job이 시작되기 전에 새 이미지를 빌드하고 로컬 컨테이너 레지스트리에 푸시하세요. api_security job이 완료된 후 이미지를 제거해야 합니다.
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
  • api_security job을 확장하고 새 이미지 이름을 사용하세요.
api_security:
  image: apisec-$CI_COMMIT_SHA

인덱스가 배열 범위를 벗어났습니다. at Peach.Web.Runner.Services.RunnerOptions.GetHeaders()#

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

오류 메시지

이 문제는 두 가지 오류 메시지로 확인할 수 있습니다. 첫 번째 오류 메시지는 job 콘솔 출력에서, 두 번째는 gl-api-security-scanner.log 파일에서 확인됩니다.

job 콘솔의 오류 메시지:

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]  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]  * Session failed: An unexpected exception occurred: Index was outside the bounds of the array.
08:45:43.677 [INF]  Finished testing. Performed a total of 0 requests.

해결 방법

이 문제는 잘못된 형식의 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