문제 해결

API 퍼징 작업이 N 시간 후에 시간 초과됨

더 큰 리포지토리의 경우, API 퍼징 작업이 기본적으로 설정된 리눅스의 작은 호스팅 러너에서 시간 초과될 수 있습니다. 작업에서 이러한 일이 발생하면 더 큰 러너로 확장해야 합니다.

도움이 필요하면 다음 문서 섹션을 참조하세요:

API 퍼징 작업이 완료되는 데 너무 오래 걸림

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

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

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

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

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

  1. 이 문제 해결 섹션을 참조하고, 문제를 동적 분석 팀에 에스컬레이션해 달라고 요청하세요.
  2. 작업의 전체 콘솔 출력을 제공하세요.
  3. 작업 아티팩트로 제공되는 gl-api-security-scanner.log 파일을 제공하세요. 작업 세부정보 페이지의 오른쪽 패널에서 Browse 버튼을 선택하세요.
  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 퍼징 엔진은 스캐너 애플리케이션 구성 요소와 연결을 설정하지 못할 때 오류 메시지를 출력합니다. 오류 메시지는 apifuzzer_fuzz 작업의 작업 출력 창에서 표시됩니다. 이 문제의 일반적인 원인은 백그라운드 구성 요소가 이미 사용 중인 포트를 사용할 수 없기 때문입니다. 이 오류는 타이밍이 중요한 경우(경합 조건) 간헐적으로 발생할 수 있습니다. 이 문제는 다른 서비스가 컨테이너에 매핑되어 포트 충돌을 일으킬 때 Kubernetes 환경에서 가장 자주 발생합니다.

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

  1. 작업 콘솔로 이동하세요.

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

  3. 텍스트 편집기에서 gl-api-security-scanner.log 파일을 열어보세요.

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

  • GitLab 15.5 및 이후:

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

  • GitLab 15.4 및 이전 버전:

    Failed to bind to address http://[::]:5000: address already in use.

이전 메시지의 텍스트 http://[::]:5000이 여러분의 경우와 다를 수 있으며, 예를 들어 http://[::]:5500 또는 http://127.0.0.1:5500일 수 있습니다. 오류 메시지의 나머지 부분이 동일하면 포트가 이미 사용 중이라는 것을 안전하게 가정할 수 있습니다.

포트가 이미 사용 중이라는 증거를 찾지 못한 경우, 작업 콘솔 출력에서 동일한 오류 메시지를 다루는 다른 문제 해결 섹션을 확인하세요. 추가 옵션이 없다면, 적절한 경로를 통해 지원 요청 또는 개선 요청을 자유롭게 하세요.

포트가 이미 사용 중이라는 문제를 확인한 후, GitLab 15.5 및 이후에서 FUZZAPI_API_PORT 구성 변수를 도입했습니다. 이 구성 변수는 스캐너 백그라운드 구성 요소의 고정 포트 번호를 설정할 수 있습니다.

해결책

  1. .gitlab-ci.yml 파일에서 FUZZAPI_API_PORT 구성 변수를 정의했는지 확인하세요.

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

오류: 문서의 유효성 검증 중 발행된 OpenAPI 스키마를 사용하여 오류가 발견되었습니다

API 퍼징 작업의 시작 시 OpenAPI 사양이 발행된 스키마와 검증됩니다. 제공된 OpenAPI 사양에 유효성 검사 오류가 있는 경우 이 오류가 표시됩니다:

오류, OpenAPI 문서가 유효하지 않습니다.
문서의 유효성 검증 중 발행된 OpenAPI 스키마를 사용하여 오류가 발견되었습니다.

OpenAPI 사양을 수동으로 생성할 때 및 스키마가 생성될 때 오류가 발생할 수 있습니다.

자동으로 생성된 OpenAPI 사양의 경우 유효성 검사 오류는 종종 누락된 코드 주석의 결과입니다.

오류 메시지

  • 오류, 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 퍼징 엔진은 스캐너 애플리케이션 구성 요소와 연결을 설정할 수 없을 때 오류 메시지를 출력합니다. 오류 메시지는 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 Fuzzing 분석기는 다양한 출처를 확인하면서 대상 API를 얻기 위해 우선 순위를 따릅니다. 먼저 FUZZAPI_TARGET_URL를 사용하려고 시도합니다. 환경 변수가 설정되지 않은 경우, API Fuzzing 분석기는 environment_url.txt 파일을 사용하려고 시도합니다. environment_url.txt 파일이 없는 경우, API Fuzzing 분석기는 OpenAPI 문서 내용과 FUZZAPI_OPENAPI에 제공된 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 Fuzzing은 사용할 URL이 포함된 environment_url.txt 파일을 지원합니다. 이 파일은 저장소에 체크인되지 않으며, 대신 테스트 대상을 배포하는 작업 중에 파이프라인에서 생성되고, 나중에 파이프라인의 다른 작업에서 사용할 수 있는 아티팩트로 수집됩니다. environment_url.txt 파일을 생성하는 작업은 API Fuzzing 작업 전에 실행되어야 합니다.

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

예시:

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

  artifacts:
    paths:
      - environment_url.txt

유효하지 않은 스키마로 OpenAPI 사용하기

문서가 유효하지 않은 스키마로 자동 생성되거나 적시에 수동으로 수정할 수 없는 경우가 있습니다. 이러한 시나리오에서는 FUZZAPI_OPENAPI_RELAXED_VALIDATION 변수를 설정하여 API Fuzzing이 느슨한 검증을 수행할 수 있습니다. 예상치 못한 동작을 방지하기 위해 완벽하게 호환되는 OpenAPI 문서를 제공하는 것이 좋습니다.

OpenAPI 파일 수정하기

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

Editor 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 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에 비TLS 연결을 사용할 수 없는 경우, 지원 팀에 문의하여 도움을 받으세요.

테스트 SSL.sh 도구를 사용하여 조사를 ускорить할 수 있습니다. bash 셸과 영향을 받은 서버에 연결할 수 있는 기기에서:

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

ERROR: 작업 실패: 이미지 가져오기 실패

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

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

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:이미지 가져오기 정책 "항상"으로 실패: 데몬의 오류 응답: Get https://registry.example.com/my-target-app/manifests/latest: unauthorized (manager.go:237:0s)
ERROR: 작업 실패: 지정된 정책 [항상]으로 이미지 "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: 작업 실패: 이미지 가져오기 실패 다음에 데몬의 오류 응답: Get 이미지: unauthorized가 표시됩니다.

해결책

인증 자격 증명은 프라이빗 컨테이너 레지스트리에서 이미지에 접근하기 문서 섹션에 설명된 방법을 사용하여 제공합니다. 사용되는 방법은 컨테이너 레지스트리 제공업체 및 해당 구성에 따라 달라집니다. Azure, Google Cloud (GCP), AWS 등과 같은 타사에서 제공하는 컨테이너 레지스트리를 사용하는 경우, 해당 제공업체의 문서를 확인하여 인증하는 방법에 대한 정보를 확인하세요.

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

  1. 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로 가져올 수 있습니다. 성공하면 작업 콘솔은 다음과 같은 출력을 보여줍니다:

    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: "no new privileges" 플래그가 설정되어 있어 sudo가 root로 실행되는 것을 방지합니다.

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

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

오류 메시지

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

$ sudo apk add nodejs

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

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

해결책

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

  • 컨테이너를 root 사용자로 실행합니다. 이 구성을 테스트하는 것이 권장되며, 모든 경우에 작동하지 않을 수 있습니다. 이는 CICD 구성을 수정하고 작업 출력을 확인하여 whoami가 root를 반환하는지 확인함으로써 수행할 수 있습니다. 만약 gitlab이 표시된다면 다른 우회 방법을 사용하세요. 테스트 후에는 before_script를 제거할 수 있습니다.

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

    예제 작업 콘솔 출력:

    작업 스크립트의 "step_script" 단계 실행 중
registry.gitlab.com/security-products/api-security:5에 대한 docker 이미지 sha256:8b95f188b37d6b342dc740f68557771bb214fe520a5dc78a88c7a9cc6a0f9901 사용 중 
$ whoami
root
$ /peach/analyzer-api-fuzzing
17:17:14 [INF] API 보안: Gitlab API 보안
17:17:14 [INF] API 보안: -------------------
17:17:14 [INF] API 보안:
17:17:14 [INF] API 보안: 버전: 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 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. 레지스트리에서 임시 컨테이너를 제거합니다. 컨테이너 이미지 제거에 대한 이 문서 페이지를 참조하세요.

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

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

이 오류 메시지는 API 퍼징 분석기가 FUZZAPI_REQUEST_HEADERS 또는 FUZZAPI_REQUEST_HEADERS_BASE64 구성 변수의 값을 분석할 수 없음을 나타냅니다.

오류 메시지

이 문제는 두 개의 오류 메시지로 식별할 수 있습니다. 첫 번째 오류 메시지는 작업 콘솔 출력에서 볼 수 있으며, 두 번째는 gl-api-security-scanner.log 파일에서 볼 수 있습니다.

작업 콘솔의 오류 메시지:

05:48:38 [ERR] API 보안: 테스트 실패: 예상치 못한 예외가 발생했습니다: 인덱스가 배열의 범위를 벗어났습니다.

gl_api_security-scanner.log의 오류 메시지:

08:45:43.616 [ERR] <Peach.Web.Core.Services.WebRunnerMachine> WebRunnerMachine::Run()에서 예기치 않은 예외 발생
System.IndexOutOfRangeException: 인덱스가 배열의 범위를 벗어났습니다.
   at Peach.Web.Runner.Services.RunnerOptions.GetHeaders() in /builds/gitlab-org/security-products/analyzers/api-fuzzing-src/web/PeachWeb/Runner/Services/[RunnerOptions.cs:line 362
   at Peach.Web.Runner.Services.RunnerService.Start(Job job, IRunnerOptions options) in /builds/gitlab-org/security-products/analyzers/api-fuzzing-src/web/PeachWeb/Runner/Services/RunnerService.cs:line 67
   at Peach.Web.Core.Services.WebRunnerMachine.Run(IRunnerOptions runnerOptions, CancellationToken token) in /builds/gitlab-org/security-products/analyzers/api-fuzzing-src/web/PeachWeb/Core/Services/WebRunnerMachine.cs:line 321
08:45:43.634 [WRN] <Peach.Web.Core.Services.WebRunnerMachine> * 세션 실패: 예상치 못한 예외가 발생했습니다: 인덱스가 배열의 범위를 벗어났습니다.
08:45:43.677 [INF] <Peach.Web.Core.Services.WebRunnerMachine> 테스트 완료. 총 0개의 요청을 수행했습니다.

해결책

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