InfoGrab DocsInfoGrab Docs

API 퍼징 작업 문제 해결

요약

리포지터리가 큰 경우, 기본값으로 설정된 Linux의 소형 호스팅 러너에서 API 퍼징 job 이 타임아웃될 수 있습니다. 도움이 되는 다음 문서 섹션을 참고합니다. 성능 조정 및 테스트 속도를 참고합니다. v1.6.196 이전 버전의 API 퍼징 분석기에는 특정 조건에서 백그라운드 프로세스가 실패할 수 있는 버그가 있습니다.

API 퍼징 job 이 N시간 후 타임아웃됨#

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

도움이 되는 다음 문서 섹션을 참고합니다.

API 퍼징 job 완료에 시간이 너무 오래 걸림#

성능 조정 및 테스트 속도를 참고합니다.

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

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

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

v1.6.196 이상에서 이 문제가 발생하면 지원팀에 문의하면서 다음 정보를 제공합니다.

  1. 이 문제 해결 섹션을 언급하고 이슈를 Dynamic Analysis 팀으로 에스컬레이션해 달라고 요청합니다.
  2. job의 전체 콘솔 출력입니다.
  3. job 아티팩트로 제공되는 gl-api-security-scanner.log 파일입니다. job 상세 페이지의 오른쪽 패널에서 Browse 버튼을 선택합니다.
  4. .gitlab-ci.yml 파일의 apifuzzer_fuzz job 정의입니다.

오류 메시지

Error waiting for API Fuzzing '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 job의 job 출력 창에 표시됩니다. 이 문제의 일반적인 원인은 백그라운드 컴포넌트가 선택된 포트를 이미 사용 중이어서 사용할 수 없는 경우입니다. 타이밍이 관여하면(경쟁 조건) 이 오류가 간헐적으로 발생할 수 있습니다. 이 문제는 다른 서비스가 컨테이너에 매핑되어 포트 충돌이 생기는 Kubernetes 환경에서 가장 자주 발생합니다.

해결 방법으로 넘어가기 전에, 포트가 이미 사용 중이어서 오류 메시지가 나왔는지 확인하는 것이 중요합니다. 원인을 확인하는 방법은 다음과 같습니다.

  1. job 콘솔로 이동합니다.

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

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

  4. 포트가 이미 사용 중이어서 오류 메시지가 나온 경우라면 파일에서 다음과 같은 메시지를 확인할 수 있습니다.

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

앞 메시지의 주소는 환경에 따라 다를 수 있습니다. 오류 메시지의 나머지 부분이 같다면 포트가 이미 사용 중이었다고 보아도 됩니다.

포트가 이미 사용 중이었다는 근거를 찾지 못했다면, job 콘솔 출력에 같은 오류 메시지가 나타나는 다른 문제 해결 섹션도 확인합니다. 더 이상 선택할 방법이 없으면 적절한 채널을 통해 지원 요청 또는 개선 요청을 진행합니다.

포트가 이미 사용 중이어서 생긴 문제임을 확인했다면 구성 변수 FUZZAPI_API_PORT를 사용합니다. 이 구성 변수로 스캐너 백그라운드 컴포넌트의 포트 번호를 고정할 수 있습니다.

해결 방법

  1. .gitlab-ci.yml 파일에 구성 변수 FUZZAPI_API_PORT가 정의되어 있는지 확인합니다.
  2. FUZZAPI_API_PORT 값을 1024보다 큰 사용 가능한 포트 번호로 변경합니다. 새 값이 GitLab에서 이미 사용 중이지 않은지 확인합니다. GitLab 이 사용하는 포트 전체 목록은 Package defaults에 있습니다.

오류: Errors were found during validation of the document using the published OpenAPI schema#

API 퍼징 job 이 시작될 때 OpenAPI 사양은 공개된 스키마에 대해 검증됩니다. 제공한 OpenAPI 사양에 유효성 검사 오류가 있으면 다음 오류가 표시됩니다.

Error, the OpenAPI document is not valid.
Errors were found during validation of the document using the published OpenAPI schema

OpenAPI 사양을 수동으로 작성할 때도, 스키마를 생성할 때도 오류가 들어갈 수 있습니다.

자동으로 생성되는 OpenAPI 사양에서는 유효성 검사 오류가 코드 어노테이션 누락에서 비롯되는 경우가 많습니다.

