Troubleshooting

API Fuzzing 작업이 N시간 후에 타임 아웃됨

대형 저장소의 경우 Linux에서 호스팅된 작은 러너에서 설정된 기본값 때문에 API Fuzzing 작업이 타임 아웃될 수 있습니다. 작업 중에 이 문제가 발생하면 더 큰 러너로 확장해야 합니다.

지원을 위한 다음 문서 섹션을 참조하세요:

API Fuzzing 작업이 완료하는 데 시간이 너무 오래 걸림

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

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

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

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

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

  1. 이 문제를 컨텍스트에 맞게 다루도록 이 문제 해결에 대한 지원 요청과 함께 이 문제 해결 모듈로 escallation을 요청하세요.
  2. 작업의 전체 콘솔 출력.
  3. 작업 세부 정보 페이지의 오른쪽 패널에서 찾아보기 버튼을 선택하여 사용 가능한 작업 아티팩트인 gl-api-security-scanner.log 파일을 선택합니다.
  4. .gitlab-ci.yml 파일에서 apifuzzer_fuzz 작업 정의.

오류 메시지

  • GitLab 15.6 및 이후에서, Error waiting for API Fuzzing 'http://127.0.0.1:5000' to become available
  • GitLab 15.5 및 이전에서, Error waiting for API Security 'http://127.0.0.1:5000' to become available.

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

API Fuzzing 엔진은 스캐너 애플리케이션 구성 요소와 연결을 설정하지 못하면 오류 메시지가 발생합니다. 해당 에러 메시지는 apifuzzer_fuzz 작업의 작업 출력 창에 표시됩니다. 이 문제의 일반적인 원인은 백그라운드 구성요소가 이미 사용 중인 선택한 포트를 사용할 수 없을 때 발생합니다. 이 오류는 타이밍이 관련된 경우 가끔 발생할 수 있습니다. 이 문제는 다른 서비스가 컨테이너에 매핑될 때 포트 충돌이 발생하는 쿠버네티스 환경에서 가장 자주 발생합니다.

해결책을 진행하기 전에, 이 문제가 발생한 이유가 포트가 이미 사용 중이어서 생긴 것인지 확인하는 것이 중요합니다. 이것이 원인이었는지 확인하려면:

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

해결책

  1. .gitlab-ci.yml 파일이 FUZZAPI_API_PORT 구성 변수를 정의하는지 확인하세요.
  2. FUZZAPI_API_PORT의 값을 1024보다 큰 사용 가능한 포트 번호로 업데이트하세요. 새 값이 GitLab에 의해 사용되고 있지 않은지 확인하는 것을 권장합니다. 패키지 기본값에서 GitLab이 사용하는 포트의 전체 목록을 확인하세요.

오류: 게시된 OpenAPI 스키마를 사용하여 문서의 유효성을 확인하는 중에 오류가 발견되었습니다

API Fuzzing 작업 시작 시 OpenAPI 명세서가 게시된 스키마에 대해 유효성 검사됩니다. 이 오류는 제공된 OpenAPI 명세서에 유효성 오류가 있을 때 표시됩니다: 

오류, OpenAPI 문서가 유효하지 않습니다.
게시된 OpenAPI 스키마를 사용하여 문서의 유효성을 확인하는 중에 오류가 발견되었습니다

오픈API 명세서를 생성하는 경우에는 유효성 오류가 일반적으로 코드 주석이 누락된 결과물로 보입니다.

오류 메시지

  • 오류, OpenAPI 문서가 유효하지 않습니다. 게시된 OpenAPI 스키마를 사용하여 문서의 유효성을 확인하는 중에 오류가 발견되었습니다
    • OpenAPI 2.0 스키마 검증 오류 ...
    • OpenAPI 3.0.x 스키마 검증 오류 ...

해결책

