Qt OpenAPI 보안 고려 사항

외부 소스의 OpenAPI 사양 처리

OpenAPI 사양 파일은 코드 생성 파이프라인의 주요 입력 자료입니다. 이 파일은 생성된 클라이언트의 전체 범위를 정의합니다: API 엔드포인트, 데이터 모델, 서버 URL, 인증 방식 및 운영 매개변수 등이 포함됩니다. 생성기는 사양 내용을 직접 C++ 소스 코드로 변환하므로, 신뢰할 수 있는 입력 자료에만 사용해야 합니다.

사용자는 외부 소스에서 얻은 OpenAPI 사양을 기반으로 코드를 생성하기 전에 해당 사양을 철저히 검토할 책임이 있습니다. 타사 서비스나 공개 저장소에서 다운로드한 사양에는 컴파일 시 예상치 못한 동작을 일으키거나 유해한 결과를 초래할 수 있는 값이 포함되어 있을 수 있습니다. 외부 사양을 사용하기 전에 다음 사항을 검토하십시오:

• 예상치 못하거나 의심스러울 정도로 복잡한 서버 URL 패턴 및 변수 정의.
• 생성된 소스 코드에 나타나서는 안 되는 내용이 포함된 설명 필드 또는 확장 속성.
• 런타임 안정성에 영향을 줄 수 있는 지나치게 깊거나 순환적인 모델 참조.
• 의도된 요청 대상을 변경할 수 있는 서버 변수의 열거형 값 또는 기본값.

생성기는 사양에서 파생된 문자열을 통한 직접적인 코드 주입을 방지하기 위해 이스케이핑을 적용하지만, 악의적인 사양은 여전히 클래스 이름, 엔드포인트 URL, 데이터 흐름 및 운영 의미론을 포함하여 생성된 클라이언트의 구조와 동작을 제어합니다. 아무리 철저한 이스케이핑을 적용하더라도, 사전 검토 없이는 근본적으로 신뢰할 수 없는 사양을 안전하게 사용할 수 없습니다.

리소스 고갈 방지

OpenAPI 사양의 의미론적 내용을 검토하는 것 외에도, 신뢰할 수 없는 출처의 사양을 처리하는 사용자는 코드 생성 및 실행 중에 소비되는 리소스를 제한하는 것을 고려해야 합니다.

악의적으로 조작된 사양은, 예를 들어 극도로 복잡한 스키마 구조, 방대한 수의 참조, 또는 깊게 중첩된 모델을 통해 코드 생성 과정 자체에서 과도한 리소스 소모를 유발할 수 있습니다. 또한, 해당 사양이 리소스 집약적인 코드 경로나 데이터 구조를 트리거하도록 설계된 경우, 그러한 사양에서 파생된 생성된 코드는 런타임에 과도한 리소스를 소비하여 리소스 고갈이나 서비스 거부(DoS) 상황을 초래할 수 있습니다.

기본 YAML 파서는 과도한 별칭 확장(예: Billion Laughs 공격), 깊게 중첩된 컬렉션, 재귀적 매핑 키 또는 비정상적으로 큰 문서와 같이 악의적인 YAML 입력으로 인한 서비스 거부(DoS) 공격을 완화하는 데 도움이 되는 여러 구성 옵션을 지원합니다. 이러한 제한 사항은 JVM 시스템 속성(예: JAVA_OPTIONS 또는 JAVA_TOOL_OPTIONS 사용)을 통해 구성할 수 있으며, 여기에는 다음이 포함됩니다:

// Declaration (also called an anchor)
original: &name "John"
// Usage
copy: *name

예시:

qt_add_openapi_client(Example
    SPEC_FILE
        ${CMAKE_CURRENT_SOURCE_DIR}/unstructed-source-spec.yaml
    JAVA_OPTIONS
        -DmaxYamlAliasesForCollections=10
        -DmaxYamlDepth=100
        -DmaxYamlCodePoints=5000000
        -DmaxYamlReferences=10
        -DsupportYamlAnchors=false
    OUTPUT_DIRECTORY
        ${CMAKE_CURRENT_BINARY_DIR}
)

YAML 파서는 구문 수준의 공격은 차단하지만, 리소스 고갈의 모든 변형을 방지할 수는 없습니다. 파서나 OpenAPI Generator 모두 스키마의 복잡성을 제한하지 않으며, $ref 체인의 깊이를 측정하거나, 결과 C++ 구조체가 소비할 스택 공간을 계산하지도 않습니다. 따라서 코드 생성 및 컴파일이 성공적으로 이루어졌다고 해서 런타임 안전성이 보장되는 것은 아닙니다. 프로덕션 네트워크 트래픽을 처리할 때, 애플리케이션은 다음 두 가지 중대한 공격 경로에 여전히 취약합니다:

• 수평적 확장(광범위한 페이로드) — 스키마는 중첩 깊이가 최소일지라도 엄청난 수의 동급 객체를 허용할 수 있습니다. 런타임에 이를 파싱하려면 과도한 힙 할당이 필요하며, 이는 심각한 메모리 조각화나 메모리 부족(OOM) 오류를 유발합니다.
• 수직 심화(깊은 페이로드) - 스키마가 컴파일을 통과하는 깊게 중첩된 배열의 배열이나 객체 체인을 유효하게 정의할 수 있습니다. 그러나 이러한 깊이를 악용하는 악성 페이로드가 네트워크를 통해 유입되면, 런타임 파서의 재귀적 실행으로 인해 스레드의 고정된 스택 공간이 급속히 소진되어 복구 불가능한 스택 오버플로우가 발생합니다.

신뢰할 수 없는 출처의 사양을 처리하는 애플리케이션의 경우, 사용자는 생성기를 호출하기 전에 사양에 대한 추가적인 수동 검토를 수행해야 합니다. 다음 사항을 확인하는 것을 고려하십시오:

네트워크 통신

생성된 클라이언트는 QNetworkAccessManager 를 사용하여 HTTP 요청을 수행합니다. 자격 증명(API 키, 베어러 토큰, 기본 인증)은 발신 요청에 첨부됩니다. 이 라이브러리는 HTTPS를 강제하지 않으므로, 애플리케이션은 자격 증명이 보안 연결을 통해서만 전송되도록 보장해야 합니다.