웹 API를 테스트하여 다른 QA 프로세스에서 놓칠 수 있는 버그와 잠재적인 보안 이슈를 발견합니다. 다른 보안 스캐너와 자체 테스트 프로세스에 추가하여 API 보안 테스팅을 사용합니다. API 보안 테스팅 테스트를 CI/CD 워크플로우의 일부로, 온디맨드로, 또는 둘 다로 실행할 수 있습니다.

시작하기#

CI/CD 구성을 편집하여 API 보안 테스팅을 시작합니다.

필수 조건:

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

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

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

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

  각 스캔은 정확히 하나의 사양을 지원합니다. 둘 이상의 사양을 스캔하려면 여러 스캔을 사용합니다.

• Linux/amd64에서 docker 실행기를 사용하는 GitLab Runner가 있어야 합니다.

• 배포된 대상 애플리케이션이 있어야 합니다. 자세한 내용은 배포 옵션을 참조하세요.

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

  stages:
    - build
    - test
    - deploy
    - dast
  

API 보안 테스팅을 활성화하려면 환경의 고유한 요구에 맞게 GitLab CI/CD 구성 YAML을 변경해야 합니다. 다음을 사용하여 스캔할 API를 지정할 수 있습니다:

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

결과 이해하기#

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

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

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

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

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

최적화#

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

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

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

  api_security:
    dependencies: []
  

특정 애플리케이션 또는 환경에 맞게 API 보안 테스팅을 구성하려면 전체 구성 옵션 목록을 참조하세요.

배포#

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

파이프라인이 각 실행에서 동일한 웹 서버에 배포되도록 구성된 경우 다른 파이프라인이 아직 실행 중인 동안 파이프라인을 실행하면 하나의 파이프라인이 다른 파이프라인의 코드를 덮어쓰는 경쟁 조건이 발생할 수 있습니다. 스캔할 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)을 사용하는 리뷰 앱 배포를 생성했습니다. 이 예제는 리뷰 앱 - GKE 프로젝트에서 찾을 수 있으며, README.md에 DAST용 리뷰 앱 구성에 대한 자세한 지침도 있습니다.

Docker 서비스#

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

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

작업에 services 섹션을 추가할 때 alias는 서비스에 접근하는 데 사용할 수 있는 호스트 이름을 정의하는 데 사용됩니다. 다음 예에서 dast 작업 정의의 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

대부분의 애플리케이션은 데이터베이스 또는 캐싱 서비스와 같은 여러 서비스에 의존합니다. 기본적으로 서비스 필드에 정의된 서비스는 서로 통신할 수 없습니다. 서비스 간 통신을 허용하려면 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 작업 정의.
• 전체 작업 콘솔 출력.
• gl-api-security-scanner.log라는 작업 아티팩트로 사용 가능한 스캐너 로그 파일.

용어집#

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