• 웹 API 퍼징 구성 양식
  • UI에서 웹 API 퍼징 구성하기
• OpenAPI Specification
• OpenAPI 및 미디어 타입
  • 오픈API 사양으로 웹 API 퍼징 구성
• HTTP 아카이브 (HAR)
  • HAR 파일을 사용한 웹 API 퍼징 구성
• GraphQL 스키마
  • GraphQL 엔드포인트 URL을 사용한 API Fuzzing 스캔
  • GraphQL 스키마 파일을 사용한 API Fuzzing
• 포스트맨 컬렉션
  • 포스트맨 컬렉션 파일로 웹 API 모호성 구성
  • 포스트맨 변수
    • 포스트맨 클라이언트의 변수
    • Postman 클라이언트에서 내보내기
    • API Fuzzing 범위, 사용자 지정 JSON 파일 형식
    • API Fuzzing에 범위 사용
    • 정의되지 않은 Postman 변수
    • 동적 Postman 변수
    • 예: 전역 범위
    • 예: 환경 범위
    • 예: 컬렉션 범위
    • 예: API Fuzzing 범위
    • 예: 여러 범위
    • 예: 변수 값 변경
    • 예시: 다중 스코프에서 변수 값 변경하기
• 첫 번째 스캔 실행하기
• 퍼징 결함 보기
  • API 퍼징 결함의 세부 정보 보기
  • 보안 대시보드
  • 취약점 상호 작용
• 잘못된 긍정 처리
  • 검사 끄기
  • 검사의 단언 끄기

분석기 활성화

요구 사항:

• 다음 웹 API 유형 중 하나:
  • REST API
  • SOAP
  • GraphQL
  • 폼 본문, JSON 또는 XML
• 테스트할 API를 제공하기 위해 다음 자산 중 하나:
  • OpenAPI v2 또는 v3 API 정의
  • API 요청의 HTTP 아카이브(HAR)
  • Postman Collection v2.0 또는 v2.1

경고: 프로덕션 서버에서 퍼즈 테스트를 절대로 실행하지 마십시오. API가 수행할 수 있는 어떤 기능도 수행할 수 있을 뿐만 아니라 API에서 버그를 트리거할 수도 있습니다. 이는 데이터 수정 및 삭제와 같은 작업을 포함합니다. 퍼징은 테스트 서버에서만 실행하십시오.

웹 API 퍼징 활성화:

• .gitlab-ci.yml 파일에 API 퍼징 템플릿을 포함합니다.

• GitLab 13.10 이상에서 웹 API 퍼징 구성 양식을 사용합니다.

• 수동 구성 지침은 API 유형에 따라 해당 섹션을 참조하십시오:
  • OpenAPI Specification
  • GraphQL Schema
  • HTTP Archive (HAR)
  • Postman Collection
• 그렇지 않으면, 웹 API 퍼징 구성 양식을 참조하십시오.

GitLab 14.0 이상에서 API 퍼징 구성 파일은 귀하의 저장소 루트가 아닌 .gitlab 디렉토리에 있어야 합니다.

웹 API 퍼징 구성 양식

• GitLab 13.10에서 도입.

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

UI에서 웹 API 퍼징 구성하기

API Fuzzing 구성 스니펫 생성:

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

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

OpenAPI Specification

• OpenAPI Specification v3.0 지원이 도입되었습니다.
• YAML 형식을 사용하는 OpenAPI Specification 지원이 도입되었습니다.
• OpenAPI Specification v3.1 지원이 도입되었습니다.
• 미디어 타입 application/xml 생성 지원이 도입되었습니다.
• 미디어 타입 선택 지원이 도입되었습니다.

OpenAPI Specification (이전 Swagger Specification)은 REST API를 위한 API 설명 형식입니다. 이 섹션에서는 OpenAPI Specification을 사용하여 API 퍼징을 구성하는 방법을 보여줍니다. OpenAPI Specification은 파일 시스템 리소스 또는 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 퍼징은 나열된 미디어 타입을 확인하고 각 지원되는 미디어 타입에 대한 샘플 데이터를 생성하려고 시도합니다.