자동으로 생성된 OpenAPI 명세서의 경우

  1. 유효성 오류를 식별합니다.
    1. Swagger Editor를 사용하여 명세서의 유효성 문제를 식별하세요. Swagger Editor의 시각적인 특성은 어떤 부분을 변경해야 하는지 이해하기 쉽게 만들어줍니다.
    2. 또는 로그 출력을 확인하고 스키마 유효성 검증 경고를 찾으세요. 이러한 경고는 OpenAPI 2.0 스키마 검증 오류 또는 OpenAPI 3.0.x 스키마 검증 오류와 같은 메시지로 시작합니다. 각 실패한 유효성은 위치 및 설명에 대한 추가 정보를 제공합니다. JSON 스키마 유효성 검증 메시지는 복잡할 수 있으며, 편집기는 스키마 문서의 유효성을 확인하는 데 도움이 될 수 있습니다.
  2. 사용 중인 프레임워크/기술 스택의 OpenAPI 생성을 위한 문서를 검토하세요. 올바른 OpenAPI 문서를 생성하기 위해 필요한 변경 사항을 식별하세요.
  3. 유효성 문제가 해결되면 파이프라인을 다시 실행하세요.

수동으로 생성된 OpenAPI 명세서의 경우

  1. 유효성 오류를 식별합니다.
    1. 가장 간단한 해결책은 시각적 도구를 사용하여 OpenAPI 문서를 편집하고 유효성을 검사하는 것입니다. 예를 들어 Swagger Editor는 스키마 오류를 강조하여 가능한 해결책을 제시합니다.
    2. 또는 로그 출력을 확인하고 스키마 유효성 검증 경고를 찾으세요. 이러한 경고는 OpenAPI 2.0 스키마 검증 오류 또는 OpenAPI 3.0.x 스키마 검증 오류와 같은 메시지로 시작합니다. 각 실패한 유효성은 위치 및 설명에 대한 추가 정보를 제공합니다. 이러한 검증 실패를 올바르게 하고 OpenAPI 문서를 다시 제출하세요. JSON 스키마 유효성 검증 메시지는 복잡할 수 있으며, 편집기는 스키마 문서의 유효성을 확인하는 데 도움이 될 수 있습니다.
  2. 유효성 문제가 해결되면 파이프라인을 다시 실행하세요.

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

API Fuzzing 엔진은 스캐너 애플리케이션 구성 요소와의 연결을 확립할 수 없을 때 오류 메시지를 출력합니다. 이 오류 메시지는 apifuzzer_fuzz 작업의 작업 출력 창에 표시됩니다. 이 문제의 일반적인 원인 중 하나는 FUZZAPI_API 변수를 기본값에서 변경하는 것입니다.

오류 메시지

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

해결 방법

  • .gitlab-ci.yml 파일에서 FUZZAPI_API 변수를 제거하세요. 이 값은 API Fuzzing CI/CD 템플릿에서 상속됩니다. 수동으로 값을 설정하는 대신 이 방법을 권장합니다.
  • 변수를 제거할 수 없는 경우, 최신 API Fuzzing CI/CD 템플릿에서이 값이 변경되었는지 확인한 후 .gitlab-ci.yml 파일에서 값을 업데이트하세요.

응용 프로그램은 대상 API의 기본 URL을 결정할 수 없음

API Fuzzing 분석기는 OpenAPI 문서를 검사한 후 대상 API를 결정할 수 없을 때 오류 메시지를 출력합니다. 이 오류 메시지는 .gitlab-ci.yml 파일에 대상 API가 설정되어 있지 않고 environment_url.txt 파일에 사용할 수 없으며 OpenAPI 문서를 사용하여 대상 API를 계산할 수 없는 경우 표시됩니다.

서로 다른 소스를 확인할 때 API Fuzzing 분석기가 대상 API를 가져오기 위한 우선순위가 있습니다. 먼저 FUZZAPI_TARGET_URL을 사용하려고 시도합니다. 환경 변수가 설정되지 않은 경우 API Fuzzing 분석기는 environment_url.txt 파일을 사용하려고 시도합니다. environment_url.txt 파일이 없는 경우 API Fuzzing 분석기는 이제 OpenAPI 문서 내용과 FUZZAPI_OPENAPI에서 제공된 URL(제공된 경우)을 사용하여 대상 API를 계산하려고 시도합니다.

최적의 해결 방법은 각 배포마다 대상 API가 변경되는지 여부에 따라 다릅니다:

정적 환경 솔루션

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

환경 변수 추가

대상 API가 동일한 경우, 대상 URL을 FUZZAPI_TARGET_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 Fuzzing은 사용할 URL이 포함 된 environment_url.txt 파일을 지원합니다. 이 파일은 리포지토리에 체크인되지 않으며 대신 테스트 대상을 배포하는 작업에 의해 생성되고 나중에 파이프라인의 나중 작업에서 사용할 수있는 Artifact로 수집됩니다. environment_url.txt 파일을 생성하는 작업은 API Fuzzing 작업 이전에 실행해야 합니다.

  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 Fuzzing은 FUZZAPI_OPENAPI_RELAXED_VALIDATION 변수를 설정하여 완전히 호환되는 OpenAPI 문서를 제공하는 것을 권장합니다.

부적합한 OpenAPI 파일 수정

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

편집기 OpenAPI 2.0 OpenAPI 3.0.x OpenAPI 3.1.x
Swagger 에디터 YAML, JSON YAML, JSON YAML, JSON
Stoplight Studio YAML, JSON YAML, JSON YAML, JSON

수동으로 OpenAPI 문서를 생성한 경우 편집기에 문서를 로드하고 준수하지 않는 부분을 수정하세요. 자동으로 문서를 생성한 경우에는 편집기에서 스키마의 문제점을 식별한 다음 애플리케이션으로 이동하여 사용 중인 프레임워크를 기반으로 수정을 수행하세요.

OpenAPI 완화된 유효성 활성화

완전히 준수하지 않더라도 여러 도구에서 사용할 수있는 내용이 있는 경우, 완화된 유효성을 수행하지만 문서 스키마에 대해 덜 엄격하게 수행됩니다.

API Fuzzing은 여전히 OpenAPI 사양을 완전히 준수하지 않는 OpenAPI 문서를 처리할 수 있습니다. API Fuzzing 분석기에 완화된 유효성을 수행하도록 지시하려면 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'

OpenAPI 문서에는 지원되는 미디어 유형을 사용하는 작업이 하나도 없습니다

API Fuzzing은 OpenAPI 문서에 지정된 미디어 유형을 사용하여 요청을 생성합니다. 지원되는 미디어 유형이 없어서 요청을 생성할 수 없는 경우에는 오류가 발생합니다.

에러 메시지

  • 오류, OpenAPI 문서에는 지원되는 미디어 유형을 사용하는 작업이 하나도 없습니다. 'OpenAPI Specification'을 확인하여 지원되는 미디어 유형을 확인하세요.

해결 방법

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

에러: SSL 연결을 설정할 수 없음, 내부 예외를 확인하세요.

API fuzzing은 오래된 프로토콜 및 암호를 포함한 다양한 TLS 구성과 호환됩니다. 널리 지원되지만 다음과 같은 연결 오류가 발생할 수 있습니다. 

오류, `<URL>`에서 컨텐츠를 다운로드하는 중 오류가 발생했습니다:
Uri에서 컨텐츠를 검색하는 중 오류가 발생했습니다.' <URL>'.
오류:SSL 연결을 설정할 수 없음, 내부 예외를 확인하세요.

이 오류는 API fuzzing이 주어진 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

만약 URL에 비한 데이터 연결을 사용할 수 없는 경우, 지원팀에 문의하세요.

테스트 SSL.sh 도구를 사용하여 조사를 빠르게 진행할 수 있습니다. 영향을 받는 서버로부터의 검증 및 연결을 확인하는데 필요합니다.

  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

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

작업 콘솔 출력에서 오류는 다음과 같습니다: 

gitlab-runner 15.6.0~beta.186.ga889181a (a889181a)로 실행 중
  on blue-2.shared.runners-manager.gitlab.com/default XxUrkriX
비밀번호 해결 중
00:00
' 도커+머신' 실행기 준비 중
00:06
Docker 실행자를 사용하여 registry.gitlab.com/security-products/api-security:2 이미지로 시작 중...
서비스 registry.example.com/my-target-app:latest 시작 중...
도커 이미지 registry.example.com/my-target-app:latest 불러오는 중...
경고: "항상" 정책을 사용하여 이미지를 불러올 수 없습니다: 데몬으로부터의 오류 응답: Get https://registry.example.com/my-target-app/manifests/latest: unauthorized (manager.go:237:0s)
오류: 작업 실패: 지정된 정책인 "항상"으로 이미지 "registry.example.com/my-target-app:latest"을(를) 불러올 수 없습니다: 데몬으로부터의 오류 응답: 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 등 타사 클라우드 제공 업체의 컨테이너 레지스트리를 사용하는 경우, 해당 업체의 문서를 확인하여 컨테이너 레지스트리에 인증하는 방법에 대한 정보를 확인하세요.

다음 예제는 정적으로 정의된 자격 증명 인증 방법을 사용합니다. 이 예제에서 컨테이너 레지스트리는 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. 작업을 다시 실행하면 정적으로 정의된 자격 증명이 사용되어 프라이빗 컨테이너 레지스트리 registry.example.com에 로그인하고 이미지 my-target-app:latest을 가져올 수 있습니다. 성공하면 작업 콘솔에 다음과 같은 출력이 나타납니다: 

    gitlab-runner 15.6.0~beta.186.ga889181a (a889181a)로 실행 중
  on blue-4.shared.runners-manager.gitlab.com/default J2nyww-s
비밀번호 해결 중
00:00
'도커+머신' 실행기 준비 중
00:56
Docker 실행자를 사용하여 registry.gitlab.com/security-products/api-security:2 이미지로 시작 중...
서비스 registry.example.com/my-target-app:latest 시작 중...
$DOCKER_AUTH_CONFIG의 자격 증명을 사용하여 인증 중
Docker 이미지 registry.example.com/my-target-app:latest 빌드 중...
digest registry.example.com/my-target-
app@sha256:2b69fc7c3627dbd0ebaa17674c264fcd2f2ba21ed9552a472acf8b065d39039c를 사용하는 docker 이미지 sha256:139c39668e5e4417f7d0eb0eeb74145ba862f4f3c24f7c6594ecb2f82dc4ad06 ...
서비스가 실행 및 작동 중인지 기다리는 중(타임아웃 30초)...

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 구성을 수정하고 작업 출력을 확인하여 whoami가 root가 아니라 gitlab을 반환하지 않는지 확인함으로써 수행할 수 있습니다. 만약 gitlab이 표시된다면 다른 해결 방법을 사용하세요. 테스트가 완료되면 before_script를 삭제할 수 있습니다. 

    apifuzzer_fuzz:
  image:
    name: $SECURE_ANALYZERS_PREFIX/$FUZZAPI_IMAGE:$FUZZAPI_VERSION$FUZZAPI_IMAGE_SUFFIX
    docker:
      user: root
 before_script:
   - whoami

    작업 콘솔 출력 예시: 

    작업 스크립트 단계를 실행하는 중
registry.gitlab.com/security-products/api-security:5에서 registry.gitlab.com/security-products/api-security@sha256:092909baa2b41db8a7e3584f91b982174772abdfe8ceafc97cf567c3de3179d1에 대한 도커 이미지 sha256:8b95f188b37d6b342dc740f68557771bb214fe520a5dc78a88c7a9cc6a0f9901 사용 중...
$ whoami
root
$ /peach/analyzer-api-fuzzing
17:17:14 [INF] API Security: Gitlab API Security
17:17:14 [INF] API Security: -------------------
17:17:14 [INF] API Security:
17:17:14 [INF] API Security: version: 5.7.0

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

    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 Fuzzing 작업을 시작하기 전에 로컬 컨테이너 레지스트리에 푸시합니다. 작업이 완료된 후에는 이미지를 제거해야 합니다. 

      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 작업을 확장하고 새 이미지 이름을 사용합니다. 

      apifuzzer_fuzz:
  image: apifuzz-$CI_COMMIT_SHA

    4. 레지스트리에서 임시 컨테이너를 제거합니다. 이 문서 페이지에서 컨테이너 이미지 제거에 관한 정보를 확인하세요.

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

Index was outside the bounds of the array. at Peach.Web.Runner.Services.RunnerOptions.GetHeaders()

이 오류 메시지는 API Fuzzing 분석기가 FUZZAPI_REQUEST_HEADERS 또는 FUZZAPI_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.

해결 방법

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