분석기 활성화하기
다음을 사용하여 스캔하려는 API를 지정할 수 있습니다:
OpenAPI 명세
OpenAPI 명세는 REST API를 위한 API 설명 형식으로, 이 섹션에서는 OpenAPI 명세를 사용하여 DAST 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/json
및application/xml
), JSON을 사용하여 테스트하고 나서 동일한 테스트를 XML을 사용하여 수행합니다.
동일한 작업(예: POST /user
)을 다른 미디어 유형(예: application/json
및 application/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-8
는 type "/" [tree "."] subtype ["+" suffix]* [";" parameter]
의 복합입니다. 필터링 미디어 유형을 생성할 때 매개변수는 고려되지 않습니다.
환경 변수 DAST_API_OPENAPI_ALL_MEDIA_TYPES
및 DAST_API_OPENAPI_MEDIA_TYPES
는 미디어 유형을 처리하는 방법을 지정할 수 있습니다. 이러한 설정은 서로 배타적입니다. 둘 다 활성화되면 DAST API에서 오류를 보고합니다.
OpenAPI 명세로 DAST API 구성
OpenAPI 명세로 DAST API 스캔을 구성하려면 다음을 수행합니다:
-
구성 파일은 여러 테스트 프로필이 정의되어 있으며 각기 다른 확인이 활성화되어 있습니다.
Quick
프로필부터 시작하는 것이 좋습니다. 이 프로필로 테스트하면 구성 확인이 더 쉬워지고 테스트가 빨리 완료됩니다..gitlab-ci.yml
파일에DAST_API_PROFILE
CI/CD 변수를 추가하여 프로필을 제공합니다. -
OpenAPI 명세의 위치를 파일 또는 URL로 지정합니다.
DAST_API_OPENAPI
변수를 추가하여 위치를 지정합니다. -
대상 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에서 이를 확인할 수 있습니다.
OpenAPI 명세를 사용한 DAST 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/
여기서부터는 다음을 수행할 수 있습니다:
- 첫 번째 스캔 실행.
- 인증 추가하기.
- 잘못된 양성 처리 방법 배우기.
HTTP Archive (HAR)
HTTP 아카이브 형식 (HAR)은 HTTP 트랜잭션을 로그로 남기기 위한 아카이브 파일 형식입니다. GitLab DAST API 스캐너와 함께 사용할 때, HAR 파일은 테스트하기 위해 웹 API를 호출한 기록을 포함해야 합니다. DAST API 스캐너는 모든 요청을 추출하여 테스트를 수행합니다.
HAR 파일을 생성하는 다양한 도구를 사용할 수 있습니다:
- Insomnia Core: API 클라이언트
- Chrome: 브라우저
- Firefox: 브라우저
- Fiddler: 웹 디버깅 프록시
- GitLab HAR Recorder: 명령줄
HAR 파일을 사용한 DAST API 스캔
대상 API에 대한 정보를 제공하는 HAR 파일을 사용하도록 DAST API를 구성하려면 다음을 수행합니다:
-
구성 파일에는 여러 테스트 프로필이 정의되어 있으며 다양한 체크가 활성화되어 있습니다.
Quick
프로필부터 시작하는 것을 권장합니다. 이 프로필로 테스트를 진행하면 구성 검증이 쉬워집니다..gitlab-ci.yml
파일에DAST_API_PROFILE
CI/CD 변수를 추가하여 해당 프로필을 제공합니다. -
HAR 파일의 위치를 제공합니다. 파일 경로나 URL을 제공할 수 있습니다. GitLab 13.10 및 이후 버전에서 URL 지원이 추가되었습니다.
DAST_API_HAR
변수를 추가하여 위치를 지정합니다. -
대상 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 스키마
- GraphQL 스키마 지원이 GitLab 15.4에서 추가되었습니다.
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 엔드포인트에서 스키마를 조회할 수 있습니다.
DAST API를 사용하여 테스트할 대상 API에 대한 정보를 제공하기 위해 다음을 수행합니다:
-
GraphQL 엔드포인트의 경로를 제공합니다. 예:
/api/graphql
.DAST_API_GRAPHQL
변수를 추가하여 위치를 지정합니다. -
대상 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의 최소 구성입니다. 여기서부터 다음을 수행할 수 있습니다:
DAST API를 사용한 GraphQL 스키마 파일 스캔
DAST API는 introspection이 비활성화된 GraphQL 엔드포인트를 이해하고 테스트하기 위해 GraphQL 스키마 파일을 사용할 수 있습니다. GraphQL 스키마 파일을 사용하려면, 그 파일은 introspection JSON 형식이어야 합니다. 온라인 3rd party 도구인 https://transform.tools/graphql-to-introspection-json을 사용하여 GraphQL 스키마를 introspection JSON 형식으로 변환할 수 있습니다.
DAST API를 구성하여 대상 API에 대한 정보를 제공하는 GraphQL 스키마 파일을 사용하도록 설정하려면 다음을 수행하세요.
-
이름을 포함
.gitlab-ci.yml
파일에DAST-API.gitlab-ci.yml
템플릿을 추가합니다. -
GraphQL 엔드포인트 경로를 제공합니다. 예를 들어,
/api/graphql
을 지정합니다.DAST_API_GRAPHQL
변수를 추가하여 경로를 지정합니다. -
GraphQL 스키마 파일의 위치를 제공합니다. 파일 경로 또는 URL로 위치를 제공할 수 있습니다.
DAST_API_GRAPHQL_SCHEMA
변수를 추가하여 위치를 지정합니다. -
대상 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 컬렉션
Postman API Client는 개발자와 테스터가 다양한 유형의 API를 호출하는 데 사용하는 인기있는 도구입니다. API 정의는 DAST API에서 사용하기 위해 Postman 컬렉션 파일로 내보낼 수 있습니다. 내보낼 때, 지원되는 Postman 컬렉션 버전인 v2.0 또는 v2.1을 선택해야 합니다.
GitLab DAST API 스캐너와 함께 사용할 때, Postman 컬렉션에는 유효한 데이터로 테스트할 웹 API의 정의가 포함되어야 합니다. DAST API 스캐너는 모든 API 정의를 추출하여 테스트를 수행합니다.
DAST API를 사용한 Postman 컬렉션 파일 스캔
DAST API를 구성하여 대상 API에 대한 정보를 제공하는 Postman 컬렉션 파일을 사용하도록 설정하려면 다음을 수행하세요.
-
이름을 포함
.gitlab-ci.yml
파일에DAST-API.gitlab-ci.yml
템플릿을 추가합니다. -
구성 파일에는 여러 테스트 프로필이 정의되어 있으며 다양한 체크가 활성화되어 있습니다.
Quick
프로필로 시작하는 것이 좋습니다. 해당 프로필을 사용하면 더 빠르게 테스트를 완료하여 구성 유효성을 쉽게 검증할 수 있습니다..gitlab-ci.yml
파일에DAST_API_PROFILE
CI/CD 변수를 추가하여 프로필을 지정합니다. -
Postman 컬렉션 파일의 위치를 파일 또는 URL로 제공합니다.
DAST_API_POSTMAN_COLLECTION
변수를 추가하여 위치를 지정합니다. -
대상 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 컬렉션을 사용한 구성의 예시:
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 환경 파일 형식 지원이 GitLab 15.1에서 도입되었습니다.
- 여러 변수 파일 지원이 GitLab 15.1에서 도입되었습니다.
- Postman 변수 범위(Global 및 Environment) 지원이 GitLab 15.1에서 도입되었습니다.
Postman 클라이언트의 변수
Postman은 개발자가 요청의 다양한 부분에서 사용할 수 있는 플레이스홀더를 정의할 수 있게 합니다. 이러한 플레이스홀더를 변수라고 하며, 변수 사용에서 설명되어 있습니다. 요청 및 스크립트에서 값들을 저장하고 재사용하기 위해 변수를 사용할 수 있습니다. 예를 들어, 다음과 같이 컬렉션을 편집하여 문서에 변수를 추가할 수 있습니다:
또는 환경에 변수를 추가할 수도 있습니다:
그런 다음 URL, 헤더 및 기타 부분에서 이러한 변수를 사용할 수 있습니다:
Postman은 멋진 UX 경험을 제공하는 기본 클라이언트 도구에서 스크립트를 사용하여 API를 테스트하고 복잡한 컬렉션을 생성하여 보조 요청을 트리거하고 이어서 변수를 설정할 수 있는 더 복잡한 생태계로 성장했습니다. Postman 생태계의 모든 기능이 지원되는 것은 아닙니다. 예를 들어, 스크립트는 지원되지 않습니다. Postman 지원의 주요 초점은 Postman 클라이언트에서 사용되는 Postman Collection 정의 및 워크스페이스, 환경 및 컬렉션 자체에 정의된 관련 변수를 수용하는 것입니다.
Postman은 여러 범위에서 변수를 생성할 수 있습니다. 각 범위는 Postman 도구에서 다른 수준의 가시성을 갖습니다. 예를 들어 전역 환경 범위에서 변수를 생성하여 모든 작업 정의 및 워크스페이스에서 볼 수 있습니다. 또한 특정 환경 범위에서 변수를 생성하여 해당 환경이 선택된 경우에만 볼 수 있고 사용할 수 있습니다. 일부 범위는 항상 사용할 수 있는 것은 아닙니다. 예를 들어 Postman 생태계에서 Postman 클라이언트에서 요청을 생성할 수 있지만 로컬 범위는 없습니다. 하지만 테스트 스크립트는 있습니다.
Postman의 변수 범위는 이해하기 어려운 주제일 수 있으며 모든 사람이 익숙하지는 않을 수 있습니다. 따라서 앞으로 진행하기 전에 반드시 변수 범위에서 Postman 문서를 읽기를 강력히 권장합니다.
앞서 언급한 대로 다양한 변수 범위가 있으며 각각의 목적을 갖고 Postman 문서에 더 많은 유연성을 제공할 수 있습니다. 또한 Postman 문서에 따르면 변수 값에 대한 중요한 내용이 있습니다:
동일한 이름의 변수가 두 개의 다른 범위에서 선언되면 가장 좁은 범위에 저장된 값이 사용됩니다. 예를 들어 전역 변수인
username
과 지역 변수인username
이 있는 경우 요청이 실행될 때 지역 값이 사용됩니다.
다음은 Postman 클라이언트와 DAST API에서 지원되는 변수 범위에 대한 요약입니다:
- 전역 환경(Global) 범위은 워크스페이스 전체에서 사용할 수 있는 특별하게 정의된 환경입니다. 우리는 전역 환경(Global) 범위_를 _전역 범위로도 참조할 수 있습니다. Postman 클라이언트는 전역 환경을 JSON 파일로 내보낼 수 있으며, 이는 DAST API에서 사용할 수 있습니다.
- 환경 범위는 Postman 클라이언트에서 사용자가 생성한 변수의 이름 그룹입니다. Postman 클라이언트는 전역 환경과 함께 단일 활성 환경을 지원합니다. 활성 사용자 생성 환경에 정의된 변수는 전역 환경에 정의된 변수보다 우선합니다. Postman 클라이언트는 환경을 JSON 파일로 내보낼 수 있으며, 이는 DAST API에서 사용할 수 있습니다.
- 컬렉션 범위은 특정 컬렉션에서 선언된 변수 그룹입니다. 컬렉션 변수는 선언된 컬렉션 및 중첩된 요청 또는 컬렉션에서 사용할 수 있습니다. 컬렉션 범위에서 정의된 변수는 전역 환경 범위 및 환경 범위보다 우선합니다. Postman 클라이언트는 하나 이상의 컬렉션을 JSON 파일로 내보낼 수 있으며, 이 파일에는 선택한 컬렉션, 요청 및 컬렉션 변수가 포함됩니다.
-
DAST API 범위는 DAST API가 추가한 새로운 범위로, 기존 지원되는 범위에서 정의된 변수를 무시하거나 추가 변수를 제공할 수 있습니다. 이 범위는 Postman에서는 지원되지 않습니다. DAST API 범위 변수는 사용자 지정 JSON 파일 형식을 사용하여 제공됩니다.
- 환경 또는 컬렉션에서 정의된 값 무시
- 스크립트에서 변수 정의
- 지원되지 않는 _데이터 범위_에서 데이터의 단일 행 정의
- 데이터 범위는 이름 및 값이 JSON 또는 CSV 파일에서 가져온 변수 그룹입니다. Postman 컬렉션 실행기인 Newman 또는 Postman 컬렉션 실행기는 JSON 또는 CSV 파일의 항목 개수만큼 컬렉션의 요청을 실행합니다. 이러한 변수의 좋은 사용 사례는 Postman의 스크립트를 사용하여 테스트를 자동화하는 것입니다. DAST API는 CSV 또는 JSON 파일에서 데이터를 읽는 것을 지원하지 않습니다.
- 로컬 범위는 Postman 스크립트에서 정의된 변수입니다. DAST API는 Postman 스크립트와 그에 따른 변수를 지원하지 않습니다. 그러나 지원되는 범위 중 하나에 정의하여 스크립트로 정의된 변수의 값을 제공할 수 있습니다.
모든 범위가 DAST API에서 지원되지는 않으며 스크립트에서 정의된 변수도 지원되지 않습니다. 다음 표는 가장 넓은 범위에서 가장 좁은 범위로 정렬되어 있습니다.
범위 | Postman | DAST API | 설명 |
---|---|---|---|
전역 환경 | 예 | 예 | 특별하게 정의된 환경 |
환경 | 예 | 예 | 이름 지정 환경 |
컬렉션 | 예 | 예 | Postman 컬렉션에 정의됨 |
DAST API 범위 | 아니요 | 예 | DAST API가 추가한 사용자 정의 범위 |
데이터 | 예 | 아니요 | CSV 또는 JSON 형식의 외부 파일 |
로컬 | 예 | 아니요 | 스크립트에서 정의된 변수 |
다양한 범위에서 변수를 정의하고 내보내는 방법에 대한 자세한 내용은 다음을 참조하세요:
Postman 클라이언트에서의 내보내기
Postman 클라이언트를 사용하면 다양한 파일 형식으로 내보낼 수 있으며, 예를 들어 Postman 컬렉션이나 Postman 환경을 내보낼 수 있습니다. 내보낸 환경은 전역 환경(항상 사용 가능)이거나 이전에 만든 사용자 정의 환경일 수 있습니다. Postman 컬렉션을 내보낼 때는 컬렉션 및 로컬 범위 변수만 포함될 수 있으며 환경 범위 변수는 포함되지 않습니다.
환경 범위 변수에 대한 선언을 얻으려면 해당 환경을 그 때 내보내야 합니다. 각 내보낸 파일은 선택한 환경의 변수만 포함합니다.
지원되는 다양한 범위에서 변수를 내보내는 자세한 내용은 다음을 참조하세요:
DAST API 범위, 사용자 정의 JSON 파일 형식
저희의 사용자 정의 JSON 파일 형식은 JSON 객체로, 각 객체 속성은 변수 이름을 나타내고 속성 값은 변수 값입니다. 이 파일은 원하는 텍스트 편집기를 사용하여 작성하거나 파이프라인의 이전 작업에서 생성할 수 있습니다.
이 예시에서는 DAST API 범위에서 base_url
및 token
두 변수를 정의합니다:
{
"base_url": "http://127.0.0.1/",
"token": "Token 84816165151"
}
DAST API와 함께 범위 사용
범위인 global, environment, collection, 및 GitLab DAST API_는 GitLab 15.1 및 이후 버전에서 지원됩니다. GitLab 15.0 및 이전 버전에서는 _collection 및 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 컬렉션 문서에는 자동으로 collection 범위 변수가 포함됩니다. 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 컬렉션 파일이 사용하는 모든 변수 참조를 찾지 못할 수 있는 가능성이 있습니다. 이는 다음과 같은 경우가 있습니다:
- data 또는 local 범위 변수를 사용하고 있으며, 이러한 범위가 DAST API에서 지원되지 않기 때문에 DAST API 범위를 통해 이러한 변수의 값을 제공하지 않았다고 가정할 때, data_와 _local 범위 변수의 값은 정의되지 않습니다.
- 변수 이름이 잘못 입력되었으며, 해당 이름이 정의된 변수와 일치하지 않습니다.
- Postman 클라이언트가 DAST API에서 지원하지 않는 새 동적 변수를 지원합니다.
가능한 경우 DAST API는 정의되지 않은 변수를 처리할 때 Postman 클라이언트와 동일한 동작을 수행합니다. 변수 참조 텍스트는 동일한 상태로 유지되며 텍스트 치환은 이루어지지 않습니다. 동일한 동적 변수의 지원되지 않는 동작에도 동일한 동작이 적용됩니다.
예를 들어, Postman 컬렉션의 요청 정의가 변수 {{full_url}}
을 참조하고 해당 변수를 찾을 수 없을 때, 해당 값은 {{full_url}}
로 유지됩니다.
Postman 동적 변수
사용자가 다양한 범위 수준에서 정의할 수 있는 변수 외에도, Postman에는 동적 변수라고 불리는 미리 정의된 변수 집합이 있습니다. 동적 변수는 이미 정의되어 있으며, 해당 이름은 달러 기호($
)로 접두사가 붙습니다. 예를 들어, $guid
와 같이요. 동적 변수는 다른 변수와 마찬가지로 사용할 수 있으며, Postman 클라이언트에서 요청/컬렉션 실행 중에 무작위 값을 생성합니다.
DAST API와 Postman 간의 중요한 차이점은 DAST API가 동일한 동적 변수 사용에 대해 동일한 값을 반환한다는 것입니다. 이는 Postman 클라이언트의 동작과는 다르며, 후자는 동일한 동적 변수 사용 시 매번 무작위 값을 반환합니다. 다시 말해, DAST API는 동적 변수에 대해 정적 값 사용하고, Postman은 무작위 값 사용합니다.
스캔 프로세스 중에 지원되는 동적 변수는 다음과 같습니다:
변수 | 값 |
---|---|
$guid
| 611c2e81-2ccb-42d8-9ddc-2d0bfa65c1b4
|
… |
(이어지는 동적 변수 디렉터리의 번역을 위해 이어지는 부분과 함께 추가적인 도움을 받아야 할 수 있습니다.)
예시: 전역 범위
이 예에서는 Postman 클라이언트에서 전역 범위가 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/
예시: 환경 범위
이 예에서는 Postman 클라이언트에서 환경 범위가 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/
예시: 컬렉션 범위
컬렉션 범위 변수는 내보낸 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/
예시: 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"
}
예시: 여러 범위
이 예에서는 전역 범위, 환경 범위, 및 컬렉션 범위가 구성됩니다. 첫 번째 단계는 다양한 범위를 내보내는 것입니다.
-
전역 범위를 내보냅니다(
global-scope.json
로). -
환경 범위를 내보냅니다 (
environment-scope.json
로). -
컬렉션 범위를 포함하는 Postman 컬렉션을
postman-collection.json
로 내보냅니다.
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_TARGET_URL: http://test-deployment/
예시: 변수 값 변경
내보낸 범위를 사용할 때 종종 변수의 값이 DAST API와 사용하기 위해 변경되어야 합니다. 예를 들어, 컬렉션 범위 변수에는 api_version
이라는 변수가 v2
의 값으로 포함되어 있을 수 있고, 테스트에는 v1
의 값이 필요할 수 있습니다. 내보낸 컬렉션을 수정하여 값을 변경하는 대신, DAST API 범위를 사용하여 값을 변경할 수 있습니다. 이는 DAST API 범위가 모든 다른 범위보다 우선한다는 이유 때문에 작동합니다.
컬렉션 범위 변수는 내보낸 Postman 컬렉션 파일에 포함되어 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와 사용하기 위해 변경되어야 합니다. 예를 들어, 환경 범위 변수에는 api_version
이라는 변수가 v2
의 값으로 포함되어 있을 수 있고, 테스트에는 v1
의 값이 필요할 수 있습니다. 내보낸 파일을 수정하여 값을 변경하는 대신, DAST API 범위를 사용할 수 있습니다. 이는 DAST API 범위가 모든 다른 범위보다 우선한다는 이유 때문에 작동합니다.
이 예에서는 전역 범위, 환경 범위, 컬렉션 범위, 및 DAST API 범위가 구성됩니다. 먼저 다양한 범위를 내보내고 생성해야 합니다.
-
전역 범위를 내보냅니다 (
global-scope.json
로). -
환경 범위를 내보냅니다 (
environment-scope.json
로). -
컬렉션 범위를 포함하는 Postman 컬렉션을
postman-collection.json
로 내보냅니다.
DAST API 범위는 DAST_API_POSTMAN_COLLECTION_VARIABLES
구성 변수를 통해 제공됩니다. 사용자 정의 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 분석기는 수집되고 사용되는 JSON 보고서를 생성합니다 GitLab 취약점 화면으로 취약점을 채우기 위해 합니다.
거짓 긍정을 처리에 대한 자세한 정보는 거짓 긍정 처리를 참조하세요.
DAST API 취약점의 세부 정보 보기
취약점의 세부 정보를 보려면 다음 단계를 따르세요:
-
프로젝트 또는 Merge Request에서 취약점을 볼 수 있습니다:
- 프로젝트에서는 프로젝트의 보안 > 취약점 보고서 페이지로 이동합니다. 이 페이지에는 기본 브랜치에서의 모든 취약점이 표시됩니다.
- Merge Request에서는 Merge Request의 보안 섹션으로 이동한 다음 확장 버튼을 선택합니다. DAST API 취약점은 DAST에서 N개의 잠재적 취약점 감지라고 표시되는 섹션에서 사용할 수 있습니다. 취약점 세부 정보를 표시하려면 제목을 선택합니다.
-
취약점 제목을 선택하여 세부 정보를 표시합니다. 아래 표는 이러한 세부 정보를 설명합니다.
필드 설명 설명 취약점에 대한 설명으로, 무엇이 수정되었는지를 포함합니다. 프로젝트 취약점이 감지된 네임스페이스 및 프로젝트입니다. 메소드 취약점을 탐지하는 데 사용된 HTTP 메소드입니다. URL 취약점이 감지된 URL입니다. 요청 취약점을 일으킨 HTTP 요청입니다. 수정되지 않은 응답 수정되지 않은 요청에 대한 응답입니다. 이것은 전형적인 작동 응답입니다. 실제 응답 테스트 요청으로부터 수신된 응답입니다. 증거 취약점이 발생한 방법입니다. 식별자 이 취약점을 찾기 위해 사용된 DAST API 체크입니다. 심각도 취약점의 심각도입니다. 스캐너 유형 테스트를 수행하는데 사용된 스캐너입니다.
보안 대시보드
보안 대시보드는 그룹, 프로젝트 및 파이프라인에 있는 모든 보안 취약점에 대한 개요를 얻기에 좋은 장소입니다. 자세한 정보는 보안 대시보드 문서를 참조하세요.
취약점 상호 작용
취약점을 발견하면 이와 상호 작용할 수 있습니다. 취약점을 해결하는 방법에 대해 더 알아보려면 취약점 처리를 참조하세요.
거짓 긍정 처리
거짓 긍정은 여러 가지 방법으로 처리할 수 있습니다:
- 취약점을 무시합니다.
- 일부 체크에는 취약점을 식별하는 여러 가지 방법이 있는데, 이를 _억양(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
결과는 다음과 같습니다:
- 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
체크의 억양 끄기
억양은 체크에서 생성된 테스트의 취약점을 감지합니다. 많은 체크가 로그 분석, 응답 분석 및 상태 코드와 같은 여러 가지 억양을 지원합니다. 취약점이 발견될 때 사용된 억양이 제공됩니다. 기본 설정에 사용 중인 어떠한 억양인지 확인하려면 구성 파일의 체크 기본 구성을 참조하세요. 이 섹션은 Checks
로 불립니다.
다음 예시는 SQL Injection 체크를 보여줍니다:
- Name: SqlInjectionCheck
Configuration:
UserInjections: []
Assertions:
- Name: LogAnalysisAssertion
- Name: ResponseAnalysisAssertion
- Name: StatusCodeAssertion
여기서 기본 설정에서 세 가지 억양이 사용 중입니다. 거짓 긍정의 일반적인 원인은 StatusCodeAssertion
입니다. 이것을 끄려면 구성 파일의 Profiles
섹션에서 이를 수정하면 됩니다. 다음 예시는 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