Web API Fuzzing Configuration Form
- UI에서 Web API Fuzzing 구성
OpenAPI Specification
OpenAPI 및 미디어 타입
- OpenAPI Specification을 사용하여 Web API 퍼징 구성
HTTP Archive (HAR)
- HAR 파일을 사용하여 Web API 퍼징 구성
GraphQL 스키마
- GraphQL 엔드포인트 URL을 사용한 API Fuzzing 스캔
- GraphQL 스키마 파일을 사용한 API Fuzzing
Postman 컬렉션
- Postman 컬렉션 파일을 사용하여 웹 API 퍼징 구성
- Postman 변수
첫 번째 스캔 실행하기
퍼징 결함 보기
잘못된 양성 결과 처리
- Check를 끄기
- Check에 대한 어서션 끄기

Analyzer 활성화

요구 사항:

다음 중 하나의 웹 API 유형:
- REST API
- SOAP
- GraphQL
- Form bodies, JSON 또는 XML
테스트할 API를 제공하기 위한 다음 자산 중 하나:
- OpenAPI v2 또는 v3 API 정의
- API 테스트용 HTTP 아카이브 (HAR)
- Postman Collection v2.0 또는 v2.1
프로덕션 서버에 대해 Fuzz 테스트를 결코 실행하지 마십시오. API가 수행할 수 있는 모든 기능을 수행할 뿐만 아니라 API에서 버그를 유발할 수도 있습니다. 이는 데이터 수정 및 삭제와 같은 동작도 포함됩니다. Fuzzing은 테스트 서버에서만 실행하십시오.

Web API Fuzzing 활성화하려면:

.gitlab-ci.yml 파일에 API Fuzzing 템플릿을 포함합니다.
GitLab 13.10 이상에서 웹 API Fuzzing 구성 양식을 사용합니다.
매뉴얼 구성 지침은 API 유형에 따라 해당 섹션을 참조하십시오:
그렇지 않으면 Web API Fuzzing Configuration Form을 참조하십시오.

GitLab 14.0 및 이후에서 API Fuzzing 구성 파일은 귀하의 리포지터리 루트가 아닌 .gitlab 디렉터리에 있어야 합니다.

Web API Fuzzing Configuration Form

GitLab 13.10에서 도입되었습니다.

API Fuzzing 구성 양식을 사용하여 프로젝트의 API Fuzzing 구성을 작성하거나 수정하는 데 도움이 됩니다. 이 양식을 사용하면 가장 일반적인 API Fuzzing 옵션에 대한 값을 선택하고 GitLab CI/CD 구성에 붙여넣을 YAML 스니펫을 작성할 수 있습니다.

UI에서 Web API Fuzzing 구성

API Fuzzing 구성 스니펫을 생성하려면:

왼쪽 사이드바에서 검색 또는 이동하여를 선택하고 프로젝트를 찾습니다.
보안 > 보안 구성을 선택합니다.
API Fuzzing 행에서 API Fuzzing 활성화를 선택합니다.
필드를 완성합니다. 자세한 내용은 사용 가능한 CI/CD 변수를 참조하십시오.
코드 스니펫 생성을 선택합니다. 모달이 열리고 선택한 옵션에 해당하는 YAML 스니펫이 표시됩니다.
다음 중 하나를 수행하십시오:
1. 스니펫을 클립보드에 복사하려면 코드만 복사를 선택합니다.
2. 프로젝트의 .gitlab-ci.yml 파일에 스니펫을 추가하려면 코드 복사 및 .gitlab-ci.yml 파일 열기를 선택합니다. 파이프라인 편집기가 열립니다.
  1. 스니펫을 .gitlab-ci.yml 파일에 붙여넣습니다.
  2. 수정된 .gitlab-ci.yml 파일이 유효한지 확인하려면 Lint 탭을 선택하십시오.
  3. 편집 탭을 선택한 후 변경 사항 커밋을 선택하십시오.

스니펫이 .gitlab-ci.yml 파일에 커밋되면 파이프라인에 API Fuzzing 작업이 포함됩니다.

OpenAPI Specification

GitLab 13.9에서 OpenAPI Specification v3.0 지원이 도입되었습니다.
YAML 형식을 사용하는 OpenAPI Specification 지원이 GitLab 14.0에서 도입되었습니다.
GitLab 14.2에서 OpenAPI Specification v3.1 지원이 도입되었습니다.
application/xml 미디어 타입 생성 지원이 GitLab 14.8에서 도입되었습니다.
미디어 타입 선택 지원이 GitLab 14.10에서 도입되었습니다.

OpenAPI Specification(이전 Swagger Specification)은 REST API용 API 설명 형식입니다. 이 섹션에서는 대상 API에 대한 정보를 제공하기 위해 OpenAPI Specification을 사용하여 API Fuzzing를 구성하는 방법을 보여줍니다. OpenAPI Specification은 파일 시스템 리소스 또는 URL로 제공됩니다. JSON 및 YAML 형식의 OpenAPI를 모두 지원합니다.

API Fuzzing은 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 Fuzzing은 나열된 미디어 타입을 확인하고 각 지원되는 미디어 타입에 대한 샘플 데이터를 생성하려고 시도합니다.

GitLab 14.10 및 이후에서 기본 동작은 지원되는 미디어 타입 중 하나를 선택하는 것입니다. 리스트에서 첫 번째 지원되는 미디어 타입이 선택됩니다. 이 동작은 설정 가능합니다.
GitLab 14.9 및 이전에서 기본 동작은 모든 지원되는 미디어 타입을 사용하여 테스트를 수행하는 것입니다. 이는 두 개의 미디어 타입(application/json 및 application/xml 등)이 디렉터리에 있을 경우 JSON을 사용하여 테스트한 다음 동일한 테스트를 XML을 사용하여 수행합니다.

동일한 작업(예: POST /user)을 서로 다른 미디어 타입(예: application/json 및 application/xml)을 사용하여 테스트하는 것이 항상 바람직한 것은 아닙니다. 예를 들어 대상 애플리케이션이 요청 내용 유형에 관계없이 동일한 코드를 실행하는 경우 테스트 세션이 더 오래 걸리고 대상 앱에 따라 요청 본문과 관련된 중복된 취약점을 보고할 수 있습니다.

