web api fuzzer

api fuzzer?

간단히 말해서 api에 퍼징 테스트를 수행하는 퍼저이다.

api에 무작위 입력값을 넣어보고, 만약 해당 api가 비정상적인 반응값을 출력할 때(일반적으로 400 / 500 계열 오류를 출력해야 하는데 어떤 잘못된 무작위 값에서 200 리턴값을 출력한다던가 등등....)를 탐지함으로서 해당 api의 취약성을 평가하는 도구이다.

 

API 퍼징의 종류:
블랙박스 퍼징: API 내부 동작을 모르는 상태에서 외부 동작만을 테스트하는 퍼징
화이트박스 퍼징: 소스 코드를 미리 알고 있다는 전제 하에 구체적인 테스트 데이터를 만들어 코드의 특정 부분 겨냥하는 퍼징
그레이박스 퍼징: 일부 코드나 동작을 알고 있는 상태에서 테스트하는 퍼징

 

API 퍼징 테스트 과정

테스트 데이터 생성
API 퍼저는 다음과 같은 비정상적인 입력값(시드 셋)을 자동으로 생성한다

• 긴 문자열 또는 지나치게 큰 값
• 특수 문자 (예: *, $, ;)나 비알파벳 문자
• 경계값(0, 음수, 매우 큰 숫자 등)
• 비정상적인 형식의 입력값

테스트 케이스 실행: 

생성된 입력값을 API에 전달하고, 비정상적인 반응(예: 충돌, 예상치 못한 출력 등)을 모니터링한다.

예를 들어, 매우 긴 입력값을 받았을 때 API가 충돌하여 이상반응을 할 경우, 이는 버퍼 오버플로 취약점일 수도 있다.

 

API 관련 취약점 탐지:
인증 관련 취약점: 사용자 인증을 처리하는 API가 비정상적인 입력(예: 매우 긴 사용자 이름, 특수 문자가 포함된 비밀번호)에서 제대로 동작하지 않을 때 취약점이 발생할 수 있음
데이터 처리 취약점: JSON이나 XML 같은 데이터를 제대로 검증하지 않을 때 취약점이 발생할 수 있음

 

퍼징의 한계:
오탐지 및 미탐지:

대량의 테스트 케이스 생성 -> 실제로 취약점도 아닌 것을 취약점으로 보고하는 경우(오탐지)나 실제 취약점을 놓치는 경우(미탐지)가 충분히 발생할 수 있음
시간 소모: API의 크기나 복잡성에 따라 퍼징에 많은 시간이 소요

결론?
API 퍼징은 서버 배포 후 배포된 서버의 취약점을 사전에 발견하고 해결하는 데 도움을 줄 수 있는 도구이다. 그러나, 퍼징은 강력한 테스트 도구이긴 하지만 완벽한 건 아니기 때문에 모의침투 테스트나 정적 코드 분석과 함께 사용하는 것이 가장 효과적인 편이다.

 

▷ API 퍼징의 시드 값 예시

- 버퍼 오버플로우

입력 값: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa... (1000자 이상의 문자)"
결과: API가 버퍼 오버플로우로 인해 충돌하거나, 메모리 부족 문제로 인해 오류 메시지를 출력할 수 있다.

정상적으로 처리되지 않는다면(ex. 서버 오류 메세지가 아니라 엉뚱한 것을 출력함) 보안 취약점으로 이어질 수 있다
- 비정상적인 특수 문자
입력 값: "username=' OR '1'='1';--"
결과: 만약 API가 SQL 쿼리를 사용하여 데이터베이스와 상호작용할 경우 해당 입력값은 SQL 인젝션 공격을 유발할 수 있다.

이로 인해 외부 이용자가 인증 없이 로그인되는 등의 보안 취약점이 발생할 수 있다
- 비정상적인 숫자 입력
입력 값: -999999999999 또는 매우 큰 숫자 (999999999999999999999)
결과: 숫자 값을 처리하는 API가 해당 값에 대해 제대로 처리하지 못하고, 숫자 범위를 벗어나거나 무한 루프에 빠지는 등의 오류를 일으킬 수 있다
- 잘못된 형식의 데이터
입력 값: { "username": 12345, "password": true }
결과: API가 JSON 데이터 형식을 예상했지만, 숫자나 bool 값을 포함한 잘못된 데이터 형식을 전달하면 처리 오류가 발생하거나, 특정 필드가 비정상적으로 작동할 수 있다
- 오류 또는 충돌
API가 예상치 못한 값(예: 지나치게 긴 문자열, 특수 문자 등)을 받았을 때, 이를 처리하는 과정에서 메모리 오버플로우나 예외 처리 미비로 인해 API가 충돌하거나 비정상적으로 종료될 수 있다. 이 경우, 버퍼 오버플로우 또는 메모리 관리 취약점과 같은 취약점이 발생할 수 있다.

 

그러면 api fuzzer가 어떻게 해서 취약점이라는 것을 잡아내는 걸까?

api에 요청을 보낼때, 개발을 좀 하신 분이라면 알겠지만 이상한 값을 보내면 서버 에러(500번대 에러)가 뜨거나, 클라이언트 에러(400번대 에러)가 뜨거나 둘 중 하나가 떠야 정상이다. 그러나 위의 취약점들은 퍼저가 해당 경우의 랜덤값들을 보낼 경우 우리가 예상한 에러 코드의 출력값이 아니라, 비정상적인 반응을 보이기 때문에 이를 캐치(catch)하여 탐지하는 로직인 셈이다.
- 비정상적인 오류 코드:
예를 들어, 인증되지 않은 사용자가 접근해야 할 수 없는 자원에 요청을 보내면 일반적으로 403(Forbidden) 오류가 반환되어야 합니다. 하지만 잘못된 값으로 요청을 보냈을 때 200(OK)이나 500(Internal Server Error)와 같은 비정상적인 상태 코드를 받게 된다면, 이는 취약점의 징후일 수 있습니다. API가 예상되는 처리 흐름과 다르게 반응하는 것이 취약점을 드러냅니다​
- 서버 충돌 및 비정상 종료: 
잘못된 입력값을 보낸 후 API가 500 오류를 반환하거나, 서버가 응답하지 않거나 충돌하는 경우가 있습니다. 이런 경우, API가 입력 데이터를 제대로 처리하지 못하고 있음을 나타내며, 여기서 버퍼 오버플로우와 같은 보안 취약점이 드러날 수 있습니다​
- 예상치 못한 응답 시간 증가: 
특정 입력값이 API의 응답 시간을 급격히 증가시키는 경우, API는 성능 저하나 자원 고갈 문제로 취약할 수 있습니다. 이는 서비스 거부(DoS) 공격의 가능성을 시사할 수 있으며, 퍼저는 이러한 비정상적인 응답 지연을 기록하여 문제를 보고합니다
- 정확하지 않은 상태 코드 및 메시지: 
403(Forbidden) 또는 404(Not Found) 오류와 같은 일반적인 상태 코드는 정상적인 상황에서 예상되는 오류 코드입니다. 그러나, 퍼저가 잘못된 입력을 통해 잘못된 상태 코드(예: 내부 서버 오류인 500 대신 200 OK)가 반환되는 경우, API가 문제를 제대로 처리하지 못하고 있음을 의미합니다. 즉, 비정상적인 상태 코드나 오류 메시지를 통해 입력값 검증 미비나 비정상적 처리 로직을 탐지할 수 있습니다
- 응답 메시지 내용:
오류 코드가 정상적으로 반환되더라도, 오류 메시지 내용에서 디버그 정보나 민감한 정보가 노출되는 경우가 있습니다. 이는 공격자에게 시스템 내부 정보를 제공하는 취약점이 될 수 있습니다. 퍼저는 이러한 불필요한 정보 노출을 탐지하여 보고할 수 있습니다​

결국, 단순한 오류 코드 이상의 비정상적인 동작 패턴을 통해 퍼저는 API의 취약점을 탐지함 

이는 API가 예상하지 못한 방식으로 응답하거나, 입력을 제대로 처리하지 못할 때 드러남

 

api fuzzing test

내가 준비한 테스트 set + 오픈소스 대량의 데이터 set을 통해 테스트 검증 필요

https://github.com/OAI/OpenAPI-Specification/blob/main/examples/v3.0/uspto.json

OpenAPI-Specification/examples/v3.0/uspto.json at main · OAI/OpenAPI-Specification

openapi spec file 데이터셋 + 우리가 준비한 테스트 데이터 셋으로 api fuzzer를 테스팅

테스트할 api fuzzer는 cherrybomb api fuzzer

 

테스트 및 api fuzzer 분석 관련 글은 다음에 이어서 쓰도록 하겠다...