오류 메시지

  • Error, the OpenAPI document is not valid. Errors were found during validation of the document using the published OpenAPI schema
    • OpenAPI 2.0 schema validation error ...
    • OpenAPI 3.0.x schema validation error ...

해결 방법

생성된 OpenAPI 사양의 경우

  1. 유효성 검사 오류를 확인합니다.
    1. Swagger Editor로 사양의 유효성 검사 문제를 파악합니다. Swagger Editor는 시각적으로 보여 주므로 무엇을 바꿔야 하는지 이해하기 쉽습니다.
    2. 또는 로그 출력에서 스키마 유효성 검사 경고를 찾습니다. 이 경고에는 OpenAPI 2.0 schema validation error 나 OpenAPI 3.0.x schema validation error 같은 메시지가 앞에 붙습니다. 실패한 검사마다 location과 description 정보가 추가로 제공됩니다. JSON 스키마 유효성 검사 메시지는 복잡할 수 있으며, 편집기를 사용하면 스키마 문서를 검증하는 데 도움이 됩니다.
  2. 사용 중인 프레임워크·기술 스택의 OpenAPI 생성 문서를 검토합니다. 올바른 OpenAPI 문서를 만들기 위해 필요한 변경 사항을 확인합니다.
  3. 유효성 검사 문제를 해결한 뒤 파이프라인을 다시 실행합니다.

수동으로 작성한 OpenAPI 사양의 경우

  1. 유효성 검사 오류를 확인합니다.
    1. 가장 간단한 방법은 시각적 도구로 OpenAPI 문서를 편집하고 검증하는 것입니다. 예를 들어 Swagger Editor는 스키마 오류와 가능한 해결 방법을 강조해 보여 줍니다.
    2. 또는 로그 출력에서 스키마 유효성 검사 경고를 찾습니다. 이 경고에는 OpenAPI 2.0 schema validation error 나 OpenAPI 3.0.x schema validation error 같은 메시지가 앞에 붙습니다. 실패한 검사마다 location과 description 정보가 추가로 제공됩니다. 유효성 검사 실패 항목을 모두 고친 뒤 OpenAPI 문서를 다시 제출합니다. JSON 스키마 유효성 검사 메시지는 복잡할 수 있으며, 편집기를 사용하면 스키마 문서를 검증하는 데 도움이 됩니다.
  2. 유효성 검사 문제를 해결한 뒤 파이프라인을 다시 실행합니다.

Failed to start scanner session (version header not found)#

API 퍼징 엔진은 스캐너 애플리케이션 컴포넌트와 연결을 수립할 수 없을 때 오류 메시지를 출력합니다. 이 오류 메시지는 apifuzzer_fuzz job의 job 출력 창에 표시됩니다. 이 문제의 일반적인 원인은 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를 판별할 수 없으면 오류 메시지를 출력합니다. 이 오류 메시지는 .gitlab-ci.yml 파일에 대상 API가 설정되어 있지 않고, 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 URL 이 바뀌지 않는(정적인) 파이프라인을 위한 것입니다.

환경 변수 추가

대상 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 파일 사용을 검토합니다.

environment_url.txt 사용

파이프라인마다 대상 API URL 이 바뀌는 동적 환경을 지원하기 위해, API 퍼징은 사용할 URL 이 담긴 environment_url.txt 파일을 지원합니다. 이 파일은 리포지터리에 체크인하지 않고, 테스트 대상을 배포하는 job 이 파이프라인 중에 생성하며 파이프라인 뒷단의 job 이 사용할 수 있는 아티팩트로 수집합니다. environment_url.txt 파일을 만드는 job은 API 퍼징 job보다 먼저 실행되어야 합니다.

  1. 테스트 대상 배포 job을 수정해 프로젝트 루트의 environment_url.txt 파일에 기본 URL을 넣습니다.
  2. 테스트 대상 배포 job을 수정해 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 사용#

문서가 유효하지 않은 스키마로 자동 생성되거나 적시에 수동으로 편집할 수 없는 경우가 있습니다. 이런 상황에서는 FUZZAPI_OPENAPI_RELAXED_VALIDATION 변수를 설정해 API 퍼징이 완화된 유효성 검사를 수행할 수 있습니다. 예상치 못한 동작을 막으려면 완전히 준수하는 OpenAPI 문서를 제공합니다.

비준수 OpenAPI 파일 편집#