환경 변수 FUZZAPI_OPENAPI_ALL_MEDIA_TYPES를 사용하여 특정 작업에 대해 하나가 아닌 모든 지원되는 미디어 타입을 사용할지 여부를 지정할 수 있습니다. 환경 변수 FUZZAPI_OPENAPI_ALL_MEDIA_TYPES가 임의의 값을 설정하는 경우 특정 작업에 대해 하나가 아닌 모든 지원되는 미디어 타입을 생성하려고 노력합니다. 이는 제공된 각 미디어 타입에 대해 테스트를 반복하기 때문에 테스트에 더 많은 시간이 소요됩니다.

반면에, 변수 FUZZAPI_OPENAPI_MEDIA_TYPES는 선택한 미디어 타입의 디렉터리을 제공하는 데 사용됩니다. 여러 미디어 타입을 제공하면 각 미디어 타입을 선택하여 테스트를 수행하기 때문에 테스트에 더 많은 시간이 소요됩니다. 환경 변수 FUZZAPI_OPENAPI_MEDIA_TYPES가 미디어 타입 디렉터리으로 설정된 경우, 생성할 요청에 포함되는 미디어 타입은 제공된 디렉터리 중에 있는 미디어 타입뿐입니다. 지원되지 않는 미디어 타입은 항상 건너뛰게 됩니다. 미디어 타입 텍스트에는 다른 섹션이 포함될 수 있습니다. 예를 들어 application/vnd.api+json; charset=UTF-8는 type "/" [tree "."] subtype ["+" suffix]* [";" parameter]의 조합입니다. 요청 생성시 미디어 타입을 필터링할 때 매개변수는 고려되지 않습니다.

환경 변수 FUZZAPI_OPENAPI_ALL_MEDIA_TYPES 및 FUZZAPI_OPENAPI_MEDIA_TYPES를 사용하여 미디어 타입을 처리하는 방법을 결정할 수 있습니다. 이러한 설정은 상호 배타적입니다. 두 가지가 모두 활성화된 경우 API Fuzzing에서 오류가 보고됩니다.

OpenAPI Specification을 사용하여 Web API 퍼징 구성

GitLab에서 OpenAPI Specification으로 API 퍼징을 구성하려면 다음을 수행하세요:

.gitlab-ci.yml 파일에 fuzz 스테이지를 추가합니다.
.gitlab-ci.yml 파일에 API-Fuzzing.gitlab-ci.yml 템플릿을 포함합니다.
프로파일을 지정하려면 FUZZAPI_PROFILE CI/CD 변수를 .gitlab-ci.yml 파일에 추가합니다. 프로파일은 실행되는 테스트의 수를 지정합니다. 선택한 프로파일에 대해 Quick-10을 대체합니다. 자세한 내용은 API 퍼징 프로파일을 참조하십시오.
```
variables:
  FUZZAPI_PROFILE: Quick-10
```
OpenAPI Specification의 위치를 지정합니다. 명세서를 파일 또는 URL로 제공할 수 있습니다. FUZZAPI_OPENAPI 변수를 추가하여 위치를 지정합니다.
대상 API 인스턴스의 기본 URL을 제공합니다. FUZZAPI_TARGET_URL 변수 또는 environment_url.txt 파일을 사용하십시오.
프로젝트 루트의 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 유용합니다. GitLab CI/CD 파이프라인 중에 동적으로 생성된 응용 프로그램에 대해 API 퍼징을 실행하려면 응용 프로그램이 해당 URL을 environment_url.txt 파일에 유지하도록합니다. API 퍼징은 자동으로 해당 파일을 구문 분석하여 스캔 대상을 찾습니다. Auto DevOps CI YAML에서 실제 예시를 확인할 수 있습니다.

OpenAPI Specification을 사용하는 예시 .gitlab-ci.yml 파일:

   stages:
     - fuzz
   
   include:
     - template: API-Fuzzing.gitlab-ci.yml
   
   variables:
     FUZZAPI_PROFILE: Quick-10
     FUZZAPI_OPENAPI: test-api-specification.json
     FUZZAPI_TARGET_URL: http://test-deployment/

이것은 API 퍼징을 위한 최소 구성입니다. 여기서부터 다음을 수행할 수 있습니다:

