웹 API를 테스트해 다른 QA 프로세스가 놓칠 수 있는 버그와 잠재적 보안 이슈를 찾아냅니다. API 보안 테스팅은 다른 보안 스캐너 및 자체 테스트 프로세스에 더해 사용합니다. API 보안 테스팅 테스트는 CI/CD 워크플로의 일부로 실행하거나, 온디맨드로 실행하거나, 두 방식을 함께 사용할 수 있습니다.

시작하기#

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 Stage 다음에 dast Stage가 CI/CD 파이프라인 정의에 추가되어 있어야 합니다. 예를 들면 다음과 같습니다:

  stages:
    - build
    - test
    - deploy
    - dast
  

API 보안 테스팅을 활성화하려면 환경의 요구 사항에 맞게 GitLab CI/CD 구성 YAML을 수정해야 합니다. 스캔할 API는 다음으로 지정할 수 있습니다:

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

결과 이해하기#

보안 스캔의 출력을 확인하려면:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.
3. 파이프라인을 선택합니다.
4. Security 탭을 선택합니다.
5. 취약점을 선택해 다음을 포함한 세부 정보를 확인합니다:
   • Status: 취약점이 분류되었는지 또는 해결되었는지를 나타냅니다.
   • Description: 취약점의 원인, 잠재적 영향, 권장 조치 단계를 설명합니다.
   • Severity: 영향도에 따라 여섯 단계로 분류됩니다. 심각도 수준 자세히 보기.
   • Scanner: 해당 취약점을 탐지한 분석기를 식별합니다.
   • Method: 취약한 서버 상호 작용 유형을 확인합니다.
   • URL: 취약점의 위치를 표시합니다.
   • Evidence: 해당 취약점의 존재를 증명하는 테스트 케이스를 설명합니다.
   • Identifiers: CWE 식별자처럼 취약점을 분류하는 데 사용한 참조 목록.

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

• 파이프라인의 Security 탭에서 Download results를 선택합니다.

자세한 내용은 파이프라인 보안 보고서를 참고합니다.

최적화#

API 보안 테스팅을 최대한 활용하려면 다음 권장 사항을 따릅니다:

• 최신 버전의 분석기를 실행하도록 러너에 always 풀 정책을 구성합니다.

• 기본적으로 API 보안 테스팅은 파이프라인의 이전 job 이 정의한 모든 아티팩트를 다운로드합니다. DAST job 이 테스트 대상 URL을 정의하는 environment_url.txt 나 이전 job 이 생성한 다른 파일에 의존하지 않는다면 아티팩트를 다운로드하지 않아야 합니다. 아티팩트 다운로드를 피하려면 분석기 CI/CD job을 확장해 의존성이 없음을 지정합니다. 예를 들어 API 보안 테스팅 분석기라면 .gitlab-ci.yml 파일에 다음을 추가합니다:

  api_security:
    dependencies: []
  

특정 애플리케이션이나 환경에 맞게 API 보안 테스팅을 구성하려면 구성 옵션 전체 목록을 참고합니다.

배포#

CI/CD 파이프라인에서 실행할 때 API 보안 테스팅 스캐닝은 기본적으로 dast Stage에서 실행됩니다. API 보안 테스팅 스캐닝이 최신 코드를 검사하도록 하려면 CI/CD 파이프라인이 dast Stage 이전 Stage에서 테스트 환경에 변경 사항을 배포하도록 합니다.

파이프라인이 실행할 때마다 같은 웹 서버에 배포하도록 구성되어 있다면, 다른 파이프라인이 아직 실행 중인 상태에서 파이프라인을 실행할 경우 한 파이프라인이 다른 파이프라인의 코드를 덮어쓰는 경쟁 조건이 발생할 수 있습니다. 스캔 대상 API는 API 보안 테스팅 스캔이 진행되는 동안 변경에서 제외해야 합니다. API에 가해지는 변경은 API 보안 테스팅 스캐너에 의한 것뿐이어야 합니다. 스캔 중 API에 발생한 변경(예: 사용자, 예약 작업, 데이터베이스 변경, 코드 변경, 다른 파이프라인, 다른 스캐너에 의한 변경)은 부정확한 결과로 이어질 수 있습니다.