편집기로 OpenAPI 사양을 준수하지 않는 요소를 찾아 수정합니다. 편집기는 보통 문서 유효성 검사 기능과 스키마를 준수하는 OpenAPI 문서를 만들기 위한 제안을 제공합니다. 권장 편집기는 다음과 같습니다.

편집기 OpenAPI 2.0 OpenAPI 3.0.x OpenAPI 3.1.x
Swagger Editor ✅ 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.

해결 방법

  1. OpenAPI 사양 섹션에서 지원되는 미디어 타입을 검토합니다.
  2. OpenAPI 문서를 편집해 최소한 특정 작업이 지원되는 미디어 타입 중 하나를 받아들이도록 합니다. 또는 지원되는 미디어 타입을 OpenAPI 문서 수준에서 설정해 모든 작업에 적용할 수도 있습니다. 이 단계에서는 애플리케이션이 지원되는 미디어 타입을 받아들이도록 애플리케이션을 변경해야 할 수 있습니다.

오류: The SSL connection could not be established, see inner exception.#

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:
  - fuzz

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

variables:
  FUZZAPI_TARGET_URL: https://test-deployment/
  FUZZAPI_OPENAPI: https://specs/openapi.json

FUZZAPI_OPENAPI의 접두사를 https://에서 http://로 변경합니다.

stages:
  - fuzz

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

variables:
  FUZZAPI_TARGET_URL: https://test-deployment/
  FUZZAPI_OPENAPI: http://specs/openapi.json

비 TLS 연결로 URL에 접근할 수 없다면 지원팀에 문의해 도움을 받습니다.

testssl.sh 도구를 사용하면 조사를 더 빠르게 진행할 수 있습니다. bash 셸을 쓸 수 있고 해당 서버에 연결되는 머신에서 다음을 수행합니다.

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

ERROR: 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)

오류 메시지

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

  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. DOCKER_AUTH_CONFIG를 CI/CD 변수로 추가합니다. .gitlab-ci.yml 파일에 구성 변수를 직접 넣는 대신 프로젝트 CI/CD 변수를 생성해야 합니다.

  3. 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)...

오류: sudo: The "no new privileges" flag is set, which prevents sudo from running as root.#

분석기 v5 부터는 기본적으로 루트가 아닌 사용자를 사용합니다. 따라서 권한이 필요한 작업을 수행할 때 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 구성을 수정하고 job 출력을 확인해 whoami가 gitlab 이 아니라 root를 반환하는지 확인하는 방식으로 테스트합니다. gitlab 이 표시되면 다른 우회 방법을 사용합니다. 테스트를 마친 뒤에는 before_script를 제거할 수 있습니다.

    apifuzzer_fuzz:
  image:
    name: $SECURE_ANALYZERS_PREFIX/$FUZZAPI_IMAGE:$FUZZAPI_VERSION$FUZZAPI_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-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

  • 컨테이너를 감싸 빌드 시점에 필요한 의존성을 추가합니다. 이 방법은 루트보다 낮은 권한으로 실행하는 이점이 있으며, 일부 고객에게는 이 점이 요구 사항일 수 있습니다.

    1. 기존 이미지를 감싸는 새 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 gitlab

    2. 새 이미지를 빌드하고 API 퍼징 job 이 시작되기 전에 로컬 컨테이너 레지스트리에 푸시합니다. 이 이미지는 job 이 완료된 뒤 제거해야 합니다.

      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_IMAGE

    3. apifuzzer_fuzz job을 확장하고 새 이미지 이름을 사용합니다.

      apifuzzer_fuzz:
  image: apifuzz-$CI_COMMIT_SHA

    4. 레지스트리에서 임시 컨테이너를 제거합니다. 컨테이너 이미지를 제거하는 방법은 이 문서 페이지를 참고합니다.

  • 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 구성 변수의 값을 파싱할 수 없다는 뜻입니다.

오류 메시지

이 문제는 두 가지 오류 메시지로 식별할 수 있습니다. 첫 번째 오류 메시지는 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.

해결 방법

이 문제는 FUZZAPI_REQUEST_HEADERS 또는 FUZZAPI_REQUEST_HEADERS_BASE64 변수 형식이 잘못되어 발생합니다. 기대하는 형식은 Header: value 형태의 헤더 하나 이상을 쉼표로 구분한 것입니다. 해결 방법은 기대 형식에 맞게 구문을 고치는 것입니다.

유효한 예시:

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

유효하지 않은 예시:

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