첫 번째 스캔 실행](#running-your-first-scan).
인증 추가.
거짓 긍정 처리 방법을 학습합니다.

API 퍼징 구성 옵션에 대한 자세한 내용은 사용 가능한 CI/CD 변수를 참조하십시오.

HTTP Archive (HAR)

HTTP Archive 형식 (HAR) 은 HTTP 트랜잭션을 기록하는 아카이브 파일 형식입니다. GitLab API 퍼저와 함께 사용될 때, HAR은 테스트할 웹 API를 호출하는 레코드를 포함해야합니다. API 퍼저는 모든 요청을 추출하여 테스트에 사용합니다.

HAR 파일 더 자세한 내용 및 HAR 파일 생성 방법에 대해 알아보려면 HTTP Archive 형식을 참조하십시오.

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

HAR 파일을 사용하여 Web API 퍼징 구성

API 퍼징을 HAR 파일을 사용하도록 구성하려면 다음을 수행하세요:

.gitlab-ci.yml 파일에 fuzz 스테이지를 추가합니다.
.gitlab-ci.yml 파일에 API-Fuzzing.gitlab-ci.yml 템플릿을 포함합니다.
프로파일을 지정하려면 FUZZAPI_PROFILE CI/CD 변수를 .gitlab-ci.yml 파일에 추가합니다. 프로파일은 실행되는 테스트의 수를 지정합니다. 선택한 프로파일에 대해 Quick-10을 대체합니다. 자세한 내용은 API 퍼징 프로파일을 참조하십시오.
```
variables:
  FUZZAPI_PROFILE: Quick-10
```
HAR 명세서의 위치를 지정합니다. 명세서를 파일 또는 URL로 제공할 수 있습니다. FUZZAPI_HAR 변수를 추가하여 위치를 지정합니다.
대상 API 인스턴스의 기본 URL도 필요합니다. FUZZAPI_TARGET_URL 변수 또는 environment_url.txt 파일을 사용하여 제공하십시오.
프로젝트 루트의 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 유용합니다. GitLab CI/CD 파이프라인 중에 동적으로 생성된 응용 프로그램에 대해 API 퍼징을 실행하려면 응용 프로그램이 해당 URL을 environment_url.txt 파일에 유지하도록합니다. API 퍼징은 자동으로 해당 파일을 구문 분석하여 스캔 대상을 찾습니다. Auto DevOps CI YAML에서 실제 예시를 확인할 수 있습니다.

HAR 파일을 사용하는 예시 .gitlab-ci.yml 파일:

   stages:
     - fuzz
   
   include:
     - template: API-Fuzzing.gitlab-ci.yml
   
   variables:
     FUZZAPI_PROFILE: Quick-10
     FUZZAPI_HAR: test-api-recording.har
     FUZZAPI_TARGET_URL: http://test-deployment/

이것은 API 퍼징을 위한 최소 구성입니다. 여기서부터 다음을 수행할 수 있습니다:

첫 번째 스캔 실행.
인증 추가.
거짓 긍정 처리 방법을 학습합니다.

API 퍼징 구성 옵션에 대한 자세한 내용은 사용 가능한 CI/CD 변수를 참조하십시오.

GraphQL 스키마

GraphQL 스키마 지원은 GitLab 15.4에서 소개되었습니다.

GraphQL은 API용 쿼리 언어이자 REST API의 대안입니다. API 퍼징은 GraphQL 엔드포인트를 여러 가지 방법으로 테스트할 수 있습니다:

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

이 섹션에서는 GraphQL 스키마를 사용하여 테스트하는 방법에 대해 문서화합니다. API 퍼징의 GraphQL 스키마 지원은 승인 지원하는 엔드포인트에서 스키마를 쿼리할 수 있습니다. 인트로스펙션은 GraphiQL과 같은 도구가 작동하도록 기본적으로 활성화되어 있습니다.

GraphQL 엔드포인트 URL을 사용한 API Fuzzing 스캔

API Fuzzing의 GraphQL 지원은 스키마를 위한 GraphQL 엔드포인트를 쿼리할 수 있습니다.

이 방법을 올바르게 작동시키려면 GraphQL 엔드포인트가 내부조사 쿼리를 지원해야 합니다.

API Fuzzing을 구성하여 테스트할 대상 API에 대한 정보를 제공하는 GraphQL 엔드포인트 URL을 사용하려면 다음을 수행하세요.

당신의 .gitlab-ci.yml 파일에 API-Fuzzing.gitlab-ci.yml 템플릿을 포함합니다.
GraphQL 엔드포인트 경로를 제공합니다. 예를 들어 /api/graphql와 같이 지정합니다. FUZZAPI_GRAPHQL 변수를 추가하여 경로를 지정합니다.
대상 API 인스턴스의 기본 URL도 필요합니다. FUZZAPI_TARGET_URL 변수나 environment_url.txt 파일을 사용하여 제공합니다.
프로젝트 루트에 있는 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 적합합니다. 자세한 내용은 당사 문서의 동적 환경 솔루션 섹션을 확인하세요.

GraphQL 엔드포인트 URL을 사용하는 API Fuzzing의 완전한 예제 구성:

stages:
  - fuzz

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

apifuzzer_fuzz:
  variables:
    FUZZAPI_GRAPHQL: /api/graphql
    FUZZAPI_TARGET_URL: http://test-deployment/

이 예는 API Fuzzing의 최소 구성입니다. 여기서부터 다음을 수행할 수 있습니다.

첫 번째 스캔 실행.
인증 추가.
잘못된 양성 처리 방법.

GraphQL 스키마 파일을 사용한 API Fuzzing

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

API Fuzzing을 구성하여 대상 API에 대한 정보를 제공하는 GraphQL 스키마 파일을 사용하려면 다음을 수행하세요.

당신의 .gitlab-ci.yml 파일에 API-Fuzzing.gitlab-ci.yml 템플릿을 포함합니다.
GraphQL 엔드포인트 경로를 제공합니다. 예를 들어 /api/graphql와 같이 지정합니다. FUZZAPI_GRAPHQL 변수를 추가하여 경로를 지정합니다.
GraphQL 스키마 파일의 위치를 제공해야 합니다. 파일 경로나 URL로 제공할 수 있습니다. FUZZAPI_GRAPHQL_SCHEMA 변수를 추가하여 위치를 지정합니다.
대상 API 인스턴스의 기본 URL도 필요합니다. FUZZAPI_TARGET_URL 변수나 environment_url.txt 파일을 사용하여 제공합니다.
프로젝트 루트에 있는 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 적합합니다. 자세한 내용은 당사 문서의 동적 환경 솔루션 섹션을 확인하세요.

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

stages:
  - fuzz

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

apifuzzer_fuzz:
  variables:
    FUZZAPI_GRAPHQL: /api/graphql
    FUZZAPI_GRAPHQL_SCHEMA: test-api-graphql.schema
    FUZZAPI_TARGET_URL: http://test-deployment/

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

stages:
  - fuzz

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

apifuzzer_fuzz:
  variables:
    FUZZAPI_GRAPHQL: /api/graphql
    FUZZAPI_GRAPHQL_SCHEMA: http://file-store/files/test-api-graphql.schema
    FUZZAPI_TARGET_URL: http://test-deployment/

이 예는 API Fuzzing의 최소 구성입니다. 여기서부터 다음을 수행할 수 있습니다.

첫 번째 스캔 실행.
인증 추가.
잘못된 양성 처리 방법.

Postman 컬렉션

Postman API Client는 개발자와 테스터가 다양한 유형의 API를 호출하는 데 사용하는 인기 있는 도구입니다. API 정의는 Postman 컬렉션 파일로 내보낼 수 있습니다 API Fuzzing에서 사용하도록 만들려면 지원되는 버전인 v2.0 또는 v2.1을 선택하는지 확인하십시오.

GitLab API fuzzer와 함께 사용할 때, Postman 컬렉션에는 유효한 데이터로 테스트할 웹 API의 정의가 포함되어야 합니다. API fuzzer는 API 정의를 모두 추출하여 테스트를 수행합니다.

Postman 컬렉션 파일에는 인증 토큰, API 키, 세션 쿠키 등과 같은 민감한 정보가 포함될 수 있습니다. 파일을 리포지터리에 추가하기 전에 Postman 컬렉션 파일 내용을 검토하는 것이 좋습니다.

Postman 컬렉션 파일을 사용하여 웹 API 퍼징 구성

API 퍼징을 위해 Postman 컬렉션 파일을 사용하도록 구성하려면 다음을 수행하세요.

당신의 .gitlab-ci.yml 파일에 fuzz stage를 추가합니다.
당신의 .gitlab-ci.yml 파일에 API-Fuzzing.gitlab-ci.yml 템플릿을 포함합니다.
.gitlab-ci.yml 파일에 FUZZAPI_PROFILE CI/CD 변수를 추가하여 프로필을 제공합니다. 프로필은 실행할 테스트의 개수를 지정합니다. 사용할 프로필을 Quick-10으로 대체하십시오. 자세한 내용은 API 퍼징 프로필을 참조하세요.
```
variables:
  FUZZAPI_PROFILE: Quick-10
```
Postman 컬렉션 사양의 위치를 지정해야 합니다. 파일 또는 URL로 사양을 제공할 수 있습니다. URL 지원은 GitLab 13.10부터 도입되었습니다. FUZZAPI_POSTMAN_COLLECTION 변수를 추가하여 위치를 지정합니다.
대상 API 인스턴스의 기본 URL을 제공해야 합니다. FUZZAPI_TARGET_URL 변수나 environment_url.txt 파일을 사용하세요.
프로젝트 루트에 있는 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 적합합니다. GitLab CI/CD를 통해 동적으로 생성된 응용 프로그램에 대해 API 퍼징을 실행하려면 응용 프로그램이 도메인을 environment_url.txt 파일에 유지하도록 설정하세요. API 퍼징은 해당 파일을 자동으로 구문 분석하여 스캔 대상을 찾습니다. 이에 대한 예제는 Auto DevOps CI YAML에서 볼 수 있습니다.

Postman 컬렉션 파일을 사용한 예제 .gitlab-ci.yml 파일:

   stages:
     - fuzz
   
   include:
     - template: API-Fuzzing.gitlab-ci.yml
   
   variables:
     FUZZAPI_PROFILE: Quick-10
     FUZZAPI_POSTMAN_COLLECTION: postman-collection_serviceA.json
     FUZZAPI_TARGET_URL: http://test-deployment/

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

첫 번째 스캔 실행.
인증 추가.
잘못된 양성 처리 방법.

API 퍼징 구성 옵션의 자세한 내용은 사용 가능한 CI/CD 변수을 참조하세요.

Postman 변수

GitLab 15.1에서 Postman 환경 파일 형식을 지원하기 시작했습니다. (소개됨)
여러 변수 파일을 지원하기 시작했습니다. (소개됨)
Postman 변수 스코프인 Global 및 Environment을 지원하기 시작했습니다. (소개됨)

Postman 클라이언트의 변수

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

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

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

Postman은 멋진 UX 경험을 제공하는 기본 클라이언트 도구에서 스크립트를 사용하여 API를 테스트하고, 보조 요청을 트리거하는 복잡한 컬렉션을 만들며 중간에 변수를 설정할 수 있는 더 복잡한 생태계로 성장했습니다. Postman 생태계의 모든 기능이 지원되는 것은 아닙니다. 예를 들어, 스크립트는 지원되지 않습니다. Postman 지원의 주된 중점은 Postman 클라이언트에서 사용되는 Postman 콜렉션 정의와 해당 워크스페이스, 환경, 그리고 컬렉션 자체에 정의된 변수를 가져오는 것입니다.

Postman은 다양한 스코프에서 변수를 생성할 수 있습니다. 각 스코프는 Postman 도구에서 다른 수준의 가시성을 갖습니다. 예를 들어, 워크스페이스 전체에서 볼 수 있는 전역 환경 스코프를 만들 수 있습니다. 또한 특정 환경 스코프에서만 볼 수 있고 해당 환경이 사용되는 경우에만 사용될 수 있는 스코프를 만들 수 있습니다. 일부 스코프는 항상 사용할 수 있는 것은 아닙니다. 예를 들어, Postman 생태계에서 Postman 클라이언트에서 요청을 생성할 수 있지만 로컬 스코프를 갖지 않습니다. 하지만 테스트 스크립트는 따로 스코프를 갖습니다.

Postman의 변수 스코프는 복잡한 주제일 수 있으며 모든 사용자가 친숙하지는 않을 수 있습니다. 진행하기 전에 반드시 Postman 설명서의 변수 스코프를 읽을 것을 강력히 권장합니다.

위에서 언급했듯이 다양한 변수 스코프가 있으며 각각의 목적에 맞게 사용되어 Postman 문서에 더 많은 유연성을 제공할 수 있습니다. Postman 설명서에 따르면 변수 값에 대해 계산되는 중요한 내용이 있습니다.

동일한 이름의 변수가 두 가지 다른 스코프에서 선언된 경우, 가장 좁은 스코프에 저장된 값이 사용됩니다. 예를 들어, 전역 변수인 username과 로컬 변수인 username이 있는 경우 요청 실행 시 로컬 값이 사용됩니다.

다음은 Postman 클라이언트 및 API Fuzzing에서 지원되는 변수 스코프에 대한 요약입니다:

Global Environment (Global) 스코프는 워크스페이스 전체에서 사용할 수 있는 미리 정의된 특별한 환경입니다. Postman 클라이언트를 통해 전역 환경을 JSON 파일로 내보낼 수 있으며 이는 API Fuzzing에서 사용할 수 있습니다.
환경 스코프는 Postman 클라이언트에서 사용자가 생성한 변수 그룹입니다. Postman 클라이언트는 전역 환경과 함께 단일 활성 환경을 지원합니다. 활성 사용자가 생성한 환경에 정의된 변수는 전역 환경에 정의된 변수보다 우선합니다. Postman 클라이언트를 통해 환경을 JSON 파일로 내보낼 수 있으며 이는 API Fuzzing에서 사용할 수 있습니다.
컬렉션 스코프는 주어진 컬렉션에 선언된 변수 그룹입니다. 컬렉션 변수는 해당 컬렉션 및 중첩된 요청 또는 컬렉션에서 사용할 수 있습니다. 컬렉션 스코프에 정의된 변수는 전역 환경 스코프 및 환경 스코프보다 우선하며 Postman 클라이언트로 하나 이상의 컬렉션을 JSON 파일로 내보낼 수 있으며 선택된 컬렉션, 요청 및 컬렉션 변수가 포함된 이 파일을 API Fuzzing에서 사용할 수 있습니다.
API Fuzzing 스코프는 API Fuzzing에서 추가된 새로운 스코프로, 다른 지원되는 스코프에서 정의된 변수를 추가로 제공하거나 재정의할 수 있게 합니다. 이 스코프는 Postman에서 지원되지 않습니다. API Fuzzing 스코프 변수는 사용자 정의 JSON 파일 형식을 사용하여 제공됩니다.
- 환경 또는 컬렉션에서 정의된 값을 재정의
- 스크립트에서 정의된 변수 정의
- 지원되지 않는 _데이터 스코프_에서 데이터 단일 행 정의
데이터 스코프는 이름과 값이 JSON 또는 CSV 파일에서 온 변수 그룹입니다. Postman 컬렉션 실행기인 Newman 또는 Postman Collection Runner가 JSON 또는 CSV 파일의 항목 수만큼 컬렉션에서 요청을 실행합니다. 이러한 변수의 좋은 사용 사례는 Postman에서 스크립트를 사용하여 테스트를 자동화하는 것입니다. API Fuzzing는 CSV 또는 JSON 파일에서 데이터를 읽는 것을 지원하지 않습니다.
로컬 스코프는 Postman 스크립트에서 정의된 변수입니다. API Fuzzing는 Postman 스크립트와 이에 따른 변수를 지원하지 않습니다. 그럼에도 불구하고 지원되는 스코프 중 하나에 해당 변수를 정의함으로써 스크립트로 정의된 변수에 값을 제공할 수 있습니다.

모든 스코프가 API Fuzzing에서 지원되는 것은 아니며 스크립트에서 정의된 변수도 지원되지 않습니다. 다음 표는 가장 포괄적인 스코프에서 가장 좁은 스코프로 정렬되어 있습니다.

스코프	Postman	API Fuzzing	Comment
전역 환경	Yes	Yes	특별한 미리 정의된 환경
환경	Yes	Yes	사용자가 생성한 이름 있는 환경
컬렉션	Yes	Yes	사용자의 Postman 컬렉션에 정의된 변수
API Fuzzing 스코프	No	Yes	API Fuzzing에서 추가된 사용자 정의 스코프
데이터	Yes	No	CSV 또는 JSON 형식의 외부 파일
로컬	Yes	No	스크립트에서 정의된 변수

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

Postman Client에서의 내보내기

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

서로 다른 지원 범위에서 변수를 내보내는 자세한 내용은 다음에서 확인하세요:

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

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

이 예제에서는 API Fuzzing 범위에서 base_url 및 token 두 변수를 정의합니다:

{
  "base_url": "http://127.0.0.1/",
  "token": "토큰 84816165151"
}

API Fuzzing에서 범위 사용하기

글로벌, 환경, 컬렉션, GitLab API Fuzzing_과 같은 범위는 GitLab 15.1부터 지원됩니다. GitLab 15.0 및 이전 버전은 _컬렉션, GitLab API Fuzzing 범위만 지원합니다.

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

범위	제공 방법
전역 환경	FUZZAPI_POSTMAN_COLLECTION_VARIABLES
환경	FUZZAPI_POSTMAN_COLLECTION_VARIABLES
컬렉션	FUZZAPI_POSTMAN_COLLECTION
API Fuzzing 범위	FUZZAPI_POSTMAN_COLLECTION_VARIABLES
데이터	지원되지 않음
로컬	지원되지 않음

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

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

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

정의되지 않은 Postman 변수

API Fuzzing 엔진은 Postman 컬렉션 파일에서 필요한 변수 참조를 찾을 수 없는 경우가 있습니다. 일부 경우에 해당하는 것은 다음과 같습니다:

데이터 또는 로컬 범위 변수를 사용하고 있고, 이들 범위가 API Fuzzing에서 지원되지 않습니다. 따라서, 이 변수들의 값이 API Fuzzing 범위를 통해 제공되지 않은 경우 데이터 및 로컬 범위 변수의 값은 정의되지 않습니다.
변수 이름이 잘못 입력되어 정의된 변수와 일치하지 않는 경우.
Postman Client가 API Fuzzing에서 지원하지 않는 새로운 동적 변수를 지원합니다.

가능한 경우, API Fuzzing은 정의되지 않은 변수를 처리할 때 Postman Client의 동일한 동작을 따릅니다. 변수 참조 문자열은 그대로 유지되며 텍스트가 대체되지 않습니다. 지원되지 않는 동적 변수에도 동일한 동작이 적용됩니다.

예를 들어, Postman 컬렉션의 요청 정의가 {{full_url}} 변수를 참조하고 해당 변수를 찾을 수 없는 경우, 해당 변수 참조 문자열은 그대로 유지되며 값은 {{full_url}}로 남습니다.

동적 Postman 변수

다양한 범위 수준에서 사용자가 정의할 수 있는 변수 외에도, Postman에는 동적 변수라고 불리는 사전 정의된 변수 세트가 있습니다. 동적 변수는 이미 정의되어 있으며 이름 앞에 달러 기호($)가 붙습니다. 예를 들어, $guid와 같이요. 동적 변수는 일반 변수처럼 사용할 수 있으며, Postman Client에서 요청을 실행하는 동안 무작위 값을 생성합니다.

API Fuzzing과 Postman 간의 중요한 차이점은 API Fuzzing이 각 사용 중에 동일한 동적 변수에 대해 동일한 값을 반환한다는 것입니다. 이는 Postman Client의 동적 변수를 사용할 때마다 무작위 값을 반환하는 동작과는 다릅니다. 다시 말해, API Fuzzing은 동적 변수에 대해 정적 값을 사용하고, Postman은 각 동적 변수 사용 시 무작위 값을 반환합니다.

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

변수	값
`$guid`	`611c2e81-2ccb-42d8-9ddc-2d0bfa65c1b4`
`$isoTimestamp`	`2020-06-09T21:10:36.177Z`
… (중략) …	… (중략) …
`$timestamp`	`1562757107`

(postman.com으로부터의 외부 요청이며 번역 서버는 외부 인터넷에 액세스하지 않습니다)

예시: 전역 범위

이 예시에서, Postman 클라이언트에서 전역 범위가 global-scope.json으로 내보내지고 API Fuzzing을 통해 FUZZAPI_POSTMAN_COLLECTION_VARIABLES 구성 변수를 통해 제공됩니다.

FUZZAPI_POSTMAN_COLLECTION_VARIABLES 사용 예시:

stages:
     - fuzz

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

variables:
  FUZZAPI_PROFILE: Quick-10
  FUZZAPI_POSTMAN_COLLECTION: postman-collection.json
  FUZZAPI_POSTMAN_COLLECTION_VARIABLES: global-scope.json
  FUZZAPI_TARGET_URL: http://test-deployment/

예시: 환경 범위

이 예시에서, Postman 클라이언트에서 환경 범위가 environment-scope.json으로 내보내지고 API Fuzzing을 통해 FUZZAPI_POSTMAN_COLLECTION_VARIABLES 구성 변수를 통해 제공됩니다.

FUZZAPI_POSTMAN_COLLECTION_VARIABLES 사용 예시:

stages:
  - fuzz

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

variables:
  FUZZAPI_PROFILE: Quick
  FUZZAPI_POSTMAN_COLLECTION: postman-collection.json
  FUZZAPI_POSTMAN_COLLECTION_VARIABLES: environment-scope.json
  FUZZAPI_TARGET_URL: http://test-deployment/

예시: 컬렉션 범위

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

FUZZAPI_POSTMAN_COLLECTION 사용 예시:

stages:
  - fuzz

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

variables:
  FUZZAPI_PROFILE: Quick
  FUZZAPI_POSTMAN_COLLECTION: postman-collection.json
  FUZZAPI_TARGET_URL: http://test-deployment/
  FUZZAPI_POSTMAN_COLLECTION_VARIABLES: variable-collection-dictionary.json

예시: API Fuzzing 범위

API Fuzzing 범위는 두 가지 주요 목적으로 사용되며, API Fuzzing에서 지원되지 않는 데이터 및 로컬 범위 변수를 정의하고, 다른 범위에서 정의된 변수의 값을 변경합니다. API Fuzzing 범위는 FUZZAPI_POSTMAN_COLLECTION_VARIABLES 구성 변수를 통해 제공됩니다.

FUZZAPI_POSTMAN_COLLECTION_VARIABLES 사용 예시:

stages:
  - fuzz

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

variables:
  FUZZAPI_PROFILE: Quick
  FUZZAPI_POSTMAN_COLLECTION: postman-collection.json
  FUZZAPI_POSTMAN_COLLECTION_VARIABLES: api-fuzzing-scope.json
  FUZZAPI_TARGET_URL: http://test-deployment/

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

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

예시: 다중 범위

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

전역_ 범위를 내보냅니다 : global-scope.json
환경_ 범위를 내보냅니다 : environment-scope.json
컬렉션 범위를 포함하는 Postman Collection을 postman-collection.json로 내보냅니다

Postman Collection은 FUZZAPI_POSTMAN_COLLECTION 변수를 사용하여 제공되고, 다른 범위는 FUZZAPI_POSTMAN_COLLECTION_VARIABLES를 사용하여 제공됩니다. API Fuzzing은 각 파일에서 제공된 데이터를 사용하여 제공된 파일이 어떤 범위와 일치하는지 식별할 수 있습니다.

stages:
  - fuzz

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

variables:
  FUZZAPI_PROFILE: Quick
  FUZZAPI_POSTMAN_COLLECTION: postman-collection.json
  FUZZAPI_POSTMAN_COLLECTION_VARIABLES: global-scope.json,environment-scope.json
  FUZZAPI_TARGET_URL: http://test-deployment/

예시: 변수 값 변경

내보낸 범위를 사용할 때, 경우에 따라 변수의 값은 API Fuzzing과 사용하기 위해 변경되어야 하는 경우가 많습니다. 예를 들어, 컬렉션 범위 변수에는 api_version이라는 변수가 v2라는 값으로 포함되어 있을 수 있지만, 테스트에는 v1의 값이 필요할 수 있습니다. 내보낸 컬렉션을 수정하여 값 변경을 하지 않고, API Fuzzing 범위를 사용하여 값을 변경할 수 있습니다. API Fuzzing 범위는 다른 모든 범위보다 우선됩니다.

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

API Fuzzing 범위는 FUZZAPI_POSTMAN_COLLECTION_VARIABLES 구성 변수를 통해 제공됩니다. 그러나 먼저 파일을 생성해야 합니다. 파일 api-fuzzing-scope.json은 사용자 정의 JSON 파일 형식을 사용합니다. 이 JSON은 속성에 대한 키-값 쌍으로 구성된 객체입니다. 키는 변수의 이름이고, 값은 변수의 값입니다. 예를 들어:

{
  "api_version": "v1"
}

저희 CI 정의:

stages:
  - fuzz

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

variables:
  FUZZAPI_PROFILE: Quick
  FUZZAPI_POSTMAN_COLLECTION: postman-collection.json
  FUZZAPI_POSTMAN_COLLECTION_VARIABLES: api-fuzzing-scope.json
  FUZZAPI_TARGET_URL: http://test-deployment/

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

수출된 범위를 사용할 때에는 종종 변수의 값을 API Fuzzing에 사용하려면 변경해야 할 수 있습니다. 예를 들어 environment 범위에는 api_version이라는 변수가 v2의 값을 가지고 있지만, 테스트에는 v1의 값을 필요로 할 때, 수출된 파일을 수정하여 값을 변경하는 대신에 API Fuzzing 범위를 사용할 수 있습니다. 이는 API Fuzzing 범위가 모든 다른 범위보다 우선시되기 때문에 작동합니다.

이 예시에서는 global 범위, environment 범위, collection 범위, 그리고 API Fuzzing 범위가 구성되어 있습니다. 첫 번째 단계는 각각의 범위를 내보내고 만드는 것입니다.

global 범위를 내보내기로 global-scope.json이라는 이름으로
environment 범위를 내보내기로 environment-scope.json이라는 이름으로
collection 범위를 포함하는 Postman 컬렉션을 postman-collection.json이라는 이름으로 내보내기

API Fuzzing 범위는 사용자 정의 JSON 파일 형식을 사용하여 api-fuzzing-scope.json이라는 파일을 만들어 사용됩니다. 이 JSON 파일은 속성을 위한 키-값 쌍으로 이뤄진 객체입니다. 키는 변수의 이름이고, 값은 변수의 값을 나타냅니다. 예를 들면:

{
  "api_version": "v1"
}

Postman 컬렉션은 FUZZAPI_POSTMAN_COLLECTION 변수를 사용하여 제공되고, 다른 범위는 FUZZAPI_POSTMAN_COLLECTION_VARIABLES를 사용하여 제공됩니다. API Fuzzing은 각 파일에서 제공된 데이터를 사용하여 일치하는 범위를 식별할 수 있습니다.

stages:
  - fuzz

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

variables:
  FUZZAPI_PROFILE: Quick
  FUZZAPI_POSTMAN_COLLECTION: postman-collection.json
  FUZZAPI_POSTMAN_COLLECTION_VARIABLES: global-scope.json,environment-scope.json,api-fuzzing-scope.json
  FUZZAPI_TARGET_URL: http://test-deployment/

첫 번째 스캔 실행하기

정확하게 구성된 경우, CI/CD 파이프라인에는 fuzz 단계와 apifuzzer_fuzz 또는 apifuzzer_fuzz_dnd 작업이 포함됩니다. 작업은 잘못된 구성이 제공될 때만 실패합니다. 일반적인 운영 중에도, 작업은 항상 성공합니다.

결함은 Security 파이프라인 탭에 스위트 이름으로 표시됩니다. 리포지터리의 기본 브랜치에 대해 테스트하는 경우, 퍼징 결함은 또한 Security and Compliance의 취약점 보고서 페이지에 표시됩니다.

신고된 결함의 과도한 수를 방지하기 위해 API 퍼징 스캐너는 보고하는 결함의 수를 제한합니다.

퍼징 결함 보기

API Fuzzing 분석기는 JSON 보고서를 생성하고 사용하여 결함을 GitLab 취약점 화면에 채우는 데 사용합니다. 퍼징 결함은 심각도가 알 수 없는 취약점으로 표시됩니다.

API Fuzzing이 찾는 결함은 매뉴얼 조사가 필요하며 특정 취약점 유형과 관련되지 않습니다. 이러한 결함은 보안 문제인지, 수정해야 하는지를 결정하기 위해 조사가 필요합니다. 잘못된 양성 결과 처리에 대해서는 잘못된 양성 결과 처리를 참조하십시오.

API Fuzzing 취약점 세부 정보 보기

GitLab 13.7에서 도입되었습니다.

API Fuzzing에 의해 검출된 결함은 실제 웹 애플리케이션에서 발생하며, 취약성 여부를 결정하기 위해 매뉴얼으로 조사해야 합니다. 퍼징 결함은 알 수 없는 심각도의 취약점으로 포함됩니다. 퍼징 결함의 세부 정보를 살펴보기 위해 다음 단계를 따르십시오:

프로젝트 또는 Merge Request에서 결함을 볼 수 있습니다:
- 프로젝트에서 프로젝트의 Secure > Vulnerability report 페이지로 이동합니다. 이 페이지는 기본 브랜치의 모든 취약점을 표시합니다.
- Merge Request에서 Merge Request의 Security 섹션으로 이동하여 Expand 버튼을 선택합니다. API Fuzzing 결함은 API Fuzzing detected N potential vulnerabilities이라고 표시된 섹션에서 사용할 수 있습니다. 제목을 선택하여 결함 세부 정보를 표시합니다.

결함 제목을 선택하여 결함의 세부 정보를 표시합니다. 아래 표에서 이러한 세부 정보를 설명합니다.

필드	설명
설명	수정 내용을 포함한 결함에 대한 설명
프로젝트	취약점이 검출된 네임스페이스 및 프로젝트
메소드	취약점을 검출하는 데 사용된 HTTP 메소드
URL	취약점이 검출된 URL
요청	결함을 유발한 HTTP 요청
수정되지 않은 응답	수정되지 않은 요청에서의 응답. 일반적으로 작동 중인 응답입니다.
실제 응답	퍼징된 요청에서 수신된 응답
증거	결함이 발생했음을 확인한 방법
식별자	이 결함을 찾기 위해 사용된 퍼징 체크
심각도	결과의 심각도는 항상 알 수 없음입니다.
스캐너 유형	테스트를 수행하는 데 사용된 스캐너

보안 대시보드

퍼징 결함은 심각도가 알 수 없는 취약점으로 표시됩니다. 보안 대시보드는 그룹, 프로젝트 및 파이프라인의 모든 보안 취약점에 대한 개요를 얻는 좋은 장소입니다. 자세한 내용은 보안 대시보드 문서를 참조하십시오.

취약점과 상호 작용하기

퍼징 결함은 심각도가 알 수 없는 취약점으로 표시됩니다. 결함이 발견된 경우 상호 작용할 수 있습니다. 결함 처리에 대해 자세히 읽어보세요.

잘못된 양성 결과 처리

잘못된 양성 결과는 다음 두 가지 방법으로 처리할 수 있습니다:

잘못된 양성 결과 생성을 중지합니다. 이렇게 하면 해당 체크가 어떠한 결함도 생성하지 못하게 됩니다. 예제 체크로는 JSON 퍼징 체크 및 폼 바디 퍼징 체크가 있습니다.
퍼징 체크에는 잘못된 양성 결과가 식별될 때 감지하는 여러 방법이 있습니다. 이를 _Asserts_라고 합니다. Asserts는 중지하고 구성할 수도 있습니다. 예를 들어, API 퍼정 파저는 기본적으로 HTTP 상태 코드를 사용하여 실제 문제인지를 식별하는 데 도움을 주는데, 이를 끌 수 있습니다. API가 테스트 중에 500 오류를 반환하면 결함이 생성됩니다. 하지만 이는 항상 원하는 결과는 아니며, 일부 프레임워크는 자주 500 오류를 반환하기 때문에 원하지 않을 수 있습니다.

Check를 끄기

체크는 특정 유형의 테스트를 수행하며, 특정 구성 프로필에서 켜고 끌 수 있습니다. 기본 구성 파일에는 사용할 수 있는 여러 프로필이 정의되어 있습니다. 구성 파일의 프로필 정의에는 스캔 중 활성화된 모든 체크가 나열되어 있습니다. 특정 체크를 끄려면 구성 파일의 프로필 정의에서 해당 체크를 제거하면 됩니다. 프로필은 구성 파일의 Profiles 섹션에 정의되어 있습니다.

프로필 정의의 예:

Profiles:
  - Name: Quick-10
    DefaultProfile: Quick
    Routes:
      - Route: *Route0
        Checks:
          - Name: FormBodyFuzzingCheck
            Configuration:
              FuzzingCount: 10
              UnicodeFuzzing: true
          - Name: GeneralFuzzingCheck
            Configuration:
              FuzzingCount: 10
              UnicodeFuzzing: true
          - Name: JsonFuzzingCheck
            Configuration:
              FuzzingCount: 10
              UnicodeFuzzing: true
          - Name: XmlFuzzingCheck
            Configuration:
              FuzzingCount: 10
              UnicodeFuzzing: true

일반 퍼징 체크를 끄려면 다음과 같이 이 라인들을 제거할 수 있습니다:

- Name: GeneralFuzzingCheck
  Configuration:
    FuzzingCount: 10
    UnicodeFuzzing: true

이렇게 하면 다음과 같은 YAML이 생성됩니다:

- Name: Quick-10
  DefaultProfile: Quick
  Routes:
    - Route: *Route0
      Checks:
        - Name: FormBodyFuzzingCheck
          Configuration:
            FuzzingCount: 10
            UnicodeFuzzing: true
        - Name: JsonFuzzingCheck
          Configuration:
            FuzzingCount: 10
            UnicodeFuzzing: true
        - Name: XmlFuzzingCheck
          Configuration:
            FuzzingCount: 10
            UnicodeFuzzing: true

Check에 대한 어서션 끄기

어서션은 체크에 의해 생성된 테스트에서 결함을 감지합니다. 많은 체크가 로그 분석, 응답 분석 및 상태 코드와 같이 여러 어서션을 지원합니다. 결함을 찾으면 사용된 어서션이 제공됩니다. 기본적으로 켜져 있는 어서션을 확인하려면 구성 파일의 체크 기본 구성을 참조하세요. 이 섹션의 이름은 Checks입니다.

다음 예제는 FormBody Fuzzing Check를 보여줍니다:

Checks:
  - Name: FormBodyFuzzingCheck
    Configuration:
      FuzzingCount: 30
      UnicodeFuzzing: true
    Assertions:
      - Name: LogAnalysisAssertion
      - Name: ResponseAnalysisAssertion
      - Name: StatusCodeAssertion

여기에서 세 개의 어서션이 기본적으로 켜져 있는 것을 확인할 수 있습니다. 거짓 긍정의 일반적인 원인은 StatusCodeAssertion입니다. 이를 끄려면 구성 파일의 Profiles 섹션에서 해당 어서션의 구성을 수정하면 됩니다. 이 예제는 다른 두 어서션(LogAnalysisAssertion, ResponseAnalysisAssertion)만 제공합니다. 이것으로 FormBodyFuzzingCheck에서 StatusCodeAssertion을 사용하지 못하도록 합니다.

Profiles:
  - Name: Quick-10
    DefaultProfile: Quick
    Routes:
      - Route: *Route0
        Checks:
          - Name: FormBodyFuzzingCheck
            Configuration:
              FuzzingCount: 10
              UnicodeFuzzing: true
            Assertions:
              - Name: LogAnalysisAssertion
              - Name: ResponseAnalysisAssertion
          - Name: GeneralFuzzingCheck
            Configuration:
              FuzzingCount: 10
              UnicodeFuzzing: true
          - Name: JsonFuzzingCheck
            Configuration:
              FuzzingCount: 10
              UnicodeFuzzing: true
          - Name: XmlInjectionCheck
            Configuration:
              FuzzingCount: 10
              UnicodeFuzzing: true

Analyzer 활성화

Web API Fuzzing Configuration Form

UI에서 Web API Fuzzing 구성

OpenAPI Specification

OpenAPI 및 미디어 타입

OpenAPI Specification을 사용하여 Web API 퍼징 구성

HTTP Archive (HAR)

HAR 파일을 사용하여 Web API 퍼징 구성

GraphQL 스키마

GraphQL 엔드포인트 URL을 사용한 API Fuzzing 스캔

GraphQL 스키마 파일을 사용한 API Fuzzing

Postman 컬렉션

Postman 컬렉션 파일을 사용하여 웹 API 퍼징 구성

Postman 변수

Postman 클라이언트의 변수

Postman Client에서의 내보내기

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

API Fuzzing에서 범위 사용하기

정의되지 않은 Postman 변수

동적 Postman 변수

예시: 전역 범위

예시: 환경 범위

예시: 컬렉션 범위

예시: API Fuzzing 범위

예시: 다중 범위

예시: 변수 값 변경

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

첫 번째 스캔 실행하기

퍼징 결함 보기

API Fuzzing 취약점 세부 정보 보기

보안 대시보드

취약점과 상호 작용하기

잘못된 양성 결과 처리

Check를 끄기

Check에 대한 어서션 끄기

도움말

기능 사용 가능성과 제품 평가판

도움받기