API 보안 테스팅 스캐닝 구성 예제#

다음 프로젝트는 API 보안 테스팅 스캐닝을 보여 줍니다:

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

애플리케이션 배포 옵션#

API 보안 테스팅에는 스캔할 수 있도록 배포된 애플리케이션이 필요합니다.

대상 애플리케이션의 복잡도에 따라 API 보안 테스팅 템플릿을 배포하고 구성하는 방법은 몇 가지가 있습니다.

리뷰 앱#

리뷰 앱은 DAST 대상 애플리케이션을 배포하는 방법 중 가장 손이 많이 가는 방식입니다. 이 과정을 돕기 위해 GitLab은 Google Kubernetes Engine(GKE)을 사용하는 리뷰 앱 배포를 만들었습니다. 이 예제는 Review Apps - GKE 프로젝트에서 확인할 수 있으며, DAST 용 리뷰 앱을 구성하는 자세한 지침은 README.md에 있습니다.

Docker 서비스#

애플리케이션이 Docker 컨테이너를 사용한다면 DAST로 배포하고 스캔하는 또 다른 방법이 있습니다. Docker 빌드 job 이 완료되고 이미지가 컨테이너 레지스트리에 추가된 뒤에는 그 이미지를 서비스로 사용할 수 있습니다.

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

job에 services 섹션을 추가할 때 alias는 해당 서비스에 접근할 때 사용할 호스트 이름을 정의합니다. 다음 예제에서 dast job 정의의 alias: yourapp 부분은 배포된 애플리케이션의 URL 이 yourapp을 호스트 이름으로 사용한다는 의미입니다(https://yourapp/).

stages:
  - build
  - dast

include:
  - template: API-Security.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

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

variables:
  APISEC_TARGET_URL: https://yourapp

대부분의 애플리케이션은 데이터베이스나 캐시 서비스 같은 여러 서비스에 의존합니다. 기본적으로 services 필드에 정의된 서비스는 서로 통신할 수 없습니다. 서비스 간 통신을 허용하려면 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

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

특정 문제에 대한 지원이 필요하면 도움받기 채널을 이용합니다.

GitLab.com의 GitLab 이슈 트래커는 API 보안 테스팅에 관한 버그와 기능 제안을 올리기에 적합한 곳입니다. API 보안 테스팅에 관한 새 이슈를 열 때 ~"Category:API Security" 레이블을 사용하면 적임자가 빠르게 검토합니다.

직접 이슈를 제출하기 전에 이슈 트래커에서 검색해 비슷한 항목이 있는지 확인합니다. 다른 사람이 같은 이슈나 기능 제안을 이미 올렸을 가능성이 높습니다. 이모지 반응으로 지지를 표시하거나 논의에 참여할 수 있습니다.

기대한 대로 동작하지 않는 상황을 겪었다면 다음과 같은 컨텍스트 정보를 함께 제공하는 것을 고려합니다:

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

용어집#

• Assert: 어설션은 취약점을 유발하기 위해 체크가 사용하는 탐지 모듈입니다. 다수의 어설션에는 설정이 있습니다. 하나의 체크는 여러 어설션을 사용할 수 있습니다. 예를 들어 로그 분석, 응답 분석, 상태 코드는 체크가 함께 사용하는 일반적인 어설션입니다. 여러 어설션을 사용하는 체크는 각 어설션을 켜고 끌 수 있습니다.
• Check: 특정 유형의 테스트를 수행하거나 특정 취약점 유형을 점검합니다. 예를 들어 SQL 인젝션 체크는 SQL 인젝션 취약점에 대한 DAST 테스팅을 수행합니다. API 보안 테스팅 스캐너는 여러 체크로 구성됩니다. 체크는 프로필에서 켜고 끌 수 있습니다.
• Profile: 구성 파일에는 하나 이상의 테스팅 프로필, 즉 하위 구성이 있습니다. 기능 브랜치용 프로필과 main 브랜치용 추가 테스팅 프로필을 따로 둘 수 있습니다.