Web API fuzzing configuration form
- UI에서 Web API fuzzing 구성하기
OpenAPI Specification
OpenAPI 및 미디어 유형
- 오픈API 명세서를 사용하여 Web API 퍼징 구성
HTTP 아카이브 (HAR)
- HAR 파일을 사용하여 Web API 퍼징 구성
GraphQL 스키마
- GraphQL 엔드포인트 URL을 사용한 API Fuzzing 스캔
- GraphQL 스키마 파일을 사용한 API Fuzzing
Postman Collection
- Postman Collection 파일을 사용한 웹 API 퍼징 구성
- Postman 변수
첫 번째 스캔 실행하기
퍼징(fuzzing) 결함 보기
잘못된 양성 처리
- Check 해제
- Check 단언(Assertion) 해제

Analyzer 활성화하기

사전 요구 사항:

다음 Web API 유형 중 하나:
- REST API
- SOAP
- GraphQL
- 폼 본문, JSON 또는 XML
다음과 같은 자산 중 하나를 사용하여 테스트할 API 제공:
- OpenAPI v2 또는 v3 API 정의
- API 테스트용 HTTP 아카이브 (HAR)
- Postman Collection v2.0 또는 v2.1

경고: 생산 서버에 대해 fuzz 테스트를 결코 실행하지 마십시오. API가 수행할 수 있는 어떤 기능이든 수행할 뿐만 아니라 API에서 버그를 트리거할 수도 있습니다. 이는 데이터 수정 및 삭제와 같은 작업을 포함합니다. Fuzzing은 테스트 서버에서만 실행하십시오.

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

수동 구성 지침은 각 API 유형에 따라 해당 섹션을 참조하십시오:
그렇지 않으면 Web API fuzzing configuration form을 참조하십시오.

API fuzzing 구성 파일은 귀하의 저장소의 .gitlab 디렉터리에 있어야 합니다.

Web API fuzzing configuration form

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. Lint 탭을 선택하여 편집한 .gitlab-ci.yml 파일이 유효한지 확인하십시오.
  3. 편집 탭을 선택한 다음 변경 사항 커밋을 선택하십시오.

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

OpenAPI Specification

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

기본 동작은 지원되는 미디어 유형 중 하나를 선택하여 사용하는 것입니다. 리스트에서 첫 번째 지원되는 미디어 유형이 선택됩니다. 이 동작은 설정 가능합니다.

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

환경 변수 FUZZAPI_OPENAPI_ALL_MEDIA_TYPES을 사용하면 특정 작업에 대해 하나가 아닌 모든 지원되는 미디어 유형을 사용할지 여부를 지정할 수 있습니다. 환경 변수 FUZZAPI_OPENAPI_ALL_MEDIA_TYPES가 임의의 값을 설정하면 API Fuzzing은 특정 작업에 대해 하나가 아닌 모든 지원되는 미디어 유형에 대해 요청을 생성하려고 시도합니다. 이렇게 하면 제공된 각 미디어 유형에 대해 반복 테스트를 실시하므로 테스트에 더 긴 시간이 소요됩니다.

반대로 변수 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 Fuzzing은 오류를 보고합니다.

오픈API 명세서를 사용하여 Web API 퍼징 구성

GitLab에서 오픈API 명세서를 사용하여 API 퍼징을 구성하려면 다음 단계를 수행하세요:

.gitlab-ci.yml 파일에 fuzz 단계를 추가합니다.
.gitlab-ci.yml 파일에이 템플릿을 포함합니다. .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에서 확인할 수 있습니다.

오픈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 파일을 사용하여 Web API 퍼징 구성

HAR 파일을 사용하여 API 퍼징을 구성하려면 다음 단계를 수행하세요:

.gitlab-ci.yml 파일에 fuzz 단계를 추가합니다.
.gitlab-ci.yml 파일에이 템플릿을 포함합니다. .gitlab-ci.yml 파일에 ‘API-Fuzzing.gitlab-ci.yml’ 템플릿을 포함합니다.
.gitlab-ci.yml 파일에 FUZZAPI_PROFILE CI/CD 변수를 추가하여 프로필을 제공합니다. 프로필은 실행되는 테스트의 수를 지정합니다. 원하는 프로필로 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 컬렉션을 사용하여 테스트.

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

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

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

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

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

.gitlab-ci.yml 파일에 API-Fuzzing.gitlab-ci.yml 템플릿을 포함시킵니다.
FUZZAPI_GRAPHQL 변수를 추가하여 예를들어 /api/graphql와 같이 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 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 템플릿을 포함시킵니다.
FUZZAPI_GRAPHQL 변수를 추가하여 예를들어 /api/graphql와 같이 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 Fuzzing의 최소한의 구성입니다. 여기서부터 다음 작업을 수행할 수 있습니다:

첫 번째 스캔 실행.
인증 추가.
오검출 핸들링 방법 학습.

Postman Collection

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

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

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

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

API 퍼징을 사용하여 Postman Collection 파일을 사용하려면 다음을 수행하세요:

.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
```
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에서 이를 보실 수 있습니다.

Postman Collection 파일을 사용하는 예제 .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 Environment 파일 형식을 지원하기 시작했습니다.
GitLab 15.1에서 여러 변수 파일을 지원하기 시작했습니다.
GitLab 15.1에서 Postman 변수 스코프(Global 및 Environment)를 지원하기 시작했습니다.

Postman 클라이언트의 변수

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

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

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

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

Postman은 다른 범위에서 변수를 생성할 수 있게 합니다. 각 범위에는 Postman 도구에서 다른 수준의 가시성이 있는 다양한 수준의 변수가 있습니다. 예를 들어 전역 환경 범위에 변수를 생성하여 모든 작업 정의 및 워크스페이스에서 볼 수 있는 특별한 미리 정의된 환경인 전역 환경 범위로도 참조할 수 있습니다. 또한 특정 환경 범위에서 변수를 생성하여 해당 특정 환경이 선택된 상태에서만 가시적이며 사용할 수 있는 환경 범위로도 참조할 수 있습니다. 일부 범위는 항상 사용할 수 없습니다. 예를 들어 Postman 생태계에서 Postman 클라이언트에서 요청을 만들 수 있지만, 이러한 요청에는 로컬 범위가 없지만 테스트 스크립트에는 있습니다.

Postman의 변수 스코프는 복잡한 주제일 수 있으며 모든 사람이 그것을 알지는 않습니다. 전진하기 전에 Postman 문서의 변수 스코프를 읽는 것을 강력히 추천합니다.

위에서 언급했듯이 다양한 변수 범위가 있으며 각각의 목적을 가지며 Postman 문서에 따라 변수 값이 어떻게 계산되는 중요한 참고사항이 있습니다:

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

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

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

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

범위	Postman	API Fuzzing	Comment
전역 환경	예	예	특별하게 정의된 환경
환경	예	예	명명된 환경
컬렉션	예	예	사용자의 Postman 컬렉션에서 정의됨
API Fuzzing 범위	아니요	예	API Fuzzing에 의해 추가된 사용자 정의 범위
데이터	예	아니요	CSV 또는 JSON 형식의 외부 파일
로컬	예	아니요	스크립트에서 정의된 변수

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

Postman Client에서 내보내기

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

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

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

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

저희의 사용자 정의 JSON 파일 형식은 JSON 객체이며, 각 객체 속성은 변수 이름을 나타내고 속성 값은 변수 값입니다. 이 파일은 좋아하는 텍스트 편집기를 사용하여 생성할 수 있으며, 또는 이전에 파이프라인 작업에서 생성될 수 있습니다.

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

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

API Fuzzing에서 범위 사용

global, environment, collection, GitLab API Fuzzing_의 범위는 GitLab 15.1 이후에서 지원됩니다. GitLab 15.0 이전에는 _collection 및 GitLab API Fuzzing 범위만 지원됩니다.

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

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

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

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

구성 변수 FUZZAPI_POSTMAN_COLLECTION_VARIABLES를 다음으로 설정할 수 있습니다:

정의되지 않은 Postman 변수

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

data 또는 local 범위 변수를 사용하고 있는 경우이며, 이러한 범위가 API Fuzzing에서 지원되지 않습니다. 따라서 data 또는 local 범위 변수의 값이 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의 동작과는 다르며, Postman Client는 동일한 동적 변수 사용 시 매번 무작위 값을 반환합니다. 다시 말해, 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 컬렉션 파일에 포함되며 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 컬렉션을 postman-collection.json으로 내보냅니다.

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
  FUZZAPI_TARGET_URL: http://test-deployment/

예시: 변수 값 변경

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

컬렉션_ 스코프 변수가 내보낸 Postman 컬렉션 파일에 포함되며 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으로
컬렉션 스코프를 포함하는 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 작업이 포함됩니다. 잘못된 구성이 제공되지 않는 한, 작업은 실패하지 않습니다. 일반적인 운영에서도, 작업은 항상 성공합니다.

결함은 보안 파이프라인 탭에 나타납니다. 저장소의 기본 브랜치에 대해 테스트하는 경우, 퍼징(fuzzing) 결함이 보안 및 규정 준수의 취약점 보고서 페이지에 표시됩니다.

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

퍼징(fuzzing) 결함 보기

API Fuzzing 분석기는 수집되어 사용된 JSON 보고서를 생성합니다. 이 보고서는 GitLab 취약점 화면에 결과를 채우기 위해 사용됩니다. 퍼징(fuzzing) 결함은 알 수 없는 심각도로 취약점으로 표시됩니다.

API 퍼징이 찾는 결함의 경우 수동 조사가 필요하며 특정 취약점 유형과 관련되지 않습니다. 이러한 결함은 수정해야 할 보안 문제인지, 그리고 수정해야 할지를 결정하기 위해 조사가 필요합니다. 잘못된 양성(fals positives) 처리에서 보고된 잘못된 양성의 수를 제한하기 위해 만들 수 있는 구성 변경에 대한 정보를 참조하세요.

API Fuzzing 취약점의 상세 정보 보기

API Fuzzing에 의해 검출된 결함은 실시간 웹 애플리케이션에서 발생하며, 이러한 결함은 수동 조사를 요구합니다. 퍼징 결함은 알 수 없는 심각도의 취약점으로 표시됩니다. 퍼징 결함의 세부 정보를 살펴보기 위해 다음 단계를 따르세요:

프로젝트 또는 병합 요청에서 결함을 볼 수 있습니다:
- 프로젝트의 보안 > 취약점 보고서 페이지로 이동합니다. 이 페이지에는 기본 브랜치의 모든 취약점이 표시됩니다.
- 병합 요청의 보안 섹션으로 이동하고 확장 버튼을 선택합니다. API Fuzzing 결함은 API Fuzzing가 N개의 잠재적인 취약점을 감지했습니다라는 제목의 섹션에 표시됩니다. 타이틀을 선택하여 결함 세부 정보를 표시합니다.

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

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

보안 대시보드

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

취약점과 상호작용

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

잘못된 양성 처리

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

잘못된 양성 생성을 중지합니다. 이렇게 하면 결함이 생성되지 않습니다. 예시로 JSON 퍼징 확인, Form Body 퍼징 확인 등이 있습니다.
퍼징 확인은 결함이 식별된 상황을 감지하는 여러가지 방법을 가지고 있습니다. 이를 Asserts 라고 합니다. Asserts도 중지하고 구성할 수 있습니다. 예를 들어, API 퍼징 도구는 기본적으로 HTTP 상태 코드를 사용하여 실제 문제를 식별하는 데 사용합니다. 테스트 중에 API가 500 에러를 반환하면, 이는 결함을 생성합니다. 이것은 항상 원하는 결과가 아닙니다. 일부 프레임워크에서는 자주 500 에러를 반환합니다.
- 무한 반복할 실행되는 500 에러 반환이 출력되더라도, 결과가 찍힌다.

Check 해제

Checks은 특정 유형의 테스트를 수행하며, 특정 구성 프로필에서는 활성화/비활성화할 수 있습니다. 기본 구성 파일에는 사용할 수 있는 여러 프로필이 정의되어 있습니다. 구성 파일의 프로필 정의는 스캔 중에 활성 상태인 모든 checks를 나열합니다. 특정 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

이에 따라 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 단언(Assertion) 해제

Assertions은 checks에 의해 생성된 테스트에서 결함을 감지합니다. 많은 checks가 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

여기서 기본적으로 세 개의 단언이 활성화되어 있음을 확인할 수 있습니다. False positives(잘못된 비활성화)의 일반적인 원인은 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 및 미디어 유형

오픈API 명세서를 사용하여 Web API 퍼징 구성

HTTP 아카이브 (HAR)

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

GraphQL 스키마

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

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

Postman Collection

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

Postman 변수

Postman 클라이언트의 변수

Postman Client에서 내보내기

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

API Fuzzing에서 범위 사용

정의되지 않은 Postman 변수

동적 Postman 변수

예시: 글로벌 스코프

예시: 환경 스코프

예시: 컬렉션 스코프

예시: API Fuzzing 스코프

예시: 다중 스코프

예시: 변수 값 변경

예시: 다중 스코프로 변수 값 변경하기

첫 번째 스캔 실행하기

퍼징(fuzzing) 결함 보기

API Fuzzing 취약점의 상세 정보 보기

보안 대시보드

취약점과 상호작용

잘못된 양성 처리

Check 해제

Check 단언(Assertion) 해제

도움말

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

도움받기