Web API 퍼징 구성 양식
- UI에서 Web API 퍼징 구성
OpenAPI Specification
OpenAPI 및 미디어 유형
- OpenAPI 사양으로 Web API 퍼징 구성
HTTP 아카이브 (HAR)
- HAR 파일로 웹 API 퍼징 구성
GraphQL 스키마
- GraphQL 엔드포인트 URL로 API 퍼징 스캔 구성
- GraphQL 스키마 파일로 API 퍼징
포스트맨 컬렉션
- 포스트맨 컬렉션 파일로 웹 API 퍼징 구성
- 포스트맨 변수
첫 번째 스캔 실행
Fuzzing 결함 보기
거짓 긍정적 처리
- Check 끄기
- Check을 위한 Assertion 끄기

분석기 활성화

전제 조건:

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

웹 API 퍼징을 활성화하려면 Web API 퍼징 구성 양식을 사용하십시오.

매뉴얼 구성 지침은 각 API 유형에 따라 해당 섹션을 참조하십시오:
그렇지 않은 경우, Web API 퍼징 구성 양식을 참조하십시오.

API 퍼징 구성 파일은 리포지터리의 .gitlab 디렉터리에 있어야 합니다.

Web API 퍼징 구성 양식

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

UI에서 Web API 퍼징 구성

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

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

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

OpenAPI Specification

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

API 퍼징은 OpenAPI 문서를 사용하여 요청 본문을 생성합니다. 요청 본문이 필요한 경우 본문 생성은 다음과 같은 본문 유형으로 제한됩니다:

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

OpenAPI 및 미디어 유형

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

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

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

환경 변수 FUZZAPI_OPENAPI_ALL_MEDIA_TYPES은 주어진 동작에 대한 요청 생성 시 하나의 대신 모든 지원되는 미디어 유형을 사용할 것인지 여부를 지정합니다. 환경 변수 FUZZAPI_OPENAPI_ALL_MEDIA_TYPES가 어떤 값이든 설정되어있을 때 API 퍼징은 주어진 동작에 대해 하나 대신 모든 지원되는 미디어 유형을 생성하려고 합니다. 이렇게하면 각 제공된 미디어 유형에 대해 반복하여 테스트하기 때문에 테스트 세션이 더 오래 걸리게됩니다.

대조적으로 FUZZAPI_OPENAPI_MEDIA_TYPES 변수는 각각 테스트하는 미디어 유형 디렉터리을 제공하는 데 사용됩니다. 여러 미디어 유형을 제공하면 각 선택 된 미디어 유형에 대해 테스트가 반복되므로 테스트에 더 오랜 시간이 걸립니다. 환경 변수 FUZZAPI_OPENAPI_MEDIA_TYPES를 미디어 유형 디렉터리으로 설정하면 생성중인 요청에 포함되는 것은 나열된 미디어 유형뿐입니다.

FUZZAPI_OPENAPI_MEDIA_TYPES에서 여러 미디어 유형은 콜론(:)으로 구분해야합니다. 예를들어 요청 생성을 application/x-www-form-urlencoded 및 multipart/form-data 미디어 유형으로 제한하려면 FUZZAPI_OPENAPI_MEDIA_TYPES 환경 변수를 application/x-www-form-urlencoded:multipart/form-data로 설정하십시오. 지원되지 않는 미디어 유형은 항상 건너 뜁니다. 미디어 유형 텍스트에는 서로 다른 섹션이 포함될 수 있습니다. 예를 들어application/vnd.api+json; charset=UTF-8은 type "/" [tree "."] subtype ["+" suffix]* [";" parameter]의 조합입니다. 요청 생성시 미디어 유형을 필터링할 때 매개 변수는 고려되지 않습니다.

환경 변수 FUZZAPI_OPENAPI_ALL_MEDIA_TYPES 및 FUZZAPI_OPENAPI_MEDIA_TYPES을 사용하여 미디어 유형을 처리하는 방법을 결정할 수 있습니다. 이러한 설정은 상호 배타적입니다. 둘 다 활성화되어 있으면 API 퍼징이 오류를보고합니다.

OpenAPI 사양으로 Web API 퍼징 구성

GitLab에서 OpenAPI 사양을 사용하여 API 퍼징을 구성하려면:

.gitlab-ci.yml 파일에 fuzz 스테이지를 추가합니다.
.gitlab-ci.yml에 다음과 같은 API-Fuzzing.gitlab-ci.yml 템플릿을 추가하십시오.
.gitlab-ci.yml 파일에 FUZZAPI_PROFILE CI/CD 변수를 추가하여 프로필을 제공하십시오. 이 프로필은 실행할 테스트 횟수를 지정합니다. 선택한 프로필에 대해Quick-10을 대체하십시오. 자세한 내용은 API 퍼징 프로필을 참조하십시오.
```
variables:
  FUZZAPI_PROFILE: Quick-10
```
OpenAPI 사양의 위치를 제공하십시오. 사양을 파일 또는 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 사양을 사용하여 .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 퍼징을 구성하려면 다음을 수행하세요:

.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 퍼징을 실행하려면 응용 프로그램이 도메인을 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 퍼징 스캔 구성

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

API 퍼징을 구성하여 테스트할 대상 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을 사용하는 예시 구성:

stages:
  - fuzz

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

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

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

첫 번째 스캔 실행.
인증 추가.
거짓 긍정의 처리 방법.

GraphQL 스키마 파일로 API 퍼징

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

테스트할 대상 API에 대한 정보를 제공하기 위해 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 스키마 파일을 사용하는 예시 구성:

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

첫 번째 스캔 실행.
인증 추가.
거짓 긍정의 처리 방법.

포스트맨 컬렉션

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

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

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

포스트맨 컬렉션 파일로 웹 API 퍼징 구성

Postman Collection 파일을 사용하여 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
```
Postman Collection 사양의 위치를 제공하세요. 파일 또는 URL로 사양을 제공할 수 있습니다. 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의 예시를 참조하실 수 있습니다.

포스트맨 컬렉션 파일을 사용하는 예시 .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 퍼징을 위한 최소한의 구성입니다. 여기서부터:

첫 번째 스캔 실행.
인증 추가.
false positives 처리 방법을 확인하세요.

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

포스트맨 변수

포스트맨 환경 파일 형식을 지원하기 시작했습니다(https://gitlab.com/gitlab-org/gitlab/-/issues/356312) - GitLab 15.1에서.
다중 변수 파일을 지원하기 시작했습니다(https://gitlab.com/gitlab-org/gitlab/-/issues/356312) - GitLab 15.1에서.
포스트맨 변수 스코프를 지원하기 시작했습니다(https://gitlab.com/gitlab-org/gitlab/-/issues/356312) - GitLab 15.1에서.

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

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

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

그런 다음 URL, 헤더 등과 같은 섹션에서 이러한 변수를 사용할 수 있습니다:

Postman은 멋진 UX 경험을 제공하는 기본 클라이언트 도구에서부터 스크립트로 API를 테스트하고 이를 트리거하는 복잡한 컬렉션을 만들며 이동하면서 더 복잡한 생태계로 성장했습니다. Postman 생태계의 모든 기능이 지원되는 것은 아닙니다. 예를 들어, 스크립트는 지원되지 않습니다. Postman 지원의 주요 초점은 Postman 클라이언트에서 사용되는 Postman Collection 정의와 워크스페이스, 환경 및 컬렉션에서 정의된 관련 변수를 수용하는 데 있습니다.

Postman은 서로 다른 스코프에서 변수를 생성할 수 있도록 합니다. 각 스코프는 Postman 도구에서 다른 수준의 가시성을 가집니다. 예를 들어, 글로벌 환경(global environment) 스코프에서 전역 환경으로 지정된 변수를 볼 수 있습니다. 또한 특정 환경(environment) 스코프에서만 환경이 선택된 경우에만 사용되고 볼 수 있습니다. Postman 스코프에 대해 익숙하지 않은 사용자도 있으므로 변수 스코프는 힘든 주제일 수 있습니다. 앞으로 나아가기 전에 Postman 문서의 변수 스코프를 읽는 것을 권장합니다.

위에서 언급한 바와 같이 각각의 스코프는 목적을 가지고 있으며 Postman 문서에 따라 변수의 값을 어떻게 계산하는지에 대한 중요한 참고 사항이 있습니다.

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

다음은 Postman 클라이언트와 API 퍼징이 지원하는 다양한 변수 스코프에 대한 요약입니다.

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

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

스코프	Postman	API Fuzzing	설명
글로벌 환경	예	예	특별하게 정의된 환경
환경	예	예	사용자가 만든 명명된 환경
컬렉션	예	예	Postman 컬렉션에 정의된 변수
API 퍼징 스코프	아니오	예	API Fuzzing에 의해 추가된 사용자 정의 스코프
데이터	예	아니오	CSV 또는 JSON 형식의 외부 파일
로컬	예	아니오	스크립트에서 정의된 변수

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

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": "Token 84816165151"
}

API Fuzzing에서 범위 사용하기

글로벌, 환경, 컬렉션, GitLab API Fuzzing_과 같은 범위는 GitLab 15.1 and later에서 지원됩니다. 이전의 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 클라이언트에서 global-scope.json로 내보내어 FUZZAPI_POSTMAN_COLLECTION_VARIABLES 구성 변수를 통해 API 퍼징에 제공됩니다.

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 퍼징에 제공됩니다.

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 퍼징 범위

API 퍼징 범위는 데이터_와 _로컬 범위 변수를 정의하거나 API 퍼징에서 지원되지 않는 변수의 값을 변경하는 데 주로 사용됩니다. API 퍼징 범위는 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 컬렉션을 postman-collection.json로 내보냅니다

API 퍼징은 제공된 파일의 데이터를 사용하여 파일이 어느 범위에 일치하는지 식별할 수 있습니다. Postman 컬렉션은 FUZZAPI_POSTMAN_COLLECTION 변수를 사용하여 제공되고, 다른 범위는 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: global-scope.json,environment-scope.json
  FUZZAPI_TARGET_URL: http://test-deployment/

예시: 변수 값 변경

내보낸 범위를 사용할 때, 변수의 값이 API 퍼징에 사용하기 위해 변경되어야 하는 경우가 있습니다. 예를 들어, 컬렉션 범위의 변수에는 값이 v2인 api_version이라는 변수가 포함될 수 있으며, 테스트에는 값이 v1이 필요할 수 있습니다. 값 변경을 위해 내보낸 컬렉션을 수정하는 대신에 API 퍼징 범위를 사용하여 값을 변경할 수 있습니다. 이는 API 퍼징 범위가 모든 다른 범위보다 우선시되기 때문에 작동합니다.

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

API 퍼징 범위는 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 퍼징에 사용하기 위해 변경되어야 하는 경우가 있습니다. 예를 들어, 환경 범위에는 값이 v2인 api_version이라는 변수가 포함될 수 있으며, 테스트에는 값이 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 컬렉션은 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 작업이 포함됩니다. 작업은 잘못된 구성이 제공된 경우에만 실패합니다. 일반적인 작동에서는 fuzz 테스트 중에 결함이 식별되더라도 작업이 항상 성공합니다.

보안 파이프라인 탭에서 결함은 스위트 이름과 함께 표시됩니다. 리포지터리의 기본 브랜치에 대한 테스트인 경우 fuzzing faults는 보안 및 컴플라이언스의 취약성 보고서 페이지에도 표시됩니다.

너무 많은 보고된 결함을 방지하기 위해 API fuzzing 스캐너는 보고하는 결함의 수를 제한합니다.

Fuzzing 결함 보기

API Fuzzing 분석기는 수집되고 사용되는 JSON 보고서를 생성하여 GitLab 취약성 화면에 결함을 채우는 데 사용합니다. Fuzzing faults는 Severity가 Unknown인 취약성으로 나타납니다.

API fuzzing이 발견한 결함은 매뉴얼 조사가 필요하며 특정 취약성 유형과 관련되지 않습니다. 결함이 보안 문제인지 여부 및 수정해야 하는지 여부를 결정하기 위해 조사가 필요합니다. 거짓 긍정적인 처리에 대한 정보는 거짓 긍정을 제한하기 위해 수행할 수 있는 구성 변경을 참조하세요.

API Fuzzing 취약점의 자세한 정보보기

API Fuzzing에 의해 감지된 결함은 라이브 웹 애플리케이션에서 발생하며 취약점인지 여부를 결정하기 위해 매뉴얼 조사가 필요합니다. Fuzzing faults는 Severity가 Unknown인 취약성으로 포함됩니다. Fuzzing faults의 조사를 용이하게 하기 위해 HTTP 메시지의 전송 및 수신에 대한 자세한 정보와 수행된 수정의 설명이 제공됩니다.

다음 단계를 따라 fuzzing fault의 자세한 정보를 보세요:

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

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

필드	설명
Description	변경 사항에 대한 설명
Project	취약점이 검출된 네임스페이스 및 프로젝트
Method	취약점을 검출하는 데 사용된 HTTP 메서드
URL	취약점이 검출된 URL
Request	결함을 발생시킨 HTTP 요청
Unmodified Response	수정되지 않은 요청의 응답. 일반적인 작동 응답의 모습입니다
Actual Response	수정된 요청에서 받은 응답
Evidence	결함이 발생했음을 확인한 방법
Identifiers	이 결함을 발견한 fuzzing 체크
Severity	발견의 심각성은 항상 Unknown입니다
Scanner Type	수행된 테스트에 사용된 스캐너

보안 대시보드

Fuzzing faults는 Severity가 Unknown인 취약성으로 나타납니다. 보안 대시보드는 그룹, 프로젝트 및 파이프라인의 모든 보안 취약성에 대한 개요를 제공하는 좋은 장소입니다. 자세한 정보는 보안 대시보드 설명서를 참조하세요.

취약점과 상호 작용

Fuzzing faults는 Severity가 Unknown인 취약성으로 나타납니다. 결함이 발견되면 상호 작용할 수 있습니다. 취약점 처리 방법에 대해 자세히 알아보세요.

거짓 긍정적 처리

거짓 긍정적인 처리는 두 가지 방법으로 처리할 수 있습니다.

거짓 긍정을 생성하는 Check를 끕니다. 이렇게 하면 결함이 생성되지 않습니다. 예제 체크로는 JSON Fuzzing Check 및 Form Body Fuzzing Check 등이 있습니다.
Fuzzing checks에는 Asserts라는 결함을 식별하는 여러 방법이 있습니다. Asserts도 끄고 구성할 수 있습니다. 예를 들어, API fuzzer는 기본 설정에서 실제 문제임을 식별하는 데 HTTP 상태 코드를 사용합니다. 테스트 중에 API가 500 오류를 반환하면 이는 결함을 생성합니다. 이는 항상 원하는 것은 아니며 일부 프레임워크는 500 오류를 자주 반환합니다.

Check 끄기

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

General Fuzzing Check를 끄려면 다음 라인을 제거합니다:

- 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

Check을 위한 Assertion 끄기

Check는 테스트에서 발생하는 결함을 감지하는 여러 방법인 Asserts를 지원합니다. 여러 Assertions를 지원하는 많은 Check가 있으며 예시로 Log Analysis, Response Analysis 및 Status Code를 들 수 있습니다. 결함이 발견되면 사용된 Assertion이 제공됩니다. 기본적으로 활성화된 Assertions를 식별하려면 구성 파일의 Checks 기본 구성을 참조하세요. 이러한 섹션은 Checks라고 합니다.

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

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

여기서 세 가지 Assertions이 기본적으로 활성화되어 있습니다. 거짓 긍정의 일반적인 원인은 StatusCodeAssertion입니다. 이를 끄려면 구성 파일의 프로파일 섹션에서 해당하는 구성을 수정하세요. 이 예시에서는 StatusCodeAssertion를 사용하지 않도록 설정하여 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

분석기 활성화

Web API 퍼징 구성 양식

UI에서 Web API 퍼징 구성

OpenAPI Specification

OpenAPI 및 미디어 유형

OpenAPI 사양으로 Web API 퍼징 구성

HTTP 아카이브 (HAR)

HAR 파일로 웹 API 퍼징 구성

GraphQL 스키마

GraphQL 엔드포인트 URL로 API 퍼징 스캔 구성

GraphQL 스키마 파일로 API 퍼징

포스트맨 컬렉션

포스트맨 컬렉션 파일로 웹 API 퍼징 구성

포스트맨 변수

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

Postman Client에서 내보내기

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

API Fuzzing에서 범위 사용하기

정의되지 않은 Postman 변수

동적 Postman 변수

예시: 글로벌 범위

예시: 환경 범위

예시: 컬렉션 범위

예시: API 퍼징 범위

예시: 여러 범위

예시: 변수 값 변경

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

첫 번째 스캔 실행

Fuzzing 결함 보기

API Fuzzing 취약점의 자세한 정보보기

보안 대시보드

취약점과 상호 작용

거짓 긍정적 처리

Check 끄기

Check을 위한 Assertion 끄기

도움말

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

도움받기