분석기 활성화

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

OpenAPI 명세

  • OpenAPI 명세를 사용한 YAML 형식의 지원이 GitLab 14.0에 도입되었습니다.
  • 미디어 타입 application/xml 생성 지원이 GitLab 14.8에 도입되었습니다.
  • 미디어 타입을 지원하는 기능이 GitLab 14.10에 도입되었습니다.

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

DAST 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에서는 각 작업별로 수용되는 미디어 타입을 지정할 수 있습니다. DAST API는 나열된 미디어 타입을 확인하고 각 지원되는 미디어 타입에 대한 샘플 데이터를 생성하려고 시도합니다.

  • GitLab 14.10 및 이후에서는 기본 동작은 지원되는 미디어 타입 중 하나를 선택하는 것입니다. 지원되는 미디어 타입 중 첫 번째 미디어 타입이 목록에서 선택됩니다. 이 동작은 구성 가능합니다.
  • GitLab 14.9 이전에는 기본 동작은 모든 지원되는 미디어 타입을 사용하여 테스트를 수행하는 것입니다. 즉, 두 개의 미디어 타입이 목록에 표시된 경우(application/jsonapplication/xml 등), JSON을 사용하여 테스트한 다음 동일한 테스트를 XML을 사용하여 수행하는 것입니다.

동일한 작업(예: POST /user)을 서로 다른 미디어 타입(예: application/jsonapplication/xml)을 사용하여 테스트하는 것이 항상 바람직한 것은 아닙니다. 예를 들어 대상 응용 프로그램이 요청 콘텐츠 유형에 관계없이 동일한 코드를 실행하는 경우, 테스트 세션을 완료하는 데 더 오랜 시간이 걸리고 대상 앱에 따라 요청 본문과 관련된 중복된 취약점이 보고될 수 있습니다.

환경 변수 DAST_API_OPENAPI_ALL_MEDIA_TYPES을 사용하여 특정 작업에 대한 요청 생성 시 모든 지원되는 미디어 타입을 사용할지 여부를 지정할 수 있습니다. 환경 변수 DAST_API_OPENAPI_ALL_MEDIA_TYPES이 어떤 값으로 설정되면, DAST API는 특정 작업에 대한 요청을 생성할 때 하나가 아닌 모든 지원되는 미디어 타입에 대해 테스트를 수행하려고 시도합니다. 이렇게 하면 제공된 미디어 타입마다 테스트가 반복되기 때문에 테스트에 더 오랜 시간이 걸립니다.

또는 변수 DAST_API_OPENAPI_MEDIA_TYPES를 사용하여 각각 테스트될 미디어 타입의 목록을 제공합니다. 한 번에 하나 이상의 미디어 타입을 제공하면 각 미디어 타입마다 테스트가 수행되므로 테스트에 더 오랜 시간이 걸립니다. 환경 변수 DAST_API_OPENAPI_MEDIA_TYPES가 미디어 타입 목록으로 설정된 경우, 요청 생성 시 열거된 미디어 타입만 포함되고, 지원되지 않는 미디어 타입은 항상 건너뛰어집니다. 미디어 타입 텍스트에는 다양한 섹션이 들어갈 수 있습니다. 예를 들어 application/vnd.api+json; charset=UTF-8type "/" [tree "."] subtype ["+" suffix]* [";" parameter]의 복합체입니다. 요청 생성 시 미디어 타입을 필터링하는 동안 매개변수는 고려되지 않습니다.

환경 변수 DAST_API_OPENAPI_ALL_MEDIA_TYPESDAST_API_OPENAPI_MEDIA_TYPES을 사용하여 미디어 타입을 어떻게 처리할지 결정할 수 있습니다. 이러한 설정은 상호 배타적입니다. 둘 다 활성화되어 있는 경우, DAST API는 오류를 보고합니다.

오픈API 설명서로 DAST API 구성

DAST API 스캔을 오픈API 설명서로 구성하려면 다음 단계를 따르세요:

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

  2. 구성 파일에는 다양한 검사를 활성화시킨 여러 테스트 프로필이 정의되어 있습니다. Quick 프로필부터 시작하는 것을 권장합니다. 이 프로필로 테스트하면 구성 검증이 더 쉬워짐에 따라 테스트가 빨리 완료됩니다. .gitlab-ci.yml 파일에 DAST_API_PROFILE CI/CD 변수를 추가하여 프로필을 지정하세요.

  3. 오픈API 설명서의 위치를 파일 또는 URL로 제공해야 합니다. DAST_API_OPENAPI 변수를 추가하여 위치를 지정하세요.

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

    프로젝트 루트에 있는 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 좋습니다. GitLab CI/CD 파이프라인 중에 동적으로 생성된 앱에 DAST API를 실행하려는 경우, 앱은 URL을 environment_url.txt 파일에 지속적으로 저장해야 합니다. DAST API는 이 파일을 자동으로 구문 분석하여 스캔 대상을 찾습니다. 예시는 Auto DevOps CI YAML에서 확인할 수 있습니다..

오픈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/

이것은 DAST API에 대한 최소한의 구성입니다. 여기서부터 다음을 수행할 수 있습니다:

HTTP 아카이브 (HAR)

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

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

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

HAR 파일을 사용한 DAST API 스캔 구성

DAST API를 테스트할 대상 API에 대한 정보를 제공하는 HAR 파일을 사용하도록 DAST API를 구성하려면 다음 단계를 따르세요:

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

  2. 구성 파일에는 다양한 검사를 활성화시킨 여러 테스트 프로필이 정의되어 있습니다. Quick 프로필부터 시작하는 것을 권장합니다. 이 프로필로 테스트하면 구성 검증이 더 쉬워짐에 따라 테스트가 빨리 완료됩니다.

    .gitlab-ci.yml 파일에 DAST_API_PROFILE CI/CD 변수를 추가하여 프로필을 지정하세요.

  3. HAR 파일의 위치를 제공해야 합니다. 파일 경로나 URL로 위치를 제공할 수 있습니다. URL 지원 기능은 GitLab 13.10부터 도입되었습니다. DAST_API_HAR 변수를 추가하여 위치를 지정하세요.

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

    프로젝트 루트에 있는 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 좋습니다. GitLab CI/CD 파이프라인 중에 동적으로 생성된 앱에 DAST API를 실행하려는 경우, 앱은 URL을 environment_url.txt 파일에 지속적으로 저장해야 합니다. DAST API는 이 파일을 자동으로 구문 분석하여 스캔 대상을 찾습니다. 예시는 Auto DevOps CI YAML에서 확인할 수 있습니다..

HAR 파일을 사용한 구성의 완전한 예시:

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/

이 예시는 DAST API에 대한 최소한의 구성입니다. 여기서부터 다음을 수행할 수 있습니다:

GraphQL 스키마

  • GitLab 15.4에서 GraphQL 스키마 지원이 도입되었습니다.

GraphQL은 API용 쿼리 언어이자 REST API의 대안입니다. DAST API는 GraphQL 엔드포인트를 여러 가지 방법으로 테스트하는 것을 지원합니다.

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

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

GraphQL 엔드포인트 URL로 DAST API 스캔

DAST API의 GraphQL 지원을 사용하여 GraphQL 엔드포인트에서 스키마를 쿼리할 수 있습니다.

참고: 이 방법을 올바르게 작동하려면 GraphQL 엔드포인트가 자기 조사 쿼리를 지원해야 합니다.

테스트할 대상 API에 대한 정보를 제공하는 GraphQL 엔드포인트 URL을 DAST API에 구성하는 방법은 다음과 같습니다:

  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 파일을 사용하여 제공합니다.

    프로젝트 루트에 있는 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 좋습니다. 자세한 내용은 문서의 동적 환경 솔루션 섹션을 참조하세요.

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/

위 예시는 DAST API의 최소 구성입니다. 여기서부터는:

GraphQL 스키마 파일로 DAST API 스캔

DAST API는 자기 조사가 비활성화된 GraphQL 엔드포인트를 이해하고 테스트하는 데 GraphQL 스키마 파일을 사용할 수 있습니다. GraphQL 스키마 파일을 사용하려면 자기 조사 JSON 형식이어야 합니다. GraphQL 스키마는 온라인 3rd party 도구를 사용하여 자기 조사 JSON 형식으로 변환할 수 있습니다: https://transform.tools/graphql-to-introspection-json.

대상 API에 대한 정보를 제공하는 GraphQL 스키마 파일을 DAST API에 구성하는 방법은 다음과 같습니다:

  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 파일을 사용하여 제공합니다.

    프로젝트 루트에 있는 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 좋습니다. 자세한 내용은 문서의 동적 환경 솔루션 섹션을 참조하세요.

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/

위 예시는 DAST API의 최소 구성입니다. 여기서부터는:

Postman Collection

Postman API Client은 개발자와 테스터가 다양한 유형의 API를 호출하는 데 사용하는 인기 있는 도구입니다. API 정의는 Postman Collection 파일로 내보낼 수 있습니다, DAST API를 사용하기 위해. 내보낼 때, 지원되는 Postman Collection 버전을 선택해야 합니다: v2.0 또는 v2.1.

GitLab DAST API 스캐너와 함께 사용할 때, Postman Collection은 유효한 데이터로 테스트할 웹 API의 정의를 포함해야 합니다. DAST API 스캐너는 모든 API 정의를 추출하여 테스트를 수행합니다.

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

Postman Collection 파일을 사용한 DAST API 스캔

대상 API에 대한 정보를 제공하는 Postman Collection 파일을 사용하도록 DAST API를 구성하려면 다음을 수행하세요:

  1. 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 파일을 사용하여 제공합니다.

    프로젝트 루트에 있는 environment_url.txt 파일에 URL을 추가하면 동적 환경에서의 테스트에 적합합니다. GitLab CI/CD 파이프라인 중에 동적으로 생성된 앱에서 DAST API를 실행하려면 앱이 URL을 environment_url.txt 파일에 지속적으로 저장하도록 합니다. DAST 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/

이는 DAST API를 위한 최소한의 구성입니다. 여기서부터 다음을 수행할 수 있습니다:

Postman 변수

Postman Client의 변수

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

편집 collection 변수 탭 보기

또는 대안으로 환경에 변수를 추가할 수 있습니다:

환경 변수 편집 보기

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

변수 사용한 요청 편집 보기

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

Postman은 다른 범위에 변수를 만들 수 있도록 합니다. 각 범위는 Postman 도구에서 다른 수준의 가시성을 가집니다. 예를 들어, 모든 작업 정의와 워크스페이스에서 볼 수 있는 global environment 범위로 만들 수 있는 변수인 global environment 범위로도 참조할 수 있습니다. 특정 environment 범위에 변수를 만들어 선택한 환경에서만 볼 수 있으면서 사용할 수 있습니다. 일부 범위는 항상 사용할 수 없습니다. 예를 들어, Postman 생태계에서 Postman 클라이언트에서 요청을 만들 수 있지만, 이러한 요청은 local 범위를 가지지 않습니다. 하지만 테스트 스크립트에는 local 범위가 없습니다.

Postman의 변수 범위는 복잡한 주제가 될 수 있으며 모든 사용자가 익숙하지 않을 수 있습니다. 진행하기 전에 Postman 문서의 변수 범위를 꼭 읽으실 것을 강력히 권장합니다.

위에서 언급했듯이, 다양한 변수 범위가 있으며 각각은 Postman 문서의 기본 설정 파일 및 컬렉션 내 정의할 수 있는 여러 가변 인자를 제공할 수 있습니다. 변수 값이 계산되는 방법에 대한 중요한 참고 사항이 있습니다. Postman 문서에 따르면:

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

다음은 Postman 클라이언트 및 DAST API에서 지원하는 변수 범위의 요약입니다.

  • 글로벌 환경 (Global) 범위는 워크스페이스 전체에 사용 가능한 특별하게 정의된 환경입니다. Postman 클라이언트는 글로벌 환경을 JSON 파일로 내보낼 수 있으며, 이를 DAST API와 함께 사용할 수 있습니다.
  • 환경 범위는 Postman 클라이언트에서 사용자가 생성한 변수 그룹의 이름입니다. 활성 사용자가 만든 환경 변수가 전역 환경에 정의된 변수보다 우선합니다. Postman 클라이언트는 환경을 JSON 파일로 내보낼 수 있으며, 이를 DAST API와 함께 사용할 수 있습니다.
  • 컬렉션 범위은 특정 컬렉션에 선언된 변수 그룹입니다. 컬렉션 범위에서 정의된 변수는 정의된 컬렉션 및 중첩된 요청 또는 컬렉션에서 사용할 수 있습니다. 컬렉션 범위에서 정의된 변수는 global environment 범위 및 environment 범위보다 우선합니다. Postman 클라이언트는 하나 이상의 컬렉션을 JSON 파일로 내보낼 수 있으며, 이 JSON 파일에는 선택한 컬렉션, 요청 및 컬렉션 변수가 포함됩니다.
  • DAST API 범위는 DAST API에 의해 추가된 새로운 범위로, 사용자가 다른 지원되는 범위에서 정의된 변수를 재정의하거나 추가할 수 있습니다. 이 범위는 Postman에서 지원되지 않습니다. DAST API 범위 변수는 사용자 정의 JSON 파일 형식을 사용하여 제공됩니다.
    • 환경 또는 컬렉션에 정의된 값을 재정의
    • 스크립트에서 변수 정의
    • 지원되지 않는 _data 범위_에서 단일 데이터 행 정의
  • 데이터 범위는 그 이름 및 값이 JSON 또는 CSV 파일에서 나오는 변수 그룹입니다. Postman 컬렉션 실행기인 NewmanPostman Collection Runner는 JSON 또는 CSV 파일에 있는 항목 수와 동일한 수만큼 컬렉션의 요청을 실행합니다. 이러한 변수의 좋은 사용 사례는 Postman의 스크립트를 사용하여 테스트를 자동화하는 것입니다. DAST API는 CSV 또는 JSON 파일에서 데이터를 읽는 것을 지원하지 않습니다.
  • 로컬 범위는 Postman 스크립트에서 정의된 변수입니다. DAST API는 Postman 스크립트와 해당 확장으로 정의된 변수를 지원하지 않습니다. 하지만 지원 범위 중 하나로 정의하거나 사용자 정의 JSON 형식으로 변수 값을 정의할 수 있습니다.

모든 범위가 DAST API tarafından 지원되지는 않으며 스크립트에서 정의된 변수 역시 지원되지 않습니다. 다음 표는 가장 넓은 범위에서 가장 좁은 범위로 정렬된 것입니다.

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

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

Postman Client에서 내보내기

Postman Client를 사용하면 다양한 파일 형식을 내보낼 수 있습니다. 예를 들어, Postman 컬렉션이나 Postman 환경을 내보낼 수 있습니다. 내보낸 환경은 전역 환경(항상 사용 가능)이거나 이전에 만든 사용자 정의 환경일 수 있습니다. Postman 컬렉션을 내보내면 컬렉션로컬 범위 변수에 대한 선언만 포함될 수 있으며, 환경 범위 변수는 포함되지 않습니다.

환경 범위 변수의 선언을 얻으려면 해당 환경을 그 때 내보내야 합니다. 각 내보낸 파일은 선택한 환경의 변수만 포함합니다.

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

DAST API 범위, 사용자 정의 JSON 파일 형식

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

이 예제에서 DAST API 범위에서 base_urltoken 두 변수를 정의합니다:

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

DAST API와 함께 범위 사용

글로벌, 환경, 컬렉션, GitLab DAST API 범위는 GitLab 15.1 이상에서 지원됩니다. GitLab 15.0 이하에서는 컬렉션GitLab DAST API 범위만 지원됩니다.

다음 표는 범위 파일/URL을 DAST API 구성 변수에 매핑하는 빠른 참조를 제공합니다:

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

Postman 컬렉션 문서에는 자동으로 컬렉션 범위 변수가 포함됩니다. Postman 컬렉션은 구성 변수 DAST_API_POSTMAN_COLLECTION로 제공됩니다. 이 변수는 단일 내보낸 Postman 컬렉션으로 설정할 수 있습니다.

다른 범위에서 변수는 구성 변수 DAST_API_POSTMAN_COLLECTION_VARIABLES를 통해 제공됩니다. 구성 변수는 GitLab 15.1 이상에서 쉼표(,)로 구분된 파일 목록을 지원합니다. GitLab 15.0 이하에서는 하나의 단일 파일만 지원됩니다. 제공된 파일의 순서는 중요하지 않으며, 파일은 필요한 범위 정보를 제공합니다.

구성 변수 DAST_API_POSTMAN_COLLECTION_VARIABLES은 다음에 설정할 수 있습니다:

정의되지 않은 Postman 변수

DAST API 엔진이 Postman 컬렉션 파일에서 사용하는 모든 변수 참조를 찾지 못할 수 있습니다. 일부 경우에 해당하는 경우는 다음과 같습니다:

  • 데이터 또는 로컬 범위 변수를 사용하는 경우이며, 이러한 범위는 DAST API에서 지원되지 않습니다. 따라서 이러한 변수의 값이 DAST API 범위를 통해 제공되지 않은 경우 데이터로컬 범위 변수의 값은 정의되지 않습니다.
  • 변수 이름이 잘못 입력되었으며, 이름이 정의된 변수와 일치하지 않습니다.
  • Postman Client가 지원하는 새로운 동적 변수가 DAST API에서 지원되지 않습니다.

가능한 경우, DAST API는 정의되지 않은 변수와 관련하여 Postman Client의 동일한 동작을 따릅니다. 변수 참조의 텍스트는 변경되지 않으며, 텍스트 대체가 없습니다. 동일한 동작은 지원되지 않는 동적 변수에도 적용됩니다.

예를 들어, Postman 컬렉션의 요청 정의에서 변수 {{full_url}}을 참조하고 변수를 찾을 수 없는 경우 값 {{full_url}}로 남아 있습니다.

동적 Postman 변수

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

DAST API와 Postman 사이의 중요한 차이점은 DAST API가 동일한 동적 변수를 사용하는 각 사용에 대해 동일한 값을 반환하는 반면, Postman 클라이언트 동작은 동일한 동적 변수를 사용할 때마다 무작위 값을 반환합니다. 다시 말하면, DAST API는 동적 변수에 대해 정적 값, Postman은 무작위 값 사용합니다.

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

변수
$guid 611c2e81-2ccb-42d8-9ddc-2d0bfa65c1b4
$isoTimestamp 2020-06-09T21:10:36.177Z
$randomAbbreviation PCI
$randomAbstractImage http://no-a-valid-host/640/480/abstract
$randomAdjective auxiliary
… (중략) …  
$randomWords Samoa Synergistic sticky copying Grocery
$timestamp 1562757107

예시: 글로벌 스코프

이 예에서는 포스트맨 클라이언트에서 전역 스코프가 global-scope.json으로 내보내지고 DAST 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: global-scope.json
  DAST_API_TARGET_URL: http://test-deployment/

예시: 환경 스코프

이 예에서는 포스트맨 클라이언트에서 환경 스코프가 environment-scope.json으로 내보내지고 DAST 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: environment-scope.json
  DAST_API_TARGET_URL: http://test-deployment/

예시: 콜렉션 스코프

콜렉션 스코프 변수는 내보낸 포스트맨 콜렉션 파일에 포함되고 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/

예시: DAST API 스코프

DAST API 스코프는 두 가지 주요 목적으로 사용됩니다. DAST API에서 지원되지 않는 데이터로컬 스코프 변수를 정의하고, 다른 스코프에서 정의된 기존 변수의 값을 변경하는 것입니다. DAST 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은 속성의 키-값 쌍으로 된 객체입니다. 키는 변수의 이름이고 값은 변수의 값입니다. 예시:

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

예시: 다중 스코프

이 예에서는 전역 스코프, 환경 스코프 및 컬렉션 스코프가 구성됩니다. 첫 번째 단계는 다양한 스코프를 내보내는 것입니다.

포스트맨 콜렉션은 DAST_API_POSTMAN_COLLECTION 변수를 사용하여 제공되고, 다른 스코프는 DAST_API_POSTMAN_COLLECTION_VARIABLES를 사용하여 제공됩니다. DAST 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/

예시: 변수 값 변경

내보낸 스코프를 사용할 때 변수의 값을 DAST API와 함께 사용하려면 종종 변수의 값이 변경되어야 하는 경우가 많습니다. 예를 들어, 콜렉션 스코프 변수에는 api_version이라는 변수와 값이 v2인 경우가 있을 수 있으며, 테스트에는 v1의 값을 필요로 할 수 있습니다. 내보낸 콜렉션을 수정하여 값이 변경되는 대신, DAST API 스코프를 사용하여 그 값을 변경할 수 있습니다. 이것은 DAST API 스코프가 다른 모든 스코프보다 우선되기 때문에 작동합니다.

콜렉션 스코프 변수는 내보낸 포스트맨 콜렉션 파일에 포함되고 DAST_API_POSTMAN_COLLECTION 구성 변수를 통해 제공됩니다.

DAST API 스코프는 DAST_API_POSTMAN_COLLECTION_VARIABLES 구성 변수를 통해 제공되지만, 먼저 파일을 생성해야 합니다. 파일 dast-api-scope.json사용자 정의 JSON 파일 형식을 사용합니다. 이 JSON은 속성의 키-값 쌍으로 된 객체입니다. 키는 변수의 이름이고 값은 변수의 값입니다. 예시:

{
  "api_version": "v1"
}

저희의 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/

예시: 다중 범위에서 변수 값 변경

내보낸 범위를 사용할 때 변수의 값이 종종 DAST API와 함께 사용하도록 변경되어야 하는 경우가 많습니다. 예를 들어, 환경 범위에는 값이 v2api_version이라는 변수가 포함될 수 있지만, 테스트에는 값이 v1이 필요할 수 있습니다. 값을 변경하기 위해 내보낸 파일을 수정하는 대신 DAST API 범위를 사용할 수 있습니다. 이는 DAST API 범위가 다른 모든 범위보다 우선시되기 때문에 작동합니다.

이 예제에서는 글로벌 범위, 환경 범위, 컬렉션 범위, DAST API 범위가 구성되어 있습니다. 첫 번째 단계는 각각의 여러 범위를 내보내고 생성하는 것입니다.

DAST API 범위는 사용자 정의 JSON 파일 형식을 사용하여 dast-api-scope.json이라는 파일을 만들어 사용합니다. 이 JSON은 속성에 대한 키-값 쌍으로 구성된 객체입니다. 키는 변수의 이름이고 값은 변수의 값입니다. 예를 들어:

{
  "api_version": "v1"
}

Postman 컬렉션은 DAST_API_POSTMAN_COLLECTION 변수를 사용하여 제공되며, 다른 범위는 DAST_API_POSTMAN_COLLECTION_VARIABLES를 사용하여 제공됩니다. DAST 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 작업이 포함됩니다. 잘못된 구성이 제공된 경우에만 작업이 실패합니다. 일반적으로 작동 중에는 테스트 중에 취약점이 식별되더라도 작업이 항상 성공합니다.

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

보고된 취약점의 수를 과도하게 막기 위해, DAST API 스캐너는 작업 당 보고하는 취약점 수를 제한합니다.

DAST API 취약점 보기

DAST API 분석기는 취약점을 생성하여 사용되고 GitLab 취약점 화면에 취약점을 채우기 위해 수집된 JSON 보고서를 생성합니다.

동일한 false positives를 제한하기 위해 만들 수 있는 구성 변경에 대한 정보는 false positives 처리를 참조하십시오.

DAST API 취약점 세부 정보 보기

취약점의 세부 정보를 보려면 다음 단계를 따르십시오:

  1. 프로젝트나 병합 요청에서 취약점을 볼 수 있습니다:

    • 프로젝트에서 프로젝트의 보안 > 취약점 보고서 페이지로 이동합니다. 이 페이지에는 기본 브랜치에서의 모든 취약점이 표시됩니다.
    • 병합 요청에서 병합 요청의 보안 섹션으로 이동한 다음 확장 버튼을 선택합니다. DAST API 취약점은 DAST detected N potential vulnerabilities라고 표시된 섹션에 있습니다. 취약점 세부 정보를 표시하려면 제목을 선택합니다.
  2. 세부 정보를 표시하려면 취약점 제목을 선택합니다. 아래 표에서 이러한 세부 정보에 대해 설명합니다.

    필드 설명
    설명 취약점에 대한 설명으로 무엇이 수정되었는지를 포함합니다.
    프로젝트 취약점이 감지된 네임스페이스 및 프로젝트입니다.
    메소드 취약점을 감지하는 데 사용된 HTTP 메소드입니다.
    URL 취약점이 감지된 URL입니다.
    요청 취약점을 일으킨 HTTP 요청입니다.
    수정되지 않은 응답 수정되지 않은 요청에 대한 응답입니다. 이것은 전형적인 작동 응답입니다.
    실제 응답 테스트 요청으로부터 수신한 응답입니다.
    증거 취약점이 발생했다는 것을 어떻게 확인했는지입니다.
    식별자 이 취약점을 찾기 위해 사용된 DAST API 검사입니다.
    심각도 취약점의 심각도입니다.
    스캐너 유형 테스트를 수행하는 데 사용된 스캐너입니다.

보안 대시보드

보안 대시보드는 그룹, 프로젝트 및 파이프라인의 모든 보안 취약점에 대한 개요를 얻을 수 있는 좋은 위치입니다. 자세한 내용은 보안 대시보드 문서를 참조하십시오.

취약점과 상호 작용하기

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

잘못된 양성 처리

잘못된 양성은 여러 가지 방법으로 처리할 수 있습니다:

  • 취약점을 해제합니다.
  • 몇 가지 확인 항목은 취약점이 식별될 때 _Assertions_라고 불리는 여러 감지 방법을 가지고 있습니다. Assertions는 또한 끌거나 구성할 수 있습니다. 예를 들어, DAST API 스캐너는 기본적으로 HTTP 상태 코드를 사용하여 실제 문제가 발생했는지 식별하는 데 도움이 됩니다. API가 테스트 중에 500 오류를 반환하면 이것은 취약점을 발생시킵니다. 이는 때때로 원하는 동작이 아닙니다. 왜냐하면 몇몇 프레임워크는 자주 500 오류를 반환하기 때문입니다.
  • 잘못된 양성을 생성하는 확인 항목을 끕니다. 이렇게 하면 해당 확인 항목이 어떠한 취약점도 생성하지 못합니다. 예제 확인 항목으로는 SQL Injection 확인과 JSON Hijacking 확인이 있습니다.

확인 항목 끄기

확인 항목은 특정 유형의 테스트를 수행하며, 특정 구성 프로필에서 켜거나 끌 수 있습니다. 제공된 구성 파일은 사용할 수 있는 여러 프로필을 정의합니다. 구성 파일의 프로필 정의는 스캔 중에 활성화된 모든 확인 항목을 나열합니다. 특정 확인 항목을 끄려면 구성 파일에서 해당 항목을 삭제하세요. 프로필은 구성 파일의 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 확인을 끄려면 이러한 라인을 삭제할 수 있습니다:

          - 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

확인 항목의 Assertion 끄기

Assertions는 확인 항목이 생성한 테스트에서 취약점을 감지합니다. 많은 확인 항목은 Log Analysis, Response Analysis 및 Status Code와 같은 여러 Assertions를 지원합니다. 취약점이 발견되면 사용된 Assertion이 제공됩니다. 기본적으로 활성화된 Assertions를 확인하려면 구성 파일의 확인 항목 기본 구성을 확인하세요. 이 섹션은 Checks라고 합니다.

다음 예제는 SQL Injection 확인을 보여줍니다:

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

여기에서 세 개의 Assertion이 기본적으로 활성화되어 있음을 확인할 수 있습니다. 잘못된 양성의 일반적인 원인 중 하나는 StatusCodeAssertion입니다. 이를 끄려면 구성 파일의 Profiles 섹션에서 해당 설정을 수정하세요. 이 예제에서는 다른 두 Assertion(LogAnalysisAssertion, ResponseAnalysisAssertion)만 제공됩니다. 이렇게 함으로써 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