• 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는 유형 "/" [트리 "."] 서브타입 ["+" 접미어]* [";" 매개변수]의 조합입니다. 요청 생성 시 미디어 타입 필터링에서 매개변수는 고려되지 않습니다.

환경 변수 FUZZAPI_OPENAPI_ALL_MEDIA_TYPES 및 FUZZAPI_OPENAPI_MEDIA_TYPES를 사용하여 미디어 타입을 처리하는 방법을 결정할 수 있습니다. 이 설정은 서로 배타적입니다. 둘 다 활성화된 경우 API 퍼징은 오류를 보고합니다.

오픈API 사양으로 웹 API 퍼징 구성

GitLab에서 오픈API 사양으로 API 퍼징을 구성하려면:

1. .gitlab-ci.yml 파일에 fuzz 단계를 추가합니다.

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

3. FUZZAPI_PROFILE CI/CD 변수를 .gitlab-ci.yml 파일에 추가하여 프로필을 제공합니다. 프로필은 실행할 테스트의 양을 지정합니다. 선택한 프로필에 대해 Quick-10을 대체하세요. 자세한 내용은 API 퍼징 프로필을 참조하세요.

   variables:
     FUZZAPI_PROFILE: Quick-10
   

4. 오픈API 사양의 위치를 제공합니다. 사양을 파일 또는 URL로 제공할 수 있습니다. FUZZAPI_OPENAPI 변수를 추가하여 위치를 지정합니다.

5. 대상 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의 예시를 확인할 수 있습니다.

오픈API 사양을 사용한 .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 퍼징의 최소 구성입니다. 여기서부터 가능한 작업:

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

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

HTTP 아카이브 (HAR)

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

HAR 파일 생성 방법을 포함한 자세한 내용은 HTTP 아카이브 형식을 참조하세요.

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

HAR 파일을 사용한 웹 API 퍼징 구성

HAR 파일을 사용하여 API 퍼징을 구성하려면:

1. .gitlab-ci.yml 파일에 fuzz 단계를 추가합니다.

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

3. FUZZAPI_PROFILE CI/CD 변수를 .gitlab-ci.yml 파일에 추가하여 프로필을 제공합니다. 프로필은 실행할 테스트의 양을 지정합니다. 선택한 프로필에 대해 Quick-10을 대체하세요. 자세한 내용은 API 퍼징 프로필을 참조하세요.

   variables:
     FUZZAPI_PROFILE: Quick-10
   

4. HAR 사양의 위치를 제공합니다. 사양을 파일 또는 URL로 제공할 수 있습니다. URL 지원은 GitLab 13.10 및 이후에 도입되었습니다. FUZZAPI_HAR 변수를 추가하여 위치를 지정합니다.

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

   environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 유용합니다. GitLab CI/CD 파이프라인 중에 동적으로 생성된 앱에 대해 API 퍼징을 실행하려면 앱이 해당 도메인을 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 Fuzzing은 GraphQL 엔드포인트를 여러 가지 방법으로 테스트하는 것을 지원합니다.

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

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

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

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

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

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

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

2. GraphQL 엔드포인트 경로를 제공합니다. 예를 들어 /api/graphql를 추가하여 경로를 지정합니다.

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

   프로젝트 루트에 URL을 추가하는 것은 동적 환경에서 테스트하는 데 훌륭합니다. 자세한 내용은 문서의 동적 환경 솔루션 섹션을 참조하세요.

GraphQL 엔드포인트 URL을 사용한 예시 구성의 완전한 예시:

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 스키마 파일을 사용하려면 다음을 수행하세요:

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

2. GraphQL 엔드포인트 경로를 제공합니다. 예를 들어 /api/graphql를 추가하여 경로를 지정합니다.

3. GraphQL 스키마 파일의 위치를 제공합니다. 파일 경로나 URL로 위치를 제공할 수 있습니다.

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

   프로젝트 루트에 URL을 추가하는 것은 동적 환경에서 테스트하는 데 훌륭합니다. 자세한 내용은 문서의 동적 환경 솔루션 섹션을 참조하세요.

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

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을 사용한 예시 구성의 완전한 예시:

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의 최소 구성입니다. 여기서부터 다음을 수행할 수 있습니다:

• 첫 번째 스캔 실행.
• 인증 추가.
• 거짓 양성 처리.

포스트맨 컬렉션

포스트맨 API 클라이언트는 개발자와 테스터가 다양한 유형의 API를 호출하는 데 사용하는 인기있는 도구입니다. API 정의는 포스트맨 컬렉션 파일로 내보낼 수 있습니다API 모호성을 사용하기 위해. 내보내기할 때, 지원되는 버전인 포스트맨 컬렉션(v2.0 또는 v2.1)을 선택해야 합니다.

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

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

포스트맨 컬렉션 파일로 웹 API 모호성 구성

포스트맨 컬렉션 파일을 사용하여 API 모호성을 구성하려면 다음 단계를 따르세요:

1. .gitlab-ci.yml 파일에 fuzz 단계를 추가합니다.

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

3. FUZZAPI_PROFILE CI/CD 변수를 .gitlab-ci.yml 파일에 추가하여 프로필을 제공합니다. 프로필은 실행할 테스트의 수를 지정합니다. 선택한 프로필에 따라 Quick-10을 대체합니다. 자세한 내용은 API 모호성 프로필을 참조하세요.

   variables:
     FUZZAPI_PROFILE: Quick-10
   

4. 포스트맨 컬렉션 사양의 위치를 제공합니다. 파일 또는 URL로 사양을 제공할 수 있습니다. URL 지원은 GitLab 13.10부터 도입되었습니다. FUZZAPI_POSTMAN_COLLECTION 변수를 추가하여 위치를 지정합니다.

5. 대상 API 인스턴스의 기본 URL을 제공합니다. FUZZAPI_TARGET_URL 변수 또는 environment_url.txt 파일을 사용합니다.

   프로젝트 루트에 있는 environment_url.txt 파일에 URL을 추가하면 동적 환경에서 테스트하는 데 좋습니다. GitLab CI/CD 파이프라인 중에 동적으로 생성된 애플리케이션에 대해 API 모호성을 실행하려면 해당 앱이 도메인을 environment_url.txt 파일에 유지하도록 하면 됩니다. API 모호성은 해당 파일을 자동으로 구문 분석하여 스캔 대상을 찾습니다. Auto DevOps CI YAML 내의 예제를 확인할 수 있습니다.

포스트맨 컬렉션 파일을 사용하는 예시 .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 모호성을 위한 최소 구성입니다. 여기서부터 다음을 수행할 수 있습니다:

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

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

포스트맨 변수

• 포스트맨 환경 파일 형식 지원은 GitLab 15.1에서 도입되었습니다.
• 여러 변수 파일 지원은 GitLab 15.1에서 도입되었습니다.
• 포스트맨 변수 범위(Global 및 Environment) 지원은 GitLab 15.1에서 도입되었습니다.

포스트맨 클라이언트의 변수

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

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

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

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

포스트맨은 다양한 범위에서 변수를 생성할 수 있도록 합니다. 각 범위는 포스트맨 도구에서 다른 수준의 가시성을 갖습니다. 예를 들어, 전역 환경 범위에서 변수를 생성할 수 있는데 이는 모든 작업 정의 및 워크스페이스에서 볼 수 있습니다. 특정 환경 범위에서 변수를 생성할 수도 있는데 이는 해당 특정 환경이 선택되어 사용될 때에만 볼 수 있고 사용됩니다. 일부 범위는 항상 사용할 수 있는 것은 아니며, 예를 들어 포스트맨 생태계에서 포스트맨 클라이언트에서 요청을 생성할 수 있지만, 이러한 요청에는 로컬 범위가 없습니다.

포스트맨 변수 범위는 복잡한 주제일 수 있으며, 모든 사람이 이에 익숙하지는 않습니다. 계속 진행하기 전에 조언드리고 싶은 것은 Postman 문서의 변수 범위를 읽는 것을 강력히 추천합니다.

위에서 언급한 것처럼 각각의 변수 범위는 목적을 갖고 있으며 포스트맨 문서에 따르면 변수의 값이 어떻게 계산되는지에 대한 중요한 참고사항이 있습니다:

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

다음은 포스트맨 클라이언트와 API 모호성에서 지원되는 변수 범위의 요약입니다:

• 전역 환경(Global) 범위는 워크스페이스 전체에서 사용할 수 있는 특별하게 정의된 기본 환경입니다. 포스트맨 클라이언트는 전역 환경을 JSON 파일로 내보낼 수 있으며, 이는 API 모호성에서 사용할 수 있습니다.
• 환경(Environment) 범위는 포스트맨 클라이언트에서 사용자가 생성한 변수 그룹의 이름입니다. 포스트맨 클라이언트는 전역 환경과 함께 하나의 활성 환경을 지원합니다. 사용자가 생성한 환경에서 정의된 변수가 전역 환경에 정의된 변수보다 우선권을 가집니다. 포스트맨 클라이언트는 환경을 JSON 파일로 내보낼 수 있으며, 이는 API 모호성에서 사용할 수 있습니다.
• 컬렉션(Collection) 범위은 주어진 컬렉션에 선언된 변수 그룹입니다. 컬렉션 변수는 해당 컬렉션과 해당 컬렉션 내부 요청이나 컬렉션에 사용할 수 있습니다. 컬렉션 범위에서 정의된 변수가 전역 환경 범위와 환경 범위보다 우선권을 가집니다. 포스트맨 클라이언트는 하나 이상의 컬렉션, 요청 및 컬렉션 변수를 포함하는 JSON 파일을 내보낼 수 있습니다.
• API 모호성 범위는 API 모호성에서 사용자가 추가 변수를 제공하거나 다른 지원되는 범위에서 정의된 변수를 재정의할 수 있도록하는 새로운 범위입니다. 이 범위는 포스트맨에서 지원되지 않습니다. API 모호성 범위 변수는 사용자 정의 JSON 파일 형식을 사용하여 제공됩니다.
• 데이터(Data) 범위는 JSON 또는 CSV 파일에서 이름과 값을 가져오는 변수 그룹입니다. 포스트맨 컬렉션 실행 프로그램(예: Newman 또는 포스트맨 컬렉션 러너)은 JSON 또는 CSV 파일에 있는 항목의 수만큼 컬렉션의 요청을 실행합니다. 이러한 변수의 좋은 사용 사례는 포스트맨에서 스크립트를 사용하여 테스트를 자동화하는 것입니다. API 모호성은 CSV 또는 JSON 파일에서 데이터를 읽지 않습니다.
• 로컬(Local) 범위는 포스트맨 스크립트에서 정의된 변수입니다. API 모호성은 포스트맨 스크립트와 이에 따른 변수를 지원하지 않습니다. 그러나 사용자는 지원되는 범위 중 하나에 정의하여 스크립트로 정의된 변수에 값들을 제공할 수 있습니다.

API 모호성에서 모든 범위와 스크립트에서 정의된 변수가 지원되는 것은 아니며, 스크립트에서 정의된 변수도 지원되지 않습니다. 다음 표는 가장 넓은 범위부터 가장 좁은 범위로 정렬되어 있습니다.

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

• 컬렉션 변수 정의하기
• 환경 변수 정의하기
• 전역 변수 정의하기

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

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

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

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

• 컬렉션 내보내기
• 환경 내보내기
• 글로벌 환경 다운로드

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

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

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

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

API Fuzzing에 범위 사용

범위: 글로벌, 환경, 컬렉션, GitLab API Fuzzing_은 GitLab 15.1 및 이후에서 지원됩니다. GitLab 15.0 및 이전 버전은 _컬렉션 및 GitLab API Fuzzing 범위만 지원합니다.

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

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

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

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

• 내보낸 글로벌 환경
• 내보낸 환경
• API Fuzzing 사용자 지정 JSON 형식

정의되지 않은 Postman 변수

API Fuzzing 엔진에서 사용 중인 Postman 컬렉션 파일이 모든 변수 참조를 찾지 못할 수 있습니다. 다음과 같은 경우가 있을 수 있습니다:

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

가능한 경우, API Fuzzing은 정의되지 않은 변수를 다룰 때 Postman 클라이언트와 동일한 동작을 따릅니다. 변수 참조의 텍스트는 그대로 유지되며 텍스트가 대체되지 않습니다. 같은 동작은 지원되지 않는 동적 변수에도 적용됩니다.

예를 들어, Postman 컬렉션의 요청 정의가 변수 {{full_url}}을 참조하고 해당 변수를 찾을 수 없는 경우 해당 값은 {{full_url}}로 유지됩니다.

동적 Postman 변수

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

API Fuzzing과 Postman 간의 중요한 차이점은 API Fuzzing이 같은 동적 변수를 사용하여 각 사용에 대해 동일한 값을 반환하는 것입니다. 이는 Postman 클라이언트 동작과 다르며, Postman은 같은 동적 변수 사용시 매번 무작위 값을 반환합니다. 다시 말하면, API Fuzzing은 동적 변수에 대해 정적 값, Postman은 무작위 값을 사용합니다.

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

예: 전역 범위

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

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으로 내보내어 FUZZAPI_POSTMAN_COLLECTION_VARIABLES 구성 변수를 통해 API Fuzzing에 제공됩니다.

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 Collection 파일에 포함되어 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 퍼징에 사용되는 값을 변경해야 하는 경우가 많습니다. 예를 들어, 환경 스코프에는 api_version이라는 변수가 v2의 값으로 포함되어 있을 수 있지만, 테스트에는 v1의 값을 필요로 할 수 있습니다. 내보낸 파일을 수정하여 값을 변경하는 대신 API 퍼징 스코프를 사용할 수 있습니다. 이는 API 퍼징 스코프가 모든 다른 스코프보다 우선시되기 때문에 작동합니다.

이 예에서는 글로벌 스코프, 환경 스코프, 컬렉션 스코프 및 API 퍼징 스코프가 구성됩니다. 첫 번째 단계는 다양한 스코프를 내보내고 생성하는 것입니다.

• 글로벌 스코프를 내보냅니다 : global-scope.json으로
• 환경 스코프를 내보냅니다 : environment-scope.json으로
• 컬렉션 스코프를 포함하는 Postman 컬렉션을 postman-collection.json으로 내보냅니다.

API 퍼징 스코프를 생성하기 위해 사용자 지정 JSON 파일 형식을 사용하여 api-fuzzing-scope.json이라는 파일을 생성합니다. 이 JSON은 속성에 대한 키-값 쌍으로 이루어진 객체입니다. 키는 변수의 이름이고 값은 변수의 값입니다. 예를 들어:

{
  "api_version": "v1"
}

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

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 작업을 포함합니다. 작업은 잘못된 구성이 제공된 경우에만 실패합니다. 일반적인 운영 중에도 작업은 항상 성공합니다. 심각한 결함이 발견되더라도 항상 성공합니다.

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

보고된 결함의 수를 줄이기 위해 API 퍼징 스캐너는 보고하는 결함 수를 제한합니다.

퍼징 결함 보기

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

API 퍼징이 발견하는 결함은 수동으로 조사되어, 특정한 취약점 유형과 관련되어 있지 않습니다. 이러한 결함은 보안 문제인지, 해결해야 할 문제인지 여부를 결정하기 위해 조사가 필요합니다. 잘못된 긍정적인 결과를 처리하기 문서에서는 한도를 설정하는 데 필요한 구성 변경에 대한 정보를 제공합니다.

API 퍼징 결함의 세부 정보 보기

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

API 퍼징에 의해 감지된 결함은 라이브 웹 애플리케이션에서 발생하며, 취약점인지 여부를 결정하기 위해 수동으로 조사되어야 합니다. 퍼징 결함은 알 수 없음의 심각도를 가진 취약점으로 포함됩니다. 퍼징 결함을 조사하는 것을 용이하게 하기 위해, 수정된 HTTP 메시지에 대한 자세한 정보 및 수정 사항 설명이 제공됩니다.

퍼징 결함의 세부 정보를 보려면 다음 단계를 따르세요:

1. 프로젝트나 머지 요청에서 결함을 볼 수 있습니다:

   • 프로젝트에서 프로젝트의 보안 > 취약점 보고서 페이지로 이동합니다. 이 페이지에는 기본 브랜치에서만 모든 취약점이 표시됩니다.
   • 머지 요청에서 머지 요청의 보안 섹션으로 이동하여 확장 버튼을 선택합니다. API 퍼징 결함은 API 퍼징이 가능한 N개의 잠재적인 취약점 감지됨이라고 표시된 섹션에서 사용할 수 있습니다. 제목을 선택하여 결함 세부 정보를 표시합니다.

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

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

보안 대시보드

Fuzzing faults는 심각도가 알 수 없음(unknown)인 취약점으로 나타납니다. 보안 대시보드는 그룹, 프로젝트 및 파이프라인의 모든 보안 취약점을 개요로 파악할 수 있는 좋은 장소입니다. 자세한 정보는 보안 대시보드 문서를 참조하세요.

취약점 상호 작용

Fuzzing faults는 심각도가 알 수 없는 취약점으로 나타납니다. 한 번 결함을 발견하면 상호 작용할 수 있습니다. 취약점에 대한 자세한 정보는 취약점 해결 방법을 참조하세요.

잘못된 긍정 처리

잘못된 긍정은 두 가지 방법으로 처리할 수 있습니다:

• 잘못된 긍정을 생성하는 검사를 끄기. 이렇게 하면 검사가 어떤 결함도 생성하지 않습니다. 예를 들어, JSON Fuzzing Check, Form Body Fuzzing Check 등이 있습니다.
• Fuzzing 검사에는 결함이 식별될 때 사용하는 여러 방법이 있습니다. 이를 _Asserts_라고 합니다. Asserts도 끌 수도 있고 구성할 수도 있습니다. 예를 들어, API fuzzer는 기본적으로 HTTP 상태 코드를 사용하여 언제 실제 문제인지 식별합니다. API가 테스트 중에 500 에러를 반환하면 이는 결함을 생성합니다. 이는 항상 원하는 것은 아니기 때문에 일부 프레임워크에서는 종종 500 에러를 반환합니다.

검사 끄기

검사는 특정 유형의 테스트를 수행하며 특정 구성 프로필에 대해 켜거나 끌 수 있습니다. 기본 구성 파일은 사용할 수 있는 여러 프로필을 정의합니다. 구성 파일의 프로필 정의에는 스캔 중에 활성화된 모든 검사가 나열됩니다. 특정 검사를 끄려면 구성 파일의 프로필 정의에서 해당 검사를 제거하세요. 프로필은 구성 파일의 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

결과는 다음과 같습니다:

- 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

검사의 단언 끄기

단언은 검사가 생성한 테스트의 결함을 감지합니다. 많은 검사가 Log Analysis, Response Analysis 및 Status Code와 같이 여러 단언을 지원합니다. 결함을 찾으면 사용된 단언이 제공됩니다. 기본 설정에서 켜져 있는 단언을 확인하려면 구성 파일의 Checks 기본 구성을 확인하세요. 이 섹션의 이름은 Checks입니다.

이 예시는 FormBody Fuzzing Check를 보여줍니다:

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

여기서 세 가지 단언이 기본적으로 켜져 있습니다. 잘못된 긍정의 일반적인 원인은 StatusCodeAssertion입니다. 이를 끄려면 구성 파일의 Profiles 섹션에서 해당 이의 구성을 수정하세요. 이 예시는 FormBodyFuzzingCheck가 StatusCodeAssertion을 사용하지 않도록 설정하는 것을 보여줍니다 (LogAnalysisAssertion, ResponseAnalysisAssertion만 사용):

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