API 퍼징 작업 문제 해결

GitLab v19.5
원문 보기

요약

리포지터리가 큰 경우, 기본값으로 설정된 Linux의 소형 호스팅 러너에서 API 퍼징 job 이 타임아웃될 수 있습니다. 도움이 되는 다음 문서 섹션을 참고합니다. 성능 조정 및 테스트 속도를 참고합니다. v1.6.196 이전 버전의 API 퍼징 분석기에는 특정 조건에서 백그라운드 프로세스가 실패할 수 있는 버그가 있습니다.

API 퍼징 job 이 N시간 후 타임아웃됨#

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

도움이 되는 다음 문서 섹션을 참고합니다.

API 퍼징 job 완료에 시간이 너무 오래 걸림#

성능 조정 및 테스트 속도를 참고합니다.

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

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

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

v1.6.196 이상에서 이 문제가 발생하면 지원팀에 문의하면서 다음 정보를 제공합니다.

  1. 이 문제 해결 섹션을 언급하고 이슈를 Dynamic Analysis 팀으로 에스컬레이션해 달라고 요청합니다.
  2. job의 전체 콘솔 출력입니다.
  3. job 아티팩트로 제공되는 gl-api-security-scanner.log 파일입니다. job 상세 페이지의 오른쪽 패널에서 Browse 버튼을 선택합니다.
  4. .gitlab-ci.yml 파일의 apifuzzer_fuzz job 정의입니다.

오류 메시지

Error waiting for API Fuzzing '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 job의 job 출력 창에 표시됩니다. 이 문제의 일반적인 원인은 백그라운드 컴포넌트가 선택된 포트를 이미 사용 중이어서 사용할 수 없는 경우입니다. 타이밍이 관여하면(경쟁 조건) 이 오류가 간헐적으로 발생할 수 있습니다. 이 문제는 다른 서비스가 컨테이너에 매핑되어 포트 충돌이 생기는 Kubernetes 환경에서 가장 자주 발생합니다.

해결 방법으로 넘어가기 전에, 포트가 이미 사용 중이어서 오류 메시지가 나왔는지 확인하는 것이 중요합니다. 원인을 확인하는 방법은 다음과 같습니다.

  1. job 콘솔로 이동합니다.

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

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

  4. 포트가 이미 사용 중이어서 오류 메시지가 나온 경우라면 파일에서 다음과 같은 메시지를 확인할 수 있습니다.

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

앞 메시지의 주소는 환경에 따라 다를 수 있습니다. 오류 메시지의 나머지 부분이 같다면 포트가 이미 사용 중이었다고 보아도 됩니다.

포트가 이미 사용 중이었다는 근거를 찾지 못했다면, job 콘솔 출력에 같은 오류 메시지가 나타나는 다른 문제 해결 섹션도 확인합니다. 더 이상 선택할 방법이 없으면 적절한 채널을 통해 지원 요청 또는 개선 요청을 진행합니다.

포트가 이미 사용 중이어서 생긴 문제임을 확인했다면 구성 변수 FUZZAPI_API_PORT를 사용합니다. 이 구성 변수로 스캐너 백그라운드 컴포넌트의 포트 번호를 고정할 수 있습니다.

해결 방법

  1. .gitlab-ci.yml 파일에 구성 변수 FUZZAPI_API_PORT가 정의되어 있는지 확인합니다.
  2. FUZZAPI_API_PORT 값을 1024보다 큰 사용 가능한 포트 번호로 변경합니다. 새 값이 GitLab에서 이미 사용 중이지 않은지 확인합니다. GitLab 이 사용하는 포트 전체 목록은 Package defaults에 있습니다.

오류: Errors were found during validation of the document using the published OpenAPI schema#

API 퍼징 job 이 시작될 때 OpenAPI 사양은 공개된 스키마에 대해 검증됩니다. 제공한 OpenAPI 사양에 유효성 검사 오류가 있으면 다음 오류가 표시됩니다.

Error, the OpenAPI document is not valid.
Errors were found during validation of the document using the published OpenAPI schema

OpenAPI 사양을 수동으로 작성할 때도, 스키마를 생성할 때도 오류가 들어갈 수 있습니다.

자동으로 생성되는 OpenAPI 사양에서는 유효성 검사 오류가 코드 어노테이션 누락에서 비롯되는 경우가 많습니다.

