분석기 활성화

다음을 사용하여 스캔하려는 API를 지정할 수 있습니다.

OpenAPI 사언서

OpenAPI 사언서 (이전에는 Swagger 사언서로 알려짐)는 REST API에 대한 API 설명 형식입니다. 이 섹션은 API 보안 테스트 스캔을 구성하는 방법을 보여줍니다. OpenAPI 사언서를 사용하여 대상 API에 대한 정보를 제공하여 API 보안 테스트 스캔을 구성하는 방법을 보여줍니다. OpenAPI 사언서는 파일 시스템 리소스 또는 URL로 제공됩니다. JSON 및 YAML OpenAPI 형식이 모두 지원됩니다.

API 보안 테스트는 OpenAPI 문서를 사용하여 요청 본문을 생성합니다. 요청 본문이 필요한 경우, 본문 생성은 다음과 같은 본문 유형으로 제한됩니다.

  • application/x-www-form-urlencoded
  • multipart/form-data
  • application/json
  • application/xml

OpenAPI 및 미디어 유형

미디어 유형(이전에는 MIME 유형으로 알려짐)은 파일 형식 및 포맷 내용에 대한 식별자입니다. OpenAPI 문서를 사용하면 특정 작업이 다른 미디어 유형을 수락할 수 있도록 지정할 수 있으므로 특정 요청은 서로 다른 파일 콘텐츠를 사용하여 데이터를 보낼 수 있습니다. 예를 들어 사용자 데이터를 업데이트하는 PUT /user 작업은 XML(미디어 유형 application/xml) 또는 JSON(미디어 유형 application/json) 형식의 데이터를 수락할 수 있습니다. OpenAPI 2.x에서는 전역적으로 또는 작업별로 수락된 미디어 유형을 지정할 수 있으며, OpenAPI 3.x에서는 작업별로 수락된 미디어 유형을 지정할 수 있습니다. API 보안 테스트에서는 나열된 미디어 유형을 확인하고 각 지원되는 미디어 유형에 대해 샘플 데이터를 생성하려고 시도합니다.

  • 기본 동작은 지원되는 미디어 유형 중 하나를 선택하는 것입니다. 지원되는 첫 번째 미디어 유형이 디렉터리에서 선택됩니다. 이 동작은 구성 가능합니다.

동일한 작업(POST /user와 같은)을 다른 미디어 유형(application/json 및 application/xml과 같은)을 사용하여 테스트하는 것은 항상 바람직하지는 않습니다. 예를 들어 대상 애플리케이션이 요청 콘텐츠 유형에 관계없이 동일한 코드를 실행하는 경우, 테스트 세션을 완료하는 데 더 오래 걸리며 대상 애플리케이션에 따라 요청 본문과 연결된 중복된 취약점을 보고할 수 있습니다.

환경 변수 DAST_API_OPENAPI_ALL_MEDIA_TYPES을 사용하면 지원되는 모든 미디어 유형을 한 번에 하나가 아닌 모두 사용할지 여부를 지정할 수 있습니다. 환경 변수 DAST_API_OPENAPI_ALL_MEDIA_TYPES이 특정 값으로 설정된 경우, API 보안 테스트에서는 한 번에 하나가 아닌 모든 지원되는 미디어 유형에 대해 요청을 생성하려고 시도합니다. 이는 각 제공된 미디어 유형마다 테스트가 반복되기 때문에 테스트하는 데 더 오래 걸립니다.

대조적으로 변수 DAST_API_OPENAPI_MEDIA_TYPES은 각각 테스트된 미디어 유형의 디렉터리을 제공하는 데 사용됩니다. 하나 이상의 미디어 유형을 제공하면 각 미디어 유형에 대해 테스트가 수행되기 때문에 테스트에 시간이 더 오래 걸립니다. 환경 변수 DAST_API_OPENAPI_MEDIA_TYPES가 미디어 유형 디렉터리으로 설정된 경우, 요청 생성 시 해당 미디어 유형만 포함되며 지원되지 않는 미디어 유형은 항상 건너뜁니다. 미디어 유형 텍스트는 다양한 섹션을 포함할 수 있습니다. 예를 들어 application/vnd.api+json; charset=UTF-8는 type "/" [tree "."] subtype ["+" suffix]* [";" parameter]의 조합입니다. 필터링 미디어 유형을 수행할 때 매개변수는 고려되지 않습니다.

환경 변수 DAST_API_OPENAPI_ALL_MEDIA_TYPES과 DAST_API_OPENAPI_MEDIA_TYPES은 미디어 유형을 처리하는 방법을 결정하도록 허용합니다. 이러한 설정은 상호 배타적입니다. 둘 다 활성화된 경우, API 보안 테스트에서 오류를 보고합니다.

OpenAPI 사언서를 사용하여 API 보안 테스트 구성

다음을 수행하여 OpenAPI 사언서를 사용하여 API 보안 테스트 스캔을 구성합니다.

  1. .gitlab-ci.yml 파일에 DAST-API.gitlab-ci.yml 템플릿을 포함합니다.

  2. 여러 테스트 프로파일이 정의된 구성 파일에는 다양한 체크가 활성화된 여러 테스트 프로파일이 정의되어 있습니다. Quick 프로필로 시작하는 것을 권장합니다. 이 프로필로 테스트하면 구성 유효성을 더 쉽게 검증할 수 있도록 테스트가 빨리 완료됩니다. .gitlab-ci.yml 파일에 DAST_API_PROFILE CI/CD 변수를 추가하여 프로필을 제공합니다.

  3. OpenAPI 사언서의 위치를 파일이나 URL로 제공해야 합니다. DAST_API_OPENAPI 변수를 추가하여 위치를 지정합니다.

  4. 대상 API 인스턴스의 기본 URL도 필요합니다. DAST_API_TARGET_URL 변수 또는 environment_url.txt 파일을 사용하여 제공합니다.

    프로젝트 루트의 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 좋습니다. GitLab CI/CD 도중 동적으로 생성된 앱을 대상으로 API 보안 테스트를 실행하려면 앱이 environment_url.txt 파일에 URL을 유지하도록 설정합니다. API 보안 테스트는 해당 파일을 구문 분석하여 스캔 대상을 찾습니다. 이에 대한 예시를 Auto DevOps CI YAML에서 볼 수 있습니다.

OpenAPI 사언서를 사용한 API 보안 테스트의 완전한 구성 예시: 

stages:
  - dast

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

variables:
  DAST_API_PROFILE: Quick
  DAST_API_OPENAPI: test-api-specification.json
  DAST_API_TARGET_URL: http://test-deployment/

이는 API 보안 테스트의 최소 구성입니다. 여기서부터 다음을 수행할 수 있습니다.

HTTP 아카이브 (HAR)

HTTP 아카이브 형식 (HAR)은 HTTP 트랜잭션을 기록하는 아카이브 파일 형식입니다. GitLab API 보안 테스트 스캐너와 함께 사용할 때 HAR 파일에는 테스트할 웹 API를 호출하는 레코드가 포함되어 있어야 합니다. API 보안 테스트 스캐너는 모든 요청을 추출하여 테스트하는 데 사용합니다.

다양한 도구를 사용하여 HAR 파일을 생성할 수 있습니다.

caution
HAR 파일에는 인증 토큰, API 키, 세션 쿠키와 같은 민감한 정보가 포함될 수 있습니다. 리포지터리에 추가하기 전에 HAR 파일 내용을 검토하는 것을 권장합니다.

HAR 파일을 사용한 API 보안 테스트 스캔

테스트할 대상 API에 대한 정보를 제공하는 HAR 파일을 사용하여 API 보안 테스트를 구성하려면 다음을 수행합니다.

  1. .gitlab-ci.yml 파일에 DAST-API.gitlab-ci.yml 템플릿을 포함합니다.

  2. 구성 파일에는 다양한 체크가 활성화된 여러 테스트 프로파일이 정의되어 있습니다. Quick 프로필로 시작하는 것을 권장합니다. 이 프로필로 테스트하면 구성 유효성을 더 쉽게 검증할 수 있도록 테스트가 빨리 완료됩니다.

    .gitlab-ci.yml 파일에 DAST_API_PROFILE CI/CD 변수를 추가하여 프로필을 제공합니다.

  3. HAR 파일의 위치를 제공해야 합니다. 파일 경로나 URL로 위치를 지정할 수 있습니다. DAST_API_HAR 변수를 추가하여 위치를 지정합니다.

  4. 대상 API 인스턴스의 기본 URL도 필요합니다. DAST_API_TARGET_URL 변수 또는 environment_url.txt 파일을 사용하여 제공합니다.

    프로젝트 루트의 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 좋습니다. GitLab CI/CD 도중 동적으로 생성된 앱을 대상으로 API 보안 테스트를 실행하려면 앱이 environment_url.txt 파일에 URL을 유지하도록 설정합니다. API 보안 테스트는 해당 파일을 구문 분석하여 스캔 대상을 찾습니다. 이에 대한 예시를 Auto DevOps CI YAML에서 볼 수 있습니다.

HAR 파일을 사용하는 API 보안 테스트의 완전한 구성 예시: 

stages:
  - dast

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

variables:
  DAST_API_PROFILE: Quick
  DAST_API_HAR: test-api-recording.har
  DAST_API_TARGET_URL: http://test-deployment/

이 예제는 API 보안 테스트의 최소 구성입니다. 여기서부터 다음을 수행할 수 있습니다.

GraphQL 스키마

GraphQL은 API용 쿼리 언어로, REST API의 대안입니다. API 보안 테스트는 다음과 같은 다양한 방법으로 GraphQL 엔드포인트를 테스트할 수 있습니다.

  • GraphQL 스키마를 사용하여 테스트합니다. GitLab 15.4에서 소개되었습니다.
  • GraphQL 쿼리의 녹화(HAR)를 사용하여 테스트합니다.
  • GraphQL 쿼리를 포함한 Postman Collection을 사용하여 테스트합니다.

이 섹션에서는 GraphQL 스키마를 사용하여 테스트하는 방법에 대해 문서화합니다. API 보안 테스트의 GraphQL 스키마 지원은 내체(Introspection)을 지원하는 엔드포인트에서 스키마를 쿼리할 수 있습니다. 내체는 GraphiQL과 같은 도구가 작동하도록 기본적으로 활성화되어 있습니다. 내체를 활성화하는 방법에 대한 자세한 내용은 GraphQL 프레임워크 문서를 참조하십시오.

GraphQL 엔드포인트 URL로 API 보안 테스트 스캔

API 보안 테스트의 GraphQL 지원은 스키마를 위해 GraphQL 엔드포인트에 쿼리할 수 있습니다.

note
이 방법을 올바르게 작동하려면 GraphQL 엔드포인트가 내체 쿼리를 지원해야 합니다.

API 보안 테스트를 구성하여 테스트할 대상 API에 대한 정보를 제공하는 GraphQL 엔드포인트 URL을 사용하도록 구성하려면 다음을 수행하십시오.

  1. .gitlab-ci.yml 파일에 DAST-API.gitlab-ci.yml 템플릿을 포함시킵니다.

  2. GraphQL 엔드포인트의 경로(예: /api/graphql)를 제공합니다. DAST_API_GRAPHQL 변수를 추가하여 위치를 지정하십시오.

  3. 대상 API 인스턴스의 기본 URL도 필요합니다. DAST_API_TARGET_URL 변수 또는 environment_url.txt 파일을 사용하여 제공하십시오.

    프로젝트 루트에 URL을 environment_url.txt 파일에 추가하여 동적 환경에서 테스트하는 것이 좋습니다. 자세한 정보는 문서의 동적 환경 솔루션 섹션을 참조하십시오.

GraphQL 엔드포인트 경로를 사용하는 구성의 완전한 예시: 

stages:
  - dast

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

dast_api:
  variables:
    DAST_API_GRAPHQL: /api/graphql
    DAST_API_TARGET_URL: http://test-deployment/

이 예시는 API 보안 테스트의 최소 구성입니다. 여기서 다음을 수행할 수 있습니다.

GraphQL 스키마 파일로 API 보안 테스트 스캔

API 보안 테스트는 내체를 비활성화한 GraphQL 엔드포인트를 이해하고 테스트하는 데 GraphQL 스키마 파일을 사용할 수 있습니다. GraphQL 스키마 파일을 사용하려면 내체 JSON 형식으로 변환되어야 합니다. GraphQL 스키마는 온라인 3rd party 도구를 사용하여 내체 JSON 형식으로 변환될 수 있습니다.

API 보안 테스트를 구성하여 대상 API에 대한 정보를 제공하는 GraphQL 스키마 파일을 사용하도록 구성하려면 다음을 수행하십시오.

  1. .gitlab-ci.yml 파일에 DAST-API.gitlab-ci.yml 템플릿을 포함시킵니다.

  2. GraphQL 엔드포인트의 경로(예: /api/graphql)를 제공합니다. DAST_API_GRAPHQL 변수를 추가하여 위치를 지정하십시오.

  3. GraphQL 스키마 파일의 위치를 제공해야 합니다. 파일 경로 또는 URL로 위치를 지정할 수 있습니다. DAST_API_GRAPHQL_SCHEMA 변수를 추가하여 위치를 지정하십시오.

  4. 대상 API 인스턴스의 기본 URL도 필요합니다. DAST_API_TARGET_URL 변수 또는 environment_url.txt 파일을 사용하여 제공하십시오.

    프로젝트 루트에 URL을 environment_url.txt 파일에 추가하여 동적 환경에서 테스트하는 것이 좋습니다. 자세한 정보는 문서의 동적 환경 솔루션 섹션을 참조하십시오.

GraphQL 스키마 파일을 사용하는 구성의 완전한 예시: 

stages:
  - dast

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

dast_api:
  variables:
    DAST_API_GRAPHQL: /api/graphql
    DAST_API_GRAPHQL_SCHEMA: test-api-graphql.schema
    DAST_API_TARGET_URL: http://test-deployment/

GraphQL 스키마 파일 URL을 사용하는 구성의 완전한 예시: 

stages:
  - dast

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

dast_api:
  variables:
    DAST_API_GRAPHQL: /api/graphql
    DAST_API_GRAPHQL_SCHEMA: http://file-store/files/test-api-graphql.schema
    DAST_API_TARGET_URL: http://test-deployment/

이 예시는 API 보안 테스트의 최소 구성입니다. 여기서 다음을 수행할 수 있습니다.

Postman Collection

Postman API Client는 여러 종류의 API를 호출하는 데 사용하는 인기있는 도구입니다. API 정의는 Postman Collection 파일로 내보낼 수 있습니다. GitLab API 보안 테스트 스캐너와 함께 사용할 때, Postman Collection은 유효한 데이터로 API 보안 테스트를 수행하기 위해 모든 API 정의를 추출합니다.

caution
Postman Collection 파일에는 인증 토큰, API 키, 세션 쿠키와 같은 민감한 정보가 포함될 수 있습니다. 리포지터리에 추가하기 전에 Postman Collection 파일의 내용을 검토하는 것을 권장합니다.

Postman Collection 파일로 API 보안 테스트 스캔

API 보안 테스트를 구성하여 대상 API에 대한 정보를 제공하는 Postman Collection 파일을 사용하도록 구성하려면 다음을 수행하십시오.

  1. .gitlab-ci.yml 파일에 DAST-API.gitlab-ci.yml 템플릿을 포함시킵니다.

  2. 구성 파일에 여러 가지 테스팅 프로필이 정의되어 특정 체크가 활성화된다. Quick 프로필로 시작하는 것을 권장합니다. 이 프로필로 테스트하면 더 빠르게 완료되어 구성을 쉽게 검증할 수 있습니다.

    .gitlab-ci.yml 파일에 DAST_API_PROFILE CI/CD 변수를 추가하여 프로필을 제공하십시오.

  3. Postman Collection 파일의 위치를 파일 경로 또는 URL로 제공합니다. DAST_API_POSTMAN_COLLECTION 변수를 추가하여 위치를 지정하십시오.

  4. 대상 API 인스턴스의 기본 URL도 필요합니다. DAST_API_TARGET_URL 변수 또는 environment_url.txt 파일을 사용하여 제공하십시오.

    프로젝트 루트에 URL을 environment_url.txt 파일에 추가하여 동적 환경에서 테스트하는 것이 좋습니다. GitLab CI/CD 중에 동적으로 생성된 응용 프로그램에서 API 보안 테스트를 실행하려면 응용 프로그램이 URL을 environment_url.txt 파일에 유지하도록 하십시오. API 보안 테스트는 자동으로 해당 파일을 구문 분석하여 스캔 대상을 찾습니다. 아래의 Auto DevOps CI YAML 예시에서 예시를 볼 수 있습니다.

Postman collection을 사용하는 구성의 완전한 예시: 

stages:
  - dast

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

variables:
  DAST_API_PROFILE: Quick
  DAST_API_POSTMAN_COLLECTION: postman-collection_serviceA.json
  DAST_API_TARGET_URL: http://test-deployment/

이는 API 보안 테스트의 최소 구성입니다. 여기서 다음을 수행할 수 있습니다.

Postman 변수

  • GitLab 15.1에서 Postman 환경 파일 형식 지원이 도입되었습니다.
  • GitLab 15.1에서 다중 변수 파일 지원이 도입되었습니다.
  • GitLab 15.1에서 Postman 변수 스코프(글로벌 및 환경) 지원이 도입되었습니다.

Postman 클라이언트의 변수

Postman은 개발자가 요청의 다양한 부분에서 사용할 수 있는 자리 표시자를 정의할 수 있게 합니다. 이러한 자리 표시자를 변수라고 하며, 변수 사용에서 설명된 대로 요청 및 스크립트에서 값 저장 및 재사용을 할 수 있습니다. 예를 들어, 컬렉션을 편집하여 문서에 변수를 추가할 수 있습니다:

컬렉션 변수 탭 보기 편집

또는 환경에서 변수를 추가할 수도 있습니다:

환경 변수 보기 편집

그런 다음 URL, 헤더 등의 섹션에서 변수를 사용할 수 있습니다:

변수 사용하여 요청 편집 보기

Postman은 멋진 UX 경험을 가진 기본 클라이언트 도구에서 스크립트를 사용하여 API를 테스트하고 보조 요청을 트리거하는 복잡한 컬렉션을 만들 수 있는 더 복잡한 생태계로 성장했습니다. Postman 생태계의 모든 기능이 지원되는 것은 아닙니다. 예를 들어, 스크립트는 지원되지 않습니다. Postman 지원의 주요 초점은 Postman 클라이언트에서 사용되는 Postman Collection 정의 및 해당 관련 변수에 있습니다.

Postman에서 변수를 다양한 범위에 생성할 수 있습니다. 각 범위는 Postman 도구에서 다른 수준의 가시성을 가집니다. 예를 들어, 사용자가 Postman 클라이언트에서 생성한 글로벌 환경 범위의 변수를 생성할 수 있으며, 이 변수는 모든 작업 정의와 워크스페이스에서 볼 수 있습니다. 또한 사용자가 특정 환경 범위에서 생성한 변수도 생성할 수 있으며, 해당 환경이 사용되도록 선택된 경우에만 사용할 수 있습니다. 일부 범위는 항상 사용할 수 있는 것은 아닙니다. 예를 들어, Postman 생태계에서 Postman 클라이언트에서 요청을 생성할 수 있지만, 이러한 요청에는 로컬 범위가 없습니다. 그러나 테스트 스크립트에는 있습니다.

Postman의 변수 범위는 이해하기 어려운 주제일 수 있으며 모두가 익숙하지는 않을 수 있습니다. 전진하기 전에 Postman 문서의 변수 범위를 꼭 읽으시기를 강력히 권장합니다.

위에서 언급했듯이, 각각의 변수 범위가 있고 Postman 문서에서 설명되어 있습니다. 변수 값이 어떻게 계산되는지에 대한 중요한 참고 사항이 있습니다.

동일한 이름을 가진 변수를 두 개의 다른 범위에서 선언할 경우, 가장 좁은 범위의 변수에 저장된 값이 사용됩니다. 예를 들어, 글로벌 변수의 이름이 username이고 로컬 변수의 이름이 username인 경우 요청 실행 시 로컬 값이 사용됩니다.

다음은 Postman 클라이언트와 API 보안 테스트에서 지원되는 변수 범위의 요약입니다.

  • 글로벌 환경 (글로벌) 범위는 워크스페이스 전체에서 사용할 수 있는 특별하게 정의된 환경입니다. 글로벌 환경 범위를 글로벌 범위로도 참조할 수 있습니다. Postman 클라이언트는 글로벌 환경을 JSON 파일로 내보낼 수 있으며, 이는 API 보안 테스트에 사용될 수 있습니다.
  • 환경 범위는 사용자가 Postman 클라이언트에서 생성한 변수의 이름 그룹입니다. Postman 클라이언트는 단일 활성 환경과 글로벌 환경을 지원합니다. 사용자가 생성한 활성 환경에 정의된 변수는 글로벌 환경에 정의된 변수보다 우선합니다. Postman 클라이언트는 선택한 환경의 변수를 JSON 파일로 내보낼 수 있으며, 이는 API 보안 테스트에 사용될 수 있습니다.
  • 컬렉션 범위은 특정 컬렉션에 선언된 변수 그룹입니다. 컬렉션 변수는 정의된 컬렉션 및 중첩된 요청 또는 컬렉션에서 사용할 수 있습니다. 컬렉션 범위에 정의된 변수는 글로벌 환경 범위 및 환경 범위보다 우선합니다. Postman 클라이언트는 하나 이상의 컬렉션을 JSON 파일로 내보낼 수 있으며, 선택된 컬렉션, 요청 및 컬렉션 변수를 포함한 이 JSON 파일을 내장하고 있습니다.
  • API 보안 테스트 범위는 API 보안 테스트에서 추가 변수를 제공하거나 지원되는 다른 범위에 정의된 변수를 무시하는 것을 허용하는 새로운 범위입니다. 이 범위는 Postman에서 지원되지 않습니다. API 보안 테스트 범위 변수는 사용자 정의 JSON 파일 형식을 사용하여 제공됩니다.
    • 환경 또는 컬렉션에서 정의된 변수 무시
    • 스크립트에서 변수 정의
    • 지원되지 않는 _데이터 범위_에서 하나의 데이터 행 정의
  • 데이터 범위는 이름 및 값이 JSON 또는 CSV 파일에서 가져오는 변수 그룹입니다. Postman 컬렉션 러너(예: Newman 또는 Postman Collection Runner)가 JSON 또는 CSV 파일 항목 수만큼 요청을 실행합니다. 이러한 변수의 좋은 사용 사례는 Postman에서 스크립트를 사용하여 테스트를 자동화하는 것입니다. API 보안 테스트는 CSV 또는 JSON 파일에서 데이터를 읽는 것을 지원하지 않습니다.
  • 로컬 범위는 Postman 스크립트에서 정의된 변수입니다. API 보안 테스트는 Postman 스크립트 및 해당 변수가 정의된 범위를 지원하지 않습니다. 그럼에도 불구하고, 지원되는 범위 중 하나에 정의하여 스크립트에서 정의된 변수에 대한 값 제공할 수 있습니다.

모든 범위가 API 보안 테스트에서 지원되는 것은 아니며, 스크립트에서 정의된 변수도 지원되지 않습니다. 다음 표는 가장 넓은 범위부터 가장 좁은 범위까지 정렬됩니다.

범위 Postman API 보안 테스트 설명
글로벌 환경 예 예 특별하게 정의된 환경
환경 예 예 이름 있는 환경
컬렉션 예 예 Postman 컬렉션에 정의됨
API 보안 테스트 범위 아니요 예 API 보안 테스트에서 추가된 사용자 정의 범위
데이터 예 아니요 CSV 또는 JSON 형식의 외부 파일
로컬 예 아니요 스크립트에서 정의된 변수

다양한 범위에서 변수를 정의하고 내보내는 방법에 대한 자세한 내용은 다음을 참조하세요:

Postman 클라이언트에서 내보내기

Postman 클라이언트를 통해 여러 파일 형식을 내보낼 수 있으며, 예를 들어 Postman 컬렉션이나 Postman 환경을 내보낼 수 있습니다. 내보낸 환경은 항상 사용 가능한 글로벌 환경이 될 수도 있고, 이전에 만든 사용자 정의 환경이 될 수도 있습니다. Postman 컬렉션을 내보낼 때, 컬렉션 및 로컬 범위 변수의 선언만 포함될 수 있으며, 환경 범위 변수는 포함되지 않습니다.

내보낸 파일에서 환경 범위 변수의 선언을 얻으려면 그 시점에서 특정 환경을 내보내야 합니다. 각 내보낸 파일에는 선택한 환경의 변수만 포함됩니다.

서로 다른 지원되는 범위에서 변수를 내보내는 방법에 대한 자세한 내용은 다음을 참조하세요: 

#### API 보안 테스트 범위, 사용자 정의 JSON 파일 형식

우리의 사용자 정의 JSON 파일 형식은 각 객체 속성이 변수 이름을 나타내고, 속성 값이 변수 값을 나타내는 JSON 객체입니다. 이 파일은 즐겨 사용하는 텍스트 편집기를 사용하여 생성할 수도 있고, 파이프라인 내의 이전 작업에서 생성될 수도 있습니다.

다음 예시는 API 보안 테스트 범위에서 `base_url`과 `token` 두 변수를 정의합니다:

```json
{
  "base_url": "http://127.0.0.1/",
  "token": "Token 84816165151"
}

API 보안 테스트에서 범위 사용하기

scopes: global, environment, collection, GitLab API security testing_은 GitLab 15.1 및 이후 버전에서 지원됩니다. 그동안, GitLab 15.0 및 그 이전 버전에서는 _collection 및 GitLab API security testing 범위만 지원됩니다.

다음 표는 API 보안 테스트 구성 변수에 대한 범위 파일/URL 매핑에 대한 빠른 참조를 제공합니다:

범위 제공 방법
전역 환경 DAST_API_POSTMAN_COLLECTION_VARIABLES
환경 DAST_API_POSTMAN_COLLECTION_VARIABLES
컬렉션 DAST_API_POSTMAN_COLLECTION
API 보안 테스트 범위 DAST_API_POSTMAN_COLLECTION_VARIABLES
데이터 지원되지 않음
로컬 지원되지 않음

Postman Collection 문서는 자동적으로 어떠한 collection 범위 변수도 포함합니다. Postman Collection은 구성 변수 DAST_API_POSTMAN_COLLECTION와 함께 제공됩니다. 이 변수는 단일 내보낸 Postman 컬렉션으로 설정할 수 있습니다.

다른 범위에서의 변수는 구성 변수 DAST_API_POSTMAN_COLLECTION_VARIABLES를 통해 제공됩니다. GitLab 15.1 및 이후 버전에서는 구성 변수가 쉼표로 구분된 파일 디렉터리을 지원하며, GitLab 15.0 및 그 이전 버전에서는 단일 파일만 지원됩니다. 제공된 파일의 순서는 필요한 범위 정보를 제공하기 때문에 중요하지 않습니다.

구성 변수 DAST_API_POSTMAN_COLLECTION_VARIABLES은 다음과 같이 설정할 수 있습니다:

정의되지 않은 Postman 변수

API 보안 테스트 엔진이 Postman 컬렉션 파일이 사용하는 모든 변수 참조를 찾지 못할 수도 있습니다. 일부 사례로는 다음과 같습니다:

  • 데이터 또는 로컬 범위 변수를 사용하고 있는데, 이러한 범위가 API 보안 테스트에서는 지원되지 않습니다. 따라서, 이러한 변수의 값이 API 보안 테스트 범위를 통해 제공되지 않은 경우, 데이터 및 로컬 범위 변수의 값은 정의되지 않은 상태입니다.
  • 변수 이름이 잘못 입력되었고, 해당 이름이 정의된 변수와 일치하지 않습니다.
  • Postman 클라이언트가 API 보안 테스트에서 지원하지 않는 새로운 동적 변수를 지원합니다.

가능한 경우, API 보안 테스트는 지원되지 않는 변수를 다루는 데 있어 Postman 클라이언트와 동일한 동작을 따릅니다. 변수 참조의 텍스트는 그대로 유지되며, 텍스트가 대체되지 않습니다. 이러한 동작은 지원되지 않는 동적 변수에도 적용됩니다.

예를 들어, Postman Collection의 요청 정의가 변수 {{full_url}}을 참조하고 있고, 해당 변수를 찾지 못한 경우 변수는 {{full_url}} 값으로 유지됩니다.

동적 Postman 변수

여러 범위 수준에서 사용자가 정의할 수 있는 변수 외에, Postman에는 동적 변수라고 불리는 미리 정의된 변수 세트가 있습니다. 동적 변수는 이미 정의되어 있으며, 해당 이름은 달러 기호($)로 접두사가 붙습니다. 예를 들어, $guid와 같은 형태입니다. 동적 변수는 다른 변수와 마찬가지로 사용할 수 있으며, Postman 클라이언트에서는 요청/컬렉션 실행 중에 해당 동적 변수에 대해 무작위 값을 생성합니다.

API 보안 테스트와 Postman 간의 중요한 차이점은 API 보안 테스트가 동일한 동적 변수 사용 시에는 동일한 값을 반환한다는 점입니다. 이는 Postman 클라이언트가 동일한 동적 변수 사용 시에는 각각 다른 무작위 값을 반환하는 것과는 다릅니다. 다시 말해, API 보안 테스트는 동적 변수에 대해 정적 값을 사용하며, Postman은 각 사용 시에 무작위 값을 반환합니다.

스캔 과정 중 지원되는 동적 변수는 다음과 같습니다:

| 변수 | 값 | | ———– | ———– | | $guid | 611c2e81-2ccb-42d8-9ddc-2d0bfa65c1b4 | | $isoTimestamp | 2020-06-09T21:10:36.177Z | | … ```

(계속됨)

예시: 전역 범위

이 예시에서는 Postman 클라이언트에서 전역 범위를 global-scope.json으로 내보내고, DAST_API_POSTMAN_COLLECTION_VARIABLES 구성 변수를 통해 API 보안 테스트에 제공됩니다.

DAST_API_POSTMAN_COLLECTION_VARIABLES 사용 예시: 

stages:
  - dast

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

variables:
  DAST_API_PROFILE: Quick
  DAST_API_POSTMAN_COLLECTION: postman-collection.json
  DAST_API_POSTMAN_COLLECTION_VARIABLES: global-scope.json
  DAST_API_TARGET_URL: http://test-deployment/

예시: 환경 범위

이 예시에서는 Postman 클라이언트에서 환경 범위를 environment-scope.json으로 내보내고, DAST_API_POSTMAN_COLLECTION_VARIABLES 구성 변수를 통해 API 보안 테스트에 제공됩니다.

DAST_API_POSTMAN_COLLECTION_VARIABLES 사용 예시: 

stages:
  - dast

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

variables:
  DAST_API_PROFILE: Quick
  DAST_API_POSTMAN_COLLECTION: postman-collection.json
  DAST_API_POSTMAN_COLLECTION_VARIABLES: environment-scope.json
  DAST_API_TARGET_URL: http://test-deployment/

예시: 컬렉션 범위

컬렉션 범위 변수는 내보낸 Postman 컬렉션 파일에 포함되며 DAST_API_POSTMAN_COLLECTION 구성 변수를 통해 제공됩니다.

DAST_API_POSTMAN_COLLECTION 사용 예시: 

stages:
  - dast

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

variables:
  DAST_API_PROFILE: Quick
  DAST_API_POSTMAN_COLLECTION: postman-collection.json
  DAST_API_TARGET_URL: http://test-deployment/

예시: API 보안 테스트 범위

API 보안 테스트 범위는 두 가지 주요 목적으로 사용됩니다. API 보안 테스트에서 지원되지 않는 데이터 및 로컬 범위 변수를 정의하고, 다른 범위에서 정의된 기존 변수의 값을 변경하기 위함입니다. API 보안 테스트 범위는 DAST_API_POSTMAN_COLLECTION_VARIABLES 구성 변수를 통해 제공됩니다.

DAST_API_POSTMAN_COLLECTION_VARIABLES 사용 예시: 

stages:
  - dast

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

variables:
  DAST_API_PROFILE: Quick
  DAST_API_POSTMAN_COLLECTION: postman-collection.json
  DAST_API_POSTMAN_COLLECTION_VARIABLES: dast-api-scope.json
  DAST_API_TARGET_URL: http://test-deployment/

파일 dast-api-scope.json은 사용자 정의 JSON 파일 형식을 사용합니다. 이 JSON은 속성에 대한 키-값 쌍으로 이루어진 객체입니다. 키는 변수의 이름이며, 값은 변수의 값입니다.

예시: 다중 범위

이 예시에서는 전역 범위, 환경 범위 및 컬렉션 범위가 구성됩니다. 첫 번째 단계는 각 범위를 내보내는 것입니다.

Postman 컬렉션은 DAST_API_POSTMAN_COLLECTION 변수를 사용하여 제공되며, 다른 범위는 DAST_API_POSTMAN_COLLECTION_VARIABLES를 사용하여 제공됩니다. API 보안 테스트는 각 파일에서 제공된 데이터를 사용하여 제공된 파일이 일치하는 범위를 식별할 수 있습니다. 

stages:
  - dast

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

variables:
  DAST_API_PROFILE: Quick
  DAST_API_POSTMAN_COLLECTION: postman-collection.json
  DAST_API_POSTMAN_COLLECTION_VARIABLES: global-scope.json,environment-scope.json
  DAST_API_TARGET_URL: http://test-deployment/

예시: 변수 값 변경

내보낸 범위를 사용할 때 종종 변수의 값을 API 보안 테스트에 사용할 값으로 변경해야 하는 경우가 많습니다. 예를 들어, 컬렉션 범위 변수에 api_version이라는 변수가 v2의 값을 가지고 있을 수 있고, 테스트에는 v1의 값이 필요할 수 있습니다. 내보낸 컬렉션을 수정하여 값을 변경하는 대신, API 보안 테스트 범위를 사용하여 값을 변경할 수 있습니다. 이는 API 보안 테스트 범위가 다른 모든 범위보다 우선순위를 가지기 때문에 작동합니다.

컬렉션 범위 변수는 내보낸 Postman 컬렉션 파일에 포함되며 DAST_API_POSTMAN_COLLECTION 구성 변수를 통해 제공됩니다.

API 보안 테스트 범위는 DAST_API_POSTMAN_COLLECTION_VARIABLES 구성 변수를 통해 제공되지만 먼저 파일을 생성해야 합니다. 파일 dast-api-scope.json은 사용자 정의 JSON 파일 형식을 사용합니다. 이 JSON은 속성에 대한 키-값 쌍으로 이루어진 객체입니다. 키는 변수의 이름이며, 값은 변수의 값입니다.

우리의 CI 정의: 

stages:
  - dast

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

variables:
  DAST_API_PROFILE: Quick
  DAST_API_POSTMAN_COLLECTION: postman-collection.json
  DAST_API_POSTMAN_COLLECTION_VARIABLES: dast-api-scope.json
  DAST_API_TARGET_URL: http://test-deployment/

예시: 다중 범위로 변수 값 변경

내보낸 범위를 사용할 때 종종 변수의 값을 API 보안 테스트에 사용할 값으로 변경해야 하는 경우가 많습니다. 예를 들어, 환경 범위에 api_version이라는 변수가 v2의 값을 가지고 있을 수 있고, 테스트에는 v1의 값이 필요할 수 있습니다. 내보낸 파일을 수정하여 값을 변경하는 대신, API 보안 테스트 범위를 사용할 수 있습니다. 이는 API 보안 테스트 범위가 다른 모든 범위보다 우선순위를 가지기 때문에 작동합니다.

이 예시에서는 전역 범위, 환경 범위, 컬렉션 범위 및 API 보안 테스트 범위가 구성됩니다. 첫 번째 단계는 각 범위를 내보내고 생성하는 것입니다.

API 보안 테스트 범위는 dast-api-scope.json이라는 파일을 생성하여 사용합니다. 이 JSON은 속성에 대한 키-값 쌍으로 이루어진 객체입니다. 키는 변수의 이름이며, 값은 변수의 값입니다.

Postman 컬렉션은 DAST_API_POSTMAN_COLLECTION 변수를 사용하여 제공되며, 다른 범위는 DAST_API_POSTMAN_COLLECTION_VARIABLES를 사용하여 제공됩니다. API 보안 테스트는 각 파일에서 제공된 데이터를 사용하여 제공된 파일이 일치하는 범위를 식별할 수 있습니다. 

stages:
  - dast

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

variables:
  DAST_API_PROFILE: Quick
  DAST_API_POSTMAN_COLLECTION: postman-collection.json
  DAST_API_POSTMAN_COLLECTION_VARIABLES: global-scope.json,environment-scope.json,dast-api-scope.json
  DAST_API_TARGET_URL: http://test-deployment/

첫 번째 스캔 실행하기

올바르게 구성된 CI/CD 파이프라인은 dast 단계와 dast_api 작업을 포함합니다. 이 작업은 잘못된 구성이 제공될 때에만 실패합니다. 전형적인 작업 시, 취약점이 식별되더라도 항상 성공합니다.

보안 취약점은 보안 파이프라인 탭에 스위트 이름과 함께 표시됩니다. 리포지터리의 기본 브랜치에 대해 테스트를 수행할 때 API 보안 테스트 취약점은 보안 및 규정 준수의 취약점 보고서 페이지에도 표시됩니다.

보고된 취약점 수를 줄이기 위해 API 보안 테스트 스캐너는 운영 당 담당하는 취약점 수를 제한합니다.

API 보안 테스트 취약점 보기

API 보안 테스트 분석기는 JSON 보고서를 생성하여 GitLab 취약점 화면에 취약점을 채우는 데 사용됩니다. API 보안 테스트 취약점 세부 정보 보기에 대한 자세한 내용은 여기를 참조하세요.

거짓 긍정 처리에 대한 자세한 내용은 거짓 긍정 처리를 참조하여 한계된 거짓 긍정의 수를 제한할 수 있는 구성 변경에 대해 알아보세요.

API 보안 테스트 취약점 세부 정보 보기

취약점 세부 정보를 보려면 다음 단계를 따르세요:

  1. 프로젝트 또는 Merge Request에서 취약점을 볼 수 있습니다:

    • 프로젝트의 보안 > 취약점 보고서 페이지로 이동합니다. 이 페이지에는 기본 브랜치의 모든 취약점이 표시됩니다.
    • Merge Request에서 Merge Request의 보안 섹션으로 이동한 후 확장 버튼을 선택합니다. API 보안 테스트 취약점은 DAST detected N potential vulnerabilities로 표시된 섹션에서 사용할 수 있습니다. 취약점 세부 정보를 표시하려면 제목을 선택합니다.

  2. 취약점 제목을 선택하여 세부 정보를 표시합니다. 아래 표에서 이러한 세부 정보를 설명합니다.

    필드 설명
    설명 취약점에 대한 설명으로 수행된 수정 내용을 포함합니다.
    프로젝트 취약점이 감지된 네임스페이스 및 프로젝트입니다.
    메소드 취약점을 감지하는 데 사용된 HTTP 메소드입니다.
    URL 취약점이 감지된 URL입니다.
    요청 취약점을 유발시킨 HTTP 요청입니다.
    수정되지 않은 응답 수정되지 않은 요청에 대한 응답입니다. 일반적으로 작동하는 응답입니다.
    실제 응답 테스트 요청으로부터 받은 응답입니다.
    증거 취약점이 발생한 방법입니다.
    식별자 이 취약점을 찾으려면 사용된 API 보안 테스트 확인입니다.
    심각도 취약점의 심각도입니다.
    스캐너 유형 테스트 수행에 사용된 스캐너입니다.

보안 대시보드

보안 대시보드는 그룹, 프로젝트 및 파이프라인의 모든 보안 취약점에 대한 개요를 얻기에 좋은 장소입니다. 자세한 정보는 보안 대시보드 설명서를 참조하세요.

취약점 상호작용

취약점을 발견하면 상호작용할 수 있습니다. 취약점 처리 방법에 대해 자세히 알아보세요.

거짓 긍정 처리

거짓 긍정은 다양한 방법으로 처리될 수 있습니다:

  • 취약점을 해제합니다.
  • 일부 체크는 취약점이 식별될 때 여러 메서드를 사용하여 감지하는데, 이를 _단언_이라고 합니다. 단언도 비활성화되고 구성될 수 있습니다. 예를 들어, API 보안 테스트 스캐너는 기본적으로 실제 문제임을 확인하는 데 HTTP 상태 코드를 사용합니다. API가 테스트 중에 500 오류를 반환하면 취약점이 생성됩니다. 이것이 항상 원하는 것은 아니므로 몇몇 프레임워크는 500 오류를 자주 반환합니다.
  • 거짓 긍정을 생성하는 체크를 비활성화합니다. 이렇게 하면 해당 체크가 어떠한 취약점도 생성하지 못하게 됩니다. 예제 체크로는 SQL Injection Check 및 JSON Hijacking Check 등이 있습니다.

체크 비활성화

체크는 특정 유형의 테스트를 수행하고도 특정 구성 프로필에 대해 활성화 및 비활성화될 수 있습니다. 제공된 구성 파일에서는 사용할 수 있는 프로필을 정의합니다. 구성 파일의 프로필 정의는 스캔 중 활성화된 모든 체크를 나열합니다. 특정 체크를 비활성화하려면 구성 파일의 프로필 정의에서 해당 체크를 제거합니다. 프로필은 구성 파일의 Profiles 섹션에 정의됩니다.

예제 프로필 정의: 

Profiles:
  - Name: Quick
    DefaultProfile: Empty
    Routes:
      - Route: *Route0
        Checks:
          - Name: ApplicationInformationCheck
          - Name: CleartextAuthenticationCheck
          - Name: FrameworkDebugModeCheck
          - Name: HtmlInjectionCheck
          - Name: InsecureHttpMethodsCheck
          - Name: JsonHijackingCheck
          - Name: JsonInjectionCheck
          - Name: SensitiveInformationCheck
          - Name: SessionCookieCheck
          - Name: SqlInjectionCheck
          - Name: TokenCheck
          - Name: XmlInjectionCheck

JSON Hijacking Check를 비활성화하려면 이 라인들을 삭제할 수 있습니다: 

          - Name: JsonHijackingCheck

이에 따라 아래와 같은 YAML이 나타납니다: 

- Name: Quick
  DefaultProfile: Empty
  Routes:
    - Route: *Route0
      Checks:
        - Name: ApplicationInformationCheck
        - Name: CleartextAuthenticationCheck
        - Name: FrameworkDebugModeCheck
        - Name: HtmlInjectionCheck
        - Name: InsecureHttpMethodsCheck
        - Name: JsonInjectionCheck
        - Name: SensitiveInformationCheck
        - Name: SessionCookieCheck
        - Name: SqlInjectionCheck
        - Name: TokenCheck
        - Name: XmlInjectionCheck

단언 비활성화

단언은 체크에서 생성된 테스트의 취약점을 감지합니다. 많은 체크가 Log Analysis, Response Analysis 및 Status Code와 같은 여러 단언을 지원합니다. 취약점이 발견될 때 사용된 단언이 제공됩니다. 기본적으로 활성화된 어떤 단언이 있는지 확인하려면 구성 파일의 체크 기본 구성을 확인하세요. 이 섹션이 Checks로 불립니다.

다음은 SQL Injection Check의 예시입니다: 

- Name: SqlInjectionCheck
  Configuration:
    UserInjections: []
  Assertions:
    - Name: LogAnalysisAssertion
    - Name: ResponseAnalysisAssertion
    - Name: StatusCodeAssertion

여기에서 기본적으로 세 가지 단언이 사용되고 있습니다. 자주 거짓 긍정의 원인은 StatusCodeAssertion입니다. 이를 비활성화하려면 구성 파일의 Profiles 섹션에서 해당 단언의 구성을 수정하세요. 아래 예시는 StatusCodeAssertion을 사용하지 않도록 설정하고 있습니다. 이에 따라 SqlInjectionCheck가 StatusCodeAssertion을 사용하지 않게 됩니다: 

Profiles:
  - Name: Quick
    DefaultProfile: Empty
    Routes:
      - Route: *Route0
        Checks:
          - Name: ApplicationInformationCheck
          - Name: CleartextAuthenticationCheck
          - Name: FrameworkDebugModeCheck
          - Name: HtmlInjectionCheck
          - Name: InsecureHttpMethodsCheck
          - Name: JsonHijackingCheck
          - Name: JsonInjectionCheck
          - Name: SensitiveInformationCheck
          - Name: SessionCookieCheck
          - Name: SqlInjectionCheck
            Assertions:
              - Name: LogAnalysisAssertion
              - Name: ResponseAnalysisAssertion
          - Name: TokenCheck
          - Name: XmlInjectionCheck