Qt 공유 보안 모델

Qt 공유 보안 모델은 Qt 애플리케이션 개발자, Qt 프레임워크 제공자인 Qt 그룹 및 Qt 프로젝트, 그리고 운영자 또는 기기 제조업체 간의 보안 책임 분담을 정의합니다. 이 모델은 일반적인 Qt 애플리케이션이나 기기의 기술 스택 전반에 걸쳐 보안 책임에 대한 명확한 기대치를 제시합니다.

이 페이지는 Qt 애플리케이션을 개발하는 개발자와 Qt의 보안 문제를 보고하는 보안 연구원을 위한 지침을 제공합니다.

개요

Qt 애플리케이션의 보안은 공동의 책임입니다. Qt는 안전한 프레임워크와 라이브러리를 제공하지만, 애플리케이션의 궁극적인 보안은 개발자가 이러한 구성 요소를 어떻게 사용하고 애플리케이션 고유의 문제를 어떻게 처리하는지에 달려 있습니다.

일반적인 Qt 애플리케이션은 다음과 같은 스택 구조로 시각화할 수 있습니다:

역할과 책임

애플리케이션 개발자의 책임

애플리케이션 개발자인 귀하는 애플리케이션 고유의 코드, 자산 및 구성의 보안을 책임져야 합니다. 또한 애플리케이션과 함께 제공되는 독립형 타사 라이브러리에 대한 책임도 귀하에게 있습니다.

Qt는 사용자 친화적이고 기본적으로 안전한(safe-by-default) API를 제공하는 것을 목표로 합니다. 그러나 API를 신중하게 사용하고, 예를 들어 오류 조건을 확인하고 적절하게 처리하는 것은 개발자의 책임입니다. Qt 사용 시 고려해야 할 보안 사항에 대한 개요는 Qt의 보안( Security in Qt)을 참조하십시오.

어떤 데이터 소스가 신뢰할 수 있는 것이고 어떤 것이 신뢰할 수 없는 것인지에 대해 애플리케이션을 검토하십시오. 적절한 Qt API를 사용하여 신뢰할 수 없는 데이터를 반드시 검증하고 정제하십시오. 자세한 내용은 ‘신뢰할 수 없는 데이터 처리’를 참조하십시오.

애플리케이션을 업데이트하고 Qt 보안 업데이트를 적시에 적용할 수 있는 체계를 마련하십시오. Qt 릴리스 및 보안 공지 사항을 주시하고, 그에 따라 Qt를 업데이트하십시오. 또한, 신뢰할 수 있는 출처에서 Qt를 입수해야 합니다.

이 원칙은 빌드하는 프로젝트에도 동일하게 적용됩니다. Qt 개발자 도구는 빌드 머신에서 실행되며, 처리하는 프로젝트를 신뢰할 수 있는 입력으로 간주하므로, 신뢰할 수 있는 소스의 프로젝트만 빌드해야 합니다. 자세한 내용은 ‘Qt 개발자 도구를 안전하게 사용하는 방법’을 참조하십시오.

애플리케이션의 일부로 Qt를 배포하는 경우, 공격 표면을 줄이기 위해 라이브러리와 플러그인의 수를 제한하십시오. 예를 들어, 실제로 필요한 형식에 대한 이미지 플러그인만 배포하십시오.

Qt의 기본 설정을 변경할 때는 실수로 보안 기능을 비활성화하거나 보안 보장을 약화시키지 않도록 주의하십시오. 예를 들어, 매우 타당한 이유가 없는 한 SSL/TLS 인증서 검증을 비활성화하지 마십시오. 또 다른 예로는 qt.conf 등을 통해 Qt 검색 경로를 변경하는 경우가 있습니다. 모든 경로가 신뢰할 수 있는지 확인하십시오.

Qt의 책임

Qt 그룹과 Qt 프로젝트는 공식적으로 배포되는 모든 바이너리 및 재배포 가능 파일을 포함하여 Qt 프레임워크 자체의 보안에 대한 책임을 집니다. 여기에는 Qt 라이브러리와 플러그인에 번들된 모든 타사 구성 요소의 유지 관리 및 업데이트, 알려진 취약점 추적, 그리고 적시적인 수정 제공이 포함됩니다.

Qt는 기본적으로 안전한 API를 제공하는 것을 목표로 합니다. 일반적인 사용 사례는 오용의 위험을 최소화하도록 설계되어 있는 반면, 보안에 영향을 미치는 작업의 경우 개발자의 명시적인 조치가 필요합니다.

Qt는 개발자가 사용자 입력, 네트워크 통신 또는 외부 파일과 같은 신뢰할 수 없는 출처의 데이터를 처리하고 유효성을 검사하는 데 사용할 수 있는 API를 제공합니다. 개발자가 자체적으로 유효성 검사를 구현하는 것이 비합리적인 경우, Qt는 내장된 유효성 검사 기능을 제공합니다. 예를 들어, Qt의 이미지 디코더는 이미지 파일을 안전하게 구문 분석하도록 설계되었습니다. 그러나 두 가지 방법 모두 불가능하거나 합리적이지 않은 API가 있을 수 있습니다. 이러한 경우, 문서에서는 신뢰할 수 없는 데이터로 API를 호출할 때 주의할 것을 경고합니다.

운영자 또는 기기 제조업체의 책임

Qt와 애플리케이션 모두 운영 환경(하드웨어, 운영 체제 및 서비스)의 보안과 무결성에 의존해야 합니다. 데스크톱 시스템의 경우, 이는 일반적으로 애플리케이션 운영자의 책임입니다. 예를 들어, 운영 체제를 최신 상태로 유지하는 것이 이에 해당합니다. 임베디드 기기의 경우, 이는 기기 제조사의 책임입니다.

여기에는 Qt 애플리케이션이 실행되는 프로세스 환경도 포함됩니다. 예를 들어, 모든 데스크톱 애플리케이션은 ` PATH ` 환경 변수에 지정된 디렉터리가 신뢰할 수 있다고 가정합니다.

가정

Qt의 보안 보장 사항과 아래의 수용 기준은 Qt 애플리케이션이 실행되는 환경에 대한 다음과 같은 기본 가정들에 기반합니다. 이러한 가정 중 하나라도 성립하지 않는 경우, 관련 문제는 Qt의 사이버 보안 위험 평가가 기반을 둔 의도된 목적 및 지원되는 사용 조건의 범위를 벗어나므로, Qt의 취약점으로 간주되지 않습니다.

• 공격자가 해당 기기나 계정을 이미 제어하고 있지 않은 경우: Qt는 애플리케이션이 실행되는 기기나 해당 애플리케이션이 실행되는 사용자 계정(예: 도난당했거나 잠금이 해제된 기기, 열린 원격 데스크톱 세션, 해킹당한 계정)에 대해 이미 물리적 또는 원격 제어권을 가진 공격자에 대해서는, 공격자가 애플리케이션 프로세스 자체에 접근할 수 있는지 여부와 무관하게 방어하지 않습니다. 핵심 판단 기준은 공격자가 기존에 가지고 있지 않았던 권한, 접근 권한 또는 신뢰 관계를 획득하게 되는지 여부입니다. 권한이 없는 로컬 행위자가 애플리케이션의 권한을 획득하거나, 애플리케이션이 읽는 위치에 심어진 데이터를 통해 애플리케이션에 영향을 미치는 경우, 비록 공격이 로컬에서 발생하더라도 보안 경계가 침해된 것이므로 해당 문제는 검토 대상에 포함됩니다. ‘Qt가 수용하지 않는 문제’ 항목도 참조하십시오.
• 운영 체제 및 그 환경이 올바르게 구성되어 있습니다: Qt는 OS, 그 구성, 그리고 프로세스 환경(예: ` PATH ` 및 ` QT_PLUGIN_PATH ` 변수)이 변조되거나 잘못 구성되지 않았다고 가정합니다. “운영자 또는 장치 제조업체의 책임”을 참조하십시오.
• 노출된 하드웨어는 정품입니다: Qt는 애플리케이션이 상호 작용하는 하드웨어(주변기기, 센서 또는 기타 연결된 장치)가 정품이며, 대체되거나 물리적으로 손상되지 않았다고 가정합니다. 이는 해당 하드웨어가 전송하는 데이터에는 적용되지 않습니다. 외부 장치에서 수신된 입력은 신뢰할 수 없는 입력이며, 이를 통해 접근 가능한 결함은 여전히 적용 범위에 포함됩니다. '신뢰할 수 없는 데이터 처리'를 참조하십시오.

보안 문제 접수 기준

보안 연구원은 잠재적인 보안 문제를 Qt 프로젝트에 보고해야 할지 여부를 결정할 때 다음 지침을 따라야 합니다:

Qt가 수용하는 문제

Qt 그룹과 Qt 프로젝트는 다음과 같은 보안 문제를 수용합니다:

• Qt 프레임워크 코드에 영향을 미치는 경우: 메모리 손상 버그, 타입 혼동, use-after-free, 버퍼 오버플로우 및 Qt 라이브러리의 유사한 메모리 안전성 문제를 포함하여 Qt 자체 코드의 취약점.
• 번들된 타사 구성 요소에 영향을 미치는 경우: Qt와 함께 번들된 타사 라이브러리 및 구성 요소의 보안 취약점.
• 보안 보장 위반: Qt API가 문서화된 보안 보장을 제공하지 못하거나, 보안이 중요한 API에 대한 합리적인 보안 기대치를 위반하는 문제.
• 기본 구성에 영향을 미치는 경우: 개발자의 개입 없이도 일반적인 애플리케이션에 영향을 미칠 수 있는 Qt 기본 구성의 보안 문제.

또한 Qt는 보안 문제에 대해 현실적인 공격 시나리오가 존재할 것을 기대합니다. 실제로 악용될 수 없거나 비현실적인 조건을 필요로 하는 문제는 결함으로 취급되지만, 보안 문제로 간주되지는 않습니다.

Qt가 접수하지 않는 문제

Qt 그룹 및 Qt 프로젝트는 다음과 같은 보안 문제에 대한 보고를 접수하지 않습니다:

• 안전하지 않은 애플리케이션 코드를 필요로 하는 경우: 애플리케이션 개발자가 안전하지 않은 코드를 작성하거나, 문서나 확립된 모범 사례에 부합하지 않는 방식으로 Qt API를 오용할 때만 발생하는 문제.
• 애플리케이션 고유의 논리적 결함에 기반한 경우: 인증 우회, 권한 부여 결함 또는 비즈니스 로직 취약점과 같이 애플리케이션 고유의 논리적결함에 기인한 보안 문제.
• 악성 애플리케이션 코드에 의존하는 경우: 애플리케이션이 악성 코드를 실행해야만 발생하는 문제. Qt는 애플리케이션 개발자가 자신의 코드와 리소스를 관리한다고 가정합니다.
• 악성 QML/JavaScript가 필요한 경우: Qt Qml 모든 QML 및 JavaScript 코드는 애플리케이션 개발자가 제공한다고 가정합니다. 신뢰할 수 없는 QML 코드의 실행은 지원되지 않습니다. 자세한 내용은 '신뢰할 수 없는 데이터 처리'를 참조하십시오.
• 운영 환경의 문제에 의존: Qt에 번들로 제공되지 않는 기본 운영 체제, 하드웨어 또는 시스템 라이브러리의 취약점.
• 안전하지 않은 프로세스 환경에 의존: ` PATH ` 또는 ` QT_PLUGIN_PATH ` 환경 변수에 지정된 신뢰할 수 없는 디렉터리와 같이 안전하지 않은 프로세스 환경을 필요로 하는 공격은 Qt의 보안 책임 범위 밖입니다.
• 비공개 Qt 헤더에 의존하는 경우: 비공개 헤더의 사용은 Qt의 의도된 목적에 위배되며 지원되지 않는 구성입니다. 비공개 헤더를 통해서만 노출되는 취약점은 Qt의 사이버 보안 위험 평가의 근거가 되는 의도된 목적 및 지원되는 사용 조건을 벗어난 것이므로, 취약점으로 간주되지 않습니다. 그럼에도 불구하고, 이러한 취약점에 대한 보고는 Qt의 견고성을 개선할 기회를 제시할 수 있으므로 환영합니다.
• Qt의 라이브러리, 플러그인 또는 도구에 영향을 미치지 않는 경우: Qt의 자동 테스트(autotests)와 Qt를 빌드 및 릴리스하는 데 사용되는 인프라는 배포된 제품의 일부가 아닙니다. 이를 통해서만 접근할 수 있는 취약점은 Qt에서 취약점으로 취급되지 않습니다. Qt와 함께 제공되는 빌드 시스템 파일 및 도구는 적용 대상에 포함됩니다. ‘Qt 개발자 도구를 안전하게 사용하기’를 참조하십시오.
• 예제 코드에만 영향을 미치는 경우: Qt의 예제는 API 사용법을 설명하기 위한 것이며, 실제 운영 환경에서 사용하기 위한 것이 아닙니다. 예제 내의 취약점은 보안 취약점보다는 결함으로 처리되지만, 예제가 종종 애플리케이션에 복사되어 사용되므로 보고를 환영합니다.

또한, 사이버 보안 문제에 대한 보고에는 다음과 같은 현실적인 공격 시나리오가 포함되어야 합니다.

• 보안 경계를 침범해야 합니다: 보안 경계를 침범한다는 것은 공격자에게 기존에 보유하지 않았던 권한, 접근권 또는 신뢰도를 부여하는 경우를 의미합니다. 예를 들어, 공격자가 이미 애플리케이션 프로세스에 접근할 수 있고 코드를 실행할 수 있어야만 발생하는 문제는 공격자가 이미 해당 접근권을 보유하고 있으므로 보안 문제로 간주되지 않습니다.
• 사회 공학에 기반하지 않은 것: Qt의 기술적 취약점보다는 주로 사회 공학이나 사용자를 속이는 방법에 의존하는 문제.

자주 묻는 질문

사용자 입력 검증을 누가 담당합니까?

애플리케이션 개발자가 사용자 입력을 검증할 책임이 있습니다. Qt는 검증 도구( QValidator 및 QML Validators 참조)를 제공하지만, 이러한 도구를 적절히 사용하고 애플리케이션에 특화된 검증 로직을 구현하는 것은 애플리케이션 개발자의 책임입니다.

Qt SQL 인젝션 취약점에 대한 책임이 있습니까?

아니요. SQL 인젝션 취약점은 일반적으로 SQL API의 부적절한 사용으로 인해 발생합니다. 개발자는 SQL 인젝션을 방지하기 위해 매개변수화된 쿼리와 준비된 문(예: QSqlQuery::prepare)을 사용해야 합니다. 그러나 이러한 보안 API가 올바르게 작동하도록 보장하는 것은 Qt의 책임입니다.

Qt 애플리케이션의 크로스 사이트 스크립팅(XSS)은 어떻게 되나요?

XSS 방지는 주로 애플리케이션 개발자의 책임입니다. 개발자는 신뢰할 수 없는 콘텐츠를 표시할 때, 특히 웹 뷰나 리치 텍스트 컴포넌트에서 데이터를 적절히 정제하고 이스케이프 처리해야 합니다. Qt는 이를 지원하기 위해 QString::toHtmlEscaped 과 같은 API를 제공하며, Qt WebEngine 웹 플랫폼 보안 기능을 구현하고 있지만, 애플리케이션 측에서 이를 올바르게 사용해야 합니다.

암호화 및 보안 통신은 누가 담당하나요?

Qt와 애플리케이션 개발자가 공동으로 책임을 집니다:

• Qt Network는 안전한 기본 설정이 적용된 보안 네트워킹 API(QSslSocket, QNetworkAccessManager)를 제공합니다.
• 애플리케이션 개발자는 이러한 API를 올바르게 사용하고, 인증서 유효성 검사를 구현하며, 키를 안전하게 관리하고, 민감한 데이터를 적절히 처리해야 합니다. 애플리케이션에 OpenSSL을 번들로 포함하는 경우, 이를 최신 상태로 유지하고 보안 패치를 적용하는 것도 개발자의 책임입니다.

신뢰할 수 없는 QML 코드를 로드하는 것이 보안 문제인가요?

신뢰할 수 없는 QML 코드의 실행은 명시적으로 지원되지 않으며, QML 엔진의 오용으로 간주됩니다. Qt Qml QML 및 JavaScript 코드는 모두 신뢰할 수 있으며 애플리케이션 개발자가 제공한다는 전제 하에 설계되었습니다. 애플리케이션에서 신뢰할 수 없는 콘텐츠를 불러와야 하는 경우, 적절한 샌드박싱 메커니즘이나 사용자 정의 도메인 특정 언어(DSL)와 같은 대체 방식을 사용하십시오.

이미지 파일의 취약점은 어떻게 되나요?

Qt는 이미지 디코딩을 보안상 중요한 API로 간주하며, 신뢰할 수 없는 출처의 이미지 파일을 안전하게 파싱할 책임을 집니다. Qt의 이미지 디코더에 대한 보안 문제(버퍼 오버플로, 충돌 및 이와 유사한 문제)는 Qt Group 또는 Qt Project에 보고해야 합니다. 그러나 애플리케이션은 여전히 이미지 소스를 검증하고, 대용량 이미지를 적절히 처리하며, 애플리케이션 고유의 이미지 보안 문제를 관리해야 합니다.

보안 문제를 어떻게 보고하나요?

Qt 프로젝트에 보안 문제를 보고하는 방법에 대한 자세한 지침은 Qt의 보안 페이지에 있는 ‘보안 문제 보고’를 참조하십시오.

어떤 버전의 Qt에 보안 업데이트가 제공됩니까?

보안 업데이트는 지원되는 Qt 버전에 대해 제공됩니다. 지원되는 버전에 대한 정보는 Qt 릴리스를, 지원이 종료된 버전에 대한 정보는 확장 보안 유지 관리 ( Extended Security Maintenance )를 참조하십시오.

추가 자료

Qt 보안에 대한 자세한 내용은 다음을 참조하십시오:

• Qt의 보안
• 신뢰할 수 없는 데이터 처리
• 애플리케이션 권한
• QUIP 15 Qt 프로젝트 보안 정책
• Qt 제품에서 알려진 취약점 목록