오류 메시지

  • Error, the OpenAPI document is not valid. Errors were found during validation of the document using the published OpenAPI schema
    • OpenAPI 2.0 schema validation error ...
    • OpenAPI 3.0.x schema validation error ...

해결 방법

생성된 OpenAPI 사양의 경우

  1. 유효성 검사 오류를 확인합니다.
    1. Swagger Editor로 사양의 유효성 검사 문제를 파악합니다. Swagger Editor는 시각적으로 보여 주므로 무엇을 바꿔야 하는지 이해하기 쉽습니다.
    2. 또는 로그 출력에서 스키마 유효성 검사 경고를 찾습니다. 이 경고에는 OpenAPI 2.0 schema validation error 나 OpenAPI 3.0.x schema validation error 같은 메시지가 앞에 붙습니다. 실패한 검사마다 location과 description 정보가 추가로 제공됩니다. JSON 스키마 유효성 검사 메시지는 복잡할 수 있으며, 편집기를 사용하면 스키마 문서를 검증하는 데 도움이 됩니다.
  2. 사용 중인 프레임워크·기술 스택의 OpenAPI 생성 문서를 검토합니다. 올바른 OpenAPI 문서를 만들기 위해 필요한 변경 사항을 확인합니다.
  3. 유효성 검사 문제를 해결한 뒤 파이프라인을 다시 실행합니다.

수동으로 작성한 OpenAPI 사양의 경우

  1. 유효성 검사 오류를 확인합니다.
    1. 가장 간단한 방법은 시각적 도구로 OpenAPI 문서를 편집하고 검증하는 것입니다. 예를 들어 Swagger Editor는 스키마 오류와 가능한 해결 방법을 강조해 보여 줍니다.
    2. 또는 로그 출력에서 스키마 유효성 검사 경고를 찾습니다. 이 경고에는 OpenAPI 2.0 schema validation error 나 OpenAPI 3.0.x schema validation error 같은 메시지가 앞에 붙습니다. 실패한 검사마다 location과 description 정보가 추가로 제공됩니다. 유효성 검사 실패 항목을 모두 고친 뒤 OpenAPI 문서를 다시 제출합니다. JSON 스키마 유효성 검사 메시지는 복잡할 수 있으며, 편집기를 사용하면 스키마 문서를 검증하는 데 도움이 됩니다.
  2. 유효성 검사 문제를 해결한 뒤 파이프라인을 다시 실행합니다.

Failed to start scanner session (version header not found)#

API 퍼징 엔진은 스캐너 애플리케이션 컴포넌트와 연결을 수립할 수 없을 때 오류 메시지를 출력합니다. 이 오류 메시지는 apifuzzer_fuzz job의 job 출력 창에 표시됩니다. 이 문제의 일반적인 원인은 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를 판별할 수 없으면 오류 메시지를 출력합니다. 이 오류 메시지는 .gitlab-ci.yml 파일에 대상 API가 설정되어 있지 않고, 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 URL 이 바뀌지 않는(정적인) 파이프라인을 위한 것입니다.

환경 변수 추가

대상 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 파일 사용을 검토합니다.

environment_url.txt 사용

파이프라인마다 대상 API URL 이 바뀌는 동적 환경을 지원하기 위해, API 퍼징은 사용할 URL 이 담긴 environment_url.txt 파일을 지원합니다. 이 파일은 리포지터리에 체크인하지 않고, 테스트 대상을 배포하는 job 이 파이프라인 중에 생성하며 파이프라인 뒷단의 job 이 사용할 수 있는 아티팩트로 수집합니다. environment_url.txt 파일을 만드는 job은 API 퍼징 job보다 먼저 실행되어야 합니다.

  1. 테스트 대상 배포 job을 수정해 프로젝트 루트의 environment_url.txt 파일에 기본 URL을 넣습니다.
  2. 테스트 대상 배포 job을 수정해 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 사용#

문서가 유효하지 않은 스키마로 자동 생성되거나 적시에 수동으로 편집할 수 없는 경우가 있습니다. 이런 상황에서는 FUZZAPI_OPENAPI_RELAXED_VALIDATION 변수를 설정해 API 퍼징이 완화된 유효성 검사를 수행할 수 있습니다. 예상치 못한 동작을 막으려면 완전히 준수하는 OpenAPI 문서를 제공합니다.

비준수 OpenAPI 파일 편집#

편집기로 OpenAPI 사양을 준수하지 않는 요소를 찾아 수정합니다. 편집기는 보통 문서 유효성 검사 기능과 스키마를 준수하는 OpenAPI 문서를 만들기 위한 제안을 제공합니다. 권장 편집기는 다음과 같습니다.

편집기 OpenAPI 2.0 OpenAPI 3.0.x OpenAPI 3.1.x
Swagger Editor ✅ 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.

해결 방법

  1. OpenAPI 사양 섹션에서 지원되는 미디어 타입을 검토합니다.
  2. OpenAPI 문서를 편집해 최소한 특정 작업이 지원되는 미디어 타입 중 하나를 받아들이도록 합니다. 또는 지원되는 미디어 타입을 OpenAPI 문서 수준에서 설정해 모든 작업에 적용할 수도 있습니다. 이 단계에서는 애플리케이션이 지원되는 미디어 타입을 받아들이도록 애플리케이션을 변경해야 할 수 있습니다.

오류: The SSL connection could not be established, see inner exception.#

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:
  - fuzz

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

variables:
  FUZZAPI_TARGET_URL: https://test-deployment/
  FUZZAPI_OPENAPI: https://specs/openapi.json

FUZZAPI_OPENAPI의 접두사를 https://에서 http://로 변경합니다.

stages:
  - fuzz

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

variables:
  FUZZAPI_TARGET_URL: https://test-deployment/
  FUZZAPI_OPENAPI: http://specs/openapi.json

비 TLS 연결로 URL에 접근할 수 없다면 지원팀에 문의해 도움을 받습니다.

testssl.sh 도구를 사용하면 조사를 더 빠르게 진행할 수 있습니다. bash 셸을 쓸 수 있고 해당 서버에 연결되는 머신에서 다음을 수행합니다.

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

ERROR: 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)

오류 메시지

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

  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. DOCKER_AUTH_CONFIG를 CI/CD 변수로 추가합니다. .gitlab-ci.yml 파일에 구성 변수를 직접 넣는 대신 프로젝트 CI/CD 변수를 생성해야 합니다.

  3. 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)...

오류: sudo: The "no new privileges" flag is set, which prevents sudo from running as root.#

분석기 v5 부터는 기본적으로 루트가 아닌 사용자를 사용합니다. 따라서 권한이 필요한 작업을 수행할 때 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 구성을 수정하고 job 출력을 확인해 whoami가 gitlab 이 아니라 root를 반환하는지 확인하는 방식으로 테스트합니다. gitlab 이 표시되면 다른 우회 방법을 사용합니다. 테스트를 마친 뒤에는 before_script를 제거할 수 있습니다.

    apifuzzer_fuzz:
  image:
    name: $SECURE_ANALYZERS_PREFIX/$FUZZAPI_IMAGE:$FUZZAPI_VERSION$FUZZAPI_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-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

  • 컨테이너를 감싸 빌드 시점에 필요한 의존성을 추가합니다. 이 방법은 루트보다 낮은 권한으로 실행하는 이점이 있으며, 일부 고객에게는 이 점이 요구 사항일 수 있습니다.

    1. 기존 이미지를 감싸는 새 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 gitlab

    2. 새 이미지를 빌드하고 API 퍼징 job 이 시작되기 전에 로컬 컨테이너 레지스트리에 푸시합니다. 이 이미지는 job 이 완료된 뒤 제거해야 합니다.

      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_IMAGE

    3. apifuzzer_fuzz job을 확장하고 새 이미지 이름을 사용합니다.

      apifuzzer_fuzz:
  image: apifuzz-$CI_COMMIT_SHA

    4. 레지스트리에서 임시 컨테이너를 제거합니다. 컨테이너 이미지를 제거하는 방법은 이 문서 페이지를 참고합니다.

  • 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 구성 변수의 값을 파싱할 수 없다는 뜻입니다.

오류 메시지

이 문제는 두 가지 오류 메시지로 식별할 수 있습니다. 첫 번째 오류 메시지는 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.

해결 방법

이 문제는 FUZZAPI_REQUEST_HEADERS 또는 FUZZAPI_REQUEST_HEADERS_BASE64 변수 형식이 잘못되어 발생합니다. 기대하는 형식은 Header: value 형태의 헤더 하나 이상을 쉼표로 구분한 것입니다. 해결 방법은 기대 형식에 맞게 구문을 고치는 것입니다.

유효한 예시:

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

유효하지 않은 예시:

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