웹 API 퍼즈 테스팅은 API 동작 매개변수에 예상치 못한 값을 전달하여 백엔드에서 예상치 못한 동작과 오류를 유발합니다. 퍼즈 테스팅을 사용하여 다른 QA 프로세스에서 놓칠 수 있는 버그와 잠재적 취약성을 발견합니다.

GitLab Secure의 다른 보안 스캐너와 자체 테스트 프로세스에 추가로 퍼즈 테스팅을 사용해야 합니다. GitLab CI/CD를 사용하는 경우 CI/CD 워크플로우의 일부로 퍼즈 테스트를 실행할 수 있습니다.

개요는 웹 API 퍼징 - 고급 보안 테스팅을 참조하세요.

시작하기#

CI/CD 구성을 편집하여 API 퍼징을 시작합니다.

필수 조건:

• 지원되는 API 유형 중 하나를 사용하는 웹 API:

  • REST API
  • SOAP
  • GraphQL
  • 폼 본문, JSON 또는 XML

• 다음 형식 중 하나의 API 사양:

  • OpenAPI v2 또는 v3 사양
  • GraphQL 스키마
  • HTTP Archive (HAR)
  • Postman Collection v2.0 또는 v2.1

• Linux/amd64에서 docker 실행기를 사용하는 사용 가능한 GitLab Runner.

• 배포된 대상 애플리케이션.

• deploy 스테이지 이후에 CI/CD 파이프라인 정의에 fuzz 스테이지가 추가되어 있어야 합니다:

  stages:
    - build
    - test
    - deploy
    - fuzz
  

API 퍼징을 활성화하려면:

• 웹 API 퍼징 구성 양식을 사용합니다.

  이 양식을 사용하면 가장 일반적인 API 퍼징 옵션에 대한 값을 선택하고, GitLab CI/CD 구성에 붙여넣을 수 있는 YAML 스니펫을 생성합니다.

결과 이해하기#

보안 스캔의 출력을 보려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 빌드 > 파이프라인을 선택합니다.
3. 파이프라인을 선택합니다.
4. 보안 탭을 선택합니다.
5. 다음을 포함한 세부 정보를 보려면 취약성을 선택합니다:
   • 상태: 취약성이 분류되었거나 해결되었는지 여부를 나타냅니다.
   • 설명: 취약성의 원인, 잠재적 영향 및 권장 수정 단계를 설명합니다.
   • 심각도: 영향을 기반으로 여섯 가지 수준으로 분류됩니다. 자세한 내용은 심각도 수준을 참조하세요.
   • 스캐너: 취약성을 감지한 분석기를 식별합니다.
   • 방법: 취약한 서버 상호 작용 유형을 확인합니다.
   • URL: 취약성의 위치를 표시합니다.
   • 증거: 특정 취약성의 존재를 증명하는 테스트 케이스를 설명합니다
   • 식별자: CWE 식별자와 같이 취약성을 분류하는 데 사용되는 참조 목록.

보안 스캔 결과를 다운로드할 수도 있습니다:

• 파이프라인의 보안 탭에서 결과 다운로드를 선택합니다.

자세한 내용은 파이프라인 보안 보고서를 참조하세요.

최적화#

API 퍼징을 최대한 활용하려면 다음 권장 사항을 따르세요:

• 최신 버전의 분석기를 실행하려면 pull_policy: always를 사용하도록 러너를 구성합니다.

• 기본적으로 API 퍼징은 파이프라인의 이전 작업에 의해 정의된 모든 아티팩트를 다운로드합니다. API 퍼징 작업이 테스트 중인 URL을 정의하기 위해 environment_url.txt나 이전 작업에서 생성된 다른 파일에 의존하지 않는 경우 아티팩트를 다운로드하지 않아야 합니다.

  아티팩트 다운로드를 방지하려면 분석기 CI/CD 작업을 확장하여 종속성 없음을 지정합니다. 예를 들어 API 퍼징 분석기의 경우 .gitlab-ci.yml 파일에 다음을 추가합니다:

  apifuzzer_fuzz:
    dependencies: []
  

애플리케이션 배포 옵션#

API 퍼징은 스캔할 배포된 애플리케이션이 필요합니다.

대상 애플리케이션의 복잡성에 따라 API 퍼징 템플릿을 배포하고 구성하는 방법에 몇 가지 옵션이 있습니다.

리뷰 앱#

리뷰 앱은 API 퍼징 대상 애플리케이션을 배포하는 가장 복잡한 방법입니다. 이 과정을 지원하기 위해 GitLab은 Google Kubernetes Engine(GKE)을 사용하는 리뷰 앱 배포를 생성했습니다. 이 예제는 리뷰 앱 - GKE 프로젝트에서 찾을 수 있으며, DAST에서 리뷰 앱을 구성하는 자세한 지침도 제공합니다.

Docker 서비스#

애플리케이션이 Docker 컨테이너를 사용하는 경우 API 퍼징으로 배포하고 스캔하는 또 다른 옵션이 있습니다. Docker 빌드 작업이 완료되고 이미지가 컨테이너 레지스트리에 추가된 후 이미지를 서비스로 사용할 수 있습니다.

.gitlab-ci.yml의 서비스 정의를 사용하여 DAST 분석기로 서비스를 스캔할 수 있습니다.

작업에 services 섹션을 추가할 때 alias는 서비스에 접근하는 데 사용할 수 있는 호스트 이름을 정의하는 데 사용됩니다. 다음 예에서 dast 작업 정의의 alias: yourapp 부분은 배포된 애플리케이션의 URL이 yourapp을 호스트 이름으로 사용함을 의미합니다: https://yourapp/.

stages:
  - build
  - fuzz

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

# Deploys the container to the GitLab container registry
deploy:
  services:
  - name: docker:dind
    alias: dind
  image: docker:20.10.16
  stage: build
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE:latest || true
    - docker build --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --tag $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest

apifuzzer_fuzz:
  services: # use services to link your app container to the dast job
    - name: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      alias: yourapp

variables:
  FUZZAPI_TARGET_URL: https://yourapp

대부분의 애플리케이션은 데이터베이스 또는 캐싱 서비스와 같은 여러 서비스에 의존합니다. 기본적으로 서비스 필드에 정의된 서비스는 서로 통신할 수 없습니다. 서비스 간 통신을 허용하려면 FF_NETWORK_PER_BUILD 기능 플래그를 활성화합니다.

variables:
  FF_NETWORK_PER_BUILD: "true" # enable network per build so all services can communicate on the same network

services: # use services to link the container to the dast job
  - name: mongo:latest
    alias: mongo
  - name: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    alias: yourapp

배포#

웹 API 퍼징은 CI/CD 파이프라인의 fuzz 스테이지에서 실행됩니다. API 퍼징이 최신 코드를 스캔하도록 하려면 CI/CD 파이프라인이 fuzz 스테이지 이전의 스테이지 중 하나에서 테스트 환경에 변경 사항을 배포해야 합니다.

파이프라인이 각 실행에서 동일한 웹 서버에 배포되도록 구성된 경우 다른 파이프라인이 아직 실행 중인 동안 파이프라인을 실행하면 하나의 파이프라인이 다른 파이프라인의 코드를 덮어쓰는 경쟁 조건이 발생할 수 있습니다. 스캔할 API는 퍼징 스캔 기간 동안 변경에서 제외되어야 합니다. API에 대한 유일한 변경은 퍼징 스캐너에 의한 것이어야 합니다. 스캔 중 API에 대한 변경(예: 사용자, 예약된 작업, 데이터베이스 변경, 코드 변경, 다른 파이프라인 또는 다른 스캐너에 의한)은 부정확한 결과를 초래할 수 있습니다.

다음 방법을 사용하여 웹 API 퍼징 스캔을 실행할 수 있습니다:

• OpenAPI 사양(버전 2 및 3)
• GraphQL 스키마
• HTTP 아카이브(HAR)
• Postman 컬렉션(버전 2.0 및 2.1)

API 퍼징 프로젝트 예제#

• OpenAPI v2 사양 예제 프로젝트
• HTTP 아카이브(HAR) 예제 프로젝트
• Postman Collection 예제 프로젝트
• GraphQL 예제 프로젝트
• SOAP 예제 프로젝트
• Selenium을 사용한 인증 토큰

지원 받기 또는 개선 요청하기#

특정 문제에 대한 지원을 받으려면 도움받기 채널을 사용합니다.

GitLab.com의 GitLab 이슈 트래커는 API 보안 및 API 퍼징에 관한 버그 및 기능 제안을 위한 올바른 장소입니다. 빠른 검토를 받으려면 API 퍼징에 관한 새 이슈를 열 때 ~"Category:API Security" 레이블을 사용하세요.

자신의 이슈를 제출하기 전에 유사한 항목에 대한 이슈 트래커를 검색합니다. 다른 사람이 같은 이슈나 기능 제안을 가졌을 가능성이 높습니다. 이모지 반응으로 지지를 표시하거나 토론에 참여하세요.

예상대로 작동하지 않는 동작이 발생하면 컨텍스트 정보를 제공하는 것을 고려하세요:

• GitLab Self-Managed 인스턴스를 사용하는 경우 GitLab 버전.
• .gitlab-ci.yml 작업 정의.
• 전체 작업 콘솔 출력.
• gl-api-security-scanner.log라는 작업 아티팩트로 사용 가능한 스캐너 로그 파일.

용어집#

• Assert: 어설션은 결함을 트리거하기 위해 체크에서 사용하는 감지 모듈입니다. 많은 어설션에 구성이 있습니다. 체크는 여러 어설션을 사용할 수 있습니다. 예를 들어 로그 분석, 응답 분석 및 상태 코드는 체크에 의해 함께 사용되는 일반적인 어설션입니다. 여러 어설션이 있는 체크는 켜고 끌 수 있습니다.
• Check: 특정 유형의 테스트를 수행하거나 취약성 유형을 확인합니다. 예를 들어 JSON 퍼징 체크는 JSON 페이로드의 퍼즈 테스팅을 수행합니다. API 퍼저는 여러 체크로 구성됩니다. 체크는 프로필에서 켜고 끌 수 있습니다.
• Fault: 퍼징 중에 어설션이 식별한 실패를 결함이라고 합니다. 결함은 보안 취약성인지, 비보안 이슈인지 또는 거짓 양성인지 결정하기 위해 조사됩니다. 결함은 조사될 때까지 알려진 취약성 유형이 없습니다. 취약성 유형의 예로는 SQL 인젝션 및 서비스 거부가 있습니다.
• Profile: 구성 파일에는 하나 이상의 테스팅 프로필 또는 하위 구성이 있습니다. 기능 브랜치용 프로필과 메인 브랜치에 대한 추가 테스팅이 있는 프로필을 가질 수 있습니다.