기술 요약: GraphQLer

문제 정의

GraphQL API는 스키마 기반의 단일 엔드포인트 설계 덕분에 프로덕션 시스템에서 지배적인 위치를 차지하게 되었습니다. 그러나 이러한 아키텍처는 REST API에는 없는 독특한 보안 과제를 도입합니다. HTTP 동사와 URL 구조를 통해 의도를 인코딩하는 REST와 달리, GraphQL은 모든 작업을 단일 엔드포인트를 통해 노출하며 내장된 접근 제어 강제 기능이 없습니다.

본 논문은 핵심적인 접근 제어 취약점, 특히 부적절한 직접 객체 참조(IDOR), 사용 후 해제(Use-After-Free, UAF), 그리고 **상태 의존적 인젝션(state-dependent injection)**이 자동화된 보안 테스트를 지속적으로 탈출한다는 점을 식별했습니다. 기존의 산업 표준 스캐너(예: ZAP) 및 연구용 퍼저(예: EvoMaster)는 작업을 개별적으로 테스트합니다. 이들은 GraphQL의 상태 의존적 구조를 모델링하지 못합니다. 즉, 하나의 뮤테이션이 이전 작업에 의해 생성된 리소스에 암묵적으로 의존할 수 있다는 점을 간과합니다. 결과적으로, 다단계 시퀀스가 필요한 취약점(예: 사용자 A가 리소스를 생성한 후 사용자 B가 이에 접근하는 경우)은 연산 체인을 구성할 수 없는 도구들에게는 보이지 않게 됩니다.

방법론

저자들은 **취약점 체인(vulnerability chains, 순차적 연산 시퀀스)**을 일급 객체로 취급하도록 설계된 오픈 소스 자동화 보안 테스트 프레임워크인 GraphQLer를 제시합니다. 이 프레임워크는 두 가지 주요 단계로 작동합니다.

1. 컴파일 단계 (Compilation Phase)

GraphQLer는 인트로스펙션(introspection)을 통해 라이브 스키마를 파싱하여 **타입 의존성 그래프(typed dependency graph)**를 구축합니다.

• 액션 어노테이션(Action Annotation): 이름과 설명을 분석하여 뮤테이션의 의미(CREATE, UPDATE, DELETE 또는 UNKNOWN)를 추론합니다. 모호한 경우는 선택적인 LLM 기반 리졸버를 통해 해결할 수 있습니다.
• 의존성 추론(Dependency Inference): GraphQL은 입력 의존성을 기계 판독 가능한 형태로 명시적으로 노출하지 않으므로, GraphQLer는 이름 패턴 유도와 레벤슈타인 거리(Levenshtein distance) 점수를 사용하여 ID 타입의 입력 필드를 객체 타입과 매칭함으로써 엣지(edge)를 추론합니다.
• 그래프 구축(Graph Construction): 시스템은 쿼리, 뮤테이션, 객체 타입을 위한 노드를 생성하고, 이를 하드(non-nullable) 및 소프트(nullable) 의존성을 나타내는 방향성 엣지로 연결합니다.

2. 테스트 단계 (Testing Phase)

테스트 단계는 세 단계 전략(CREATE/Queries $\rightarrow$ UPDATE $\rightarrow$ DELETE)을 사용하여 의존성 그래프를 탐색하고 페이로드를 구체화합니다.

• 페이로드 구체화(Payload Materialization): 유효한 페이로드(최소 및 최대 유효 페이로드)와 퍼징된 페이로드(SQLi, XSS, OS command 등을 주입)를 생성합니다. 또한 이후의 연산에서 재사용하기 위해 반환된 리소스(ID, 상태)를 저장하는 **객체 버킷(objects bucket)**을 유지합니다.
• 취약점 체인 전략(Vulnerability Chain Strategies): GraphQLer는 특정 공격 시퀀스를 합성하기 위해 세 가지 특화된 전략을 사용합니다:
  1. 위상적 체인 전략(Topological Chain Strategy): 순환 그래프를 처리하기 위해 강결합 컴포넌트(Strongly Connected Component, SCC) 응축을 사용하여 일반적인 도달 가능성을 위한 유효한 실행 순서를 보장합니다.
  2. IDOR 체인 전략(IDOR Chain Strategy): 일반적인 체인을 가져와 CREATE 단계에는 "기본(primary)" 사용자 자격 증명을 사용하고, 이후 단계에는 "보조(secondary)"(권한이 낮은) 사용자 자격 증명을 사용하여 재현합니다. 보조 사용자가 접근해서는 안 되는 리소스에 접근할 경우 취약점이 플래그 처리됩니다.
  3. UAF 체인 전략(UAF Chain Strategy): 리소스가 생성, 삭제된 후 다시 읽히는 체인을 합성합니다. 시스템은 $c$가 CREATE, $d$가 DELETE, $r$이 READ인 사중항 $(c, o, d, r)$을 검색합니다. 만약 READ 단계에서 DELETE 이후에도 데이터가 반환되면 UAF 취약점이 감지됩니다.

또한 이 프레임워크는 WebSocket 기반의 구독(subscriptions)을 지원하며, AI 보조 워크플로우를 위해 파이프라인을 모델 컨텍스트 프로토콜(MCP) 서버로 노출합니다.

주요 기여

1. 취약점 체인: 단일 연산 도구가 놓치는 다단계 취약점을 탐지하기 위해 설계된 순차적 GraphQL 연산 시퀀스를 주요 테스트 구조로 도입했습니다.
2. 세 가지 특화 전략: 일반적인 도달 가능성을 위한 위상적 SCC 탐색, 교차 사용자 IDOR 재현, UAF 그래프 엣지 합성을 구현하여 핵심 공격 표면을 커버합니다.
3. GraphQLer 도구: 의존성 그래프, 9가지 취류 범위를 다루는 인젝션 스위트, LLM 지원 의존성 리졸버, 멀티 인증 프로필 엔진을 갖춘 오픈 소스 구현체를 제공합니다.
4. 광범에한 평가: 공공 API, 프로덕션 플랫폼 API, 알려진 취약점이 있는 애플리케이션(Saleor, DVGA), 목적 기반의 그라운드 트루스(ground-truth) API를 포함한 21개 API에 대해 평가를 수행했습니다.

결과

평가 결과, GraphQLer는 커버리지와 취약점 탐지 측면 모두에서 기존 도구들을 크게 능가하는 것으로 나타났습니다:

• 연산 커버리지: 11개의 공공 API에서 GraphQLer는 평균 85.52%의 PositiveCoverage를 달성했으며, 이는 EvoMaster(29.29%)와 ZAP(21.80%)보다 높은 수치입니다.
• 그라운드 트루스 탐지:
  • IDOR: 목적 기반 API에서 확인된 5개의 모든 IDOR 엔드포인트를 탐지했습니다.
  • UAF: VVSM-API에서 UAF 동작을 탐지했으며, IDOR-API에서도 부수적으로 탐지했습니다.
  • 인젝션: 목적 기반 API에서 SQLi, XSS, OS command injection을 확인했으며, 제3자 애플리케이션인 DVGA에서 XSS와 SQLi를 독립적으로 검증했습니다.
  • 베이스라인 비교: 모든 베이스라인 도구(ZAP, EvoMaster, Schemathesis, GraphQL-Cop)는 체인 기반 취약점(IDOR 또는 UAF)을 단 하나도 탐지하지 못했습니다.
• 실제 적용: 프로덕션 금융 API(FinServ)에서 GraphQLer는 사전 문서나 자격 증명 없이도 스택 트레이스를 노출하는 서비스 거부(DoS) 벡터를 포함한 8개의 잠재적 취약점을 식별했습니다. CVE-2022-39275가 고정된 Saleor 인스턴스에서 보안 권고문에 언급된 4개의 모든 접근 제어 결함 뮤테이션을 재현했습니다.

의의 및 주장

본 논문은 GraphQLer가 자동화된 보안 테스트의 구조적 격차, 즉 상태 유지형 다단계 의존성을 모델링하지 못하는 기존 도구들의 한계를 해결한다고 주장합니다. 취약점 체인을 합성함으로써, GraphQLer는 단일 연산 퍼저가 볼 수 없는 결함을 드러냅니다.

저자들은 GraphQLer를 단순한 스캐너가 아니라, 프로덕션 시스템에서 고위험 벡터를 식별할 수 있는 산업적 분류(triage) 및 증거 수집을 위한 도구로 포지셔닝하며, 완전한 블랙박스 방식으로 작동할 수 있습니다. 이 연구는 단일 연산 도구가 스키마 준수 여부는 확인할 수 있을지라도, 연산의 순서와 상태에 의존하는 취약점을 탐지하는 데는 아키텍처적으로 불가능하다는 점을 강조합니다. 그라운드 트루스 API(IDOR-API, Injection-API, VVSM-API)의 공개는 체인 기반 GraphQL 취약점 탐지를 위한 첫 번째 라벨링된 벤치마크를 제공하기 위함입니다.

논문은 한계점에 대해서도 겸허하게 언급하며, 특정 복잡한 전제 조건(예: 인젝션을 위한 다중 필드 인증)과 스칼라 구체화 문제가 여전히 미탐(false negative)을 초래할 수 있으며, 대규모 제3자 애플리케이션에 대한 IDOR/UAF의 독립적인 외부 검증은 향후 과제로 남겨두고 있습니다.