Qt共有セキュリティモデル

Qt共有セキュリティモデルは、Qtアプリケーション開発者、Qtフレームワークの提供者であるQt GroupおよびQt Project、ならびに運用事業者やデバイスメーカーの間でのセキュリティ責任の分担を定義するものです。このモデルは、一般的なQtアプリケーションやデバイスにおける技術スタックの各層にわたるセキュリティ責任について、明確な指針を定めています。

このページは、Qtアプリケーションを構築する開発者や、Qtのセキュリティ問題を報告するセキュリティ研究者向けの指針を提供します。

概要

Qtアプリケーションにおけるセキュリティは、共同責任です。Qtは安全なフレームワークやライブラリを提供しますが、アプリケーションの最終的なセキュリティは、開発者がこれらのコンポーネントをどのように使用し、アプリケーション固有の課題にどのように対処するかによって決まります。

一般的な Qt アプリケーションは、次のようなスタックとしてイメージすることができます：

役割と責任

アプリケーション開発者の責任

アプリケーション開発者であるあなたは、アプリケーション固有のコード、アセット、および設定のセキュリティに責任を負います。また、アプリケーションに同梱されるスタンドアロンのサードパーティ製ライブラリについても責任を負います。

Qtは、ユーザーフレンドリーで「デフォルトで安全な」APIの提供を目指しています。しかし、APIを注意深く使用し、例えばエラー状態をチェックして適切に処理することは、あなたの責任です。Qt使用時のセキュリティ上の考慮事項の概要については、「Qtにおけるセキュリティ」を参照してください。

アプリケーションにおいて、どのデータソースが信頼できるか、どのデータソースが信頼できないかを確認してください。信頼できないデータについては、適切な Qt API を使用して検証およびサニタイズを行うようにしてください。詳細については、「信頼できないデータの取り扱い」も参照してください。

アプリケーションを更新し、Qtのセキュリティ更新プログラムを適時に適用するための仕組みを計画してください。Qtのリリース情報やセキュリティに関する発表をフォローし、それに応じてQtを更新してください。また、信頼できるソースからQtを入手するようにしてください。

これは、ビルドするプロジェクトについても同様です。Qtの開発者ツールはビルドマシン上で実行され、処理するプロジェクトを信頼できる入力として扱うため、信頼できるソースからのプロジェクトのみをビルドしてください。詳細については、「Qtの開発者ツールの安全な使用」を参照してください。

アプリケーションの一部として Qt を同梱する場合は、ライブラリやプラグインの数を制限し、攻撃対象領域を縮小してください。たとえば、実際に必要なフォーマットに対応した画像プラグインのみを同梱するようにしてください。

Qtのデフォルト設定を変更する際は、誤ってセキュリティ機能を無効にしたり、セキュリティ保証を弱めたりしないよう注意してください。例えば、非常に正当な理由がない限り、SSL/TLS証明書の検証を無効にしないでください。もう1つの例として、qt.confなどを通じてQtの検索パスを変更する場合が挙げられます。すべてのパスが信頼できるものであることを確認してください。

Qtの責任

Qt Group および Qt Project は、公式に配布されるすべてのバイナリおよび再配布可能ファイルを含め、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 Group および Qt Project は、以下の条件を満たすセキュリティ問題を承認します：

• Qt フレームワークのコードに影響を与えるもの：Qt 独自のコードにおける脆弱性。これには、メモリ破損バグ、型混同、use-after-free、バッファオーバーフロー、および Qt ライブラリにおける同様のメモリ安全性の問題が含まれます。
• バンドルされたサードパーティ製コンポーネントに影響を与えるもの：Qtにバンドルされているサードパーティ製ライブラリおよびコンポーネントにおけるセキュリティ脆弱性。
• セキュリティ保証の破綻：Qt APIが文書化されたセキュリティ保証を提供できない、あるいはセキュリティ上重要なAPIに対する合理的なセキュリティ期待に違反する問題。
• デフォルト設定に影響するもの：開発者の介入なしに一般的なアプリケーションに影響を及ぼす可能性のある、Qtのデフォルト設定におけるセキュリティ上の問題。

また、Qt では、セキュリティ問題には現実的な攻撃シナリオが存在することが求められます。実際には悪用できない問題や、非現実的な条件を必要とする問題は、欠陥として扱われますが、セキュリティ問題とは見なされません。

Qtが受理しない問題

Qt Group および Qt Project は、以下のセキュリティ問題に関する報告を受け付けません。

• 安全でないアプリケーションコードを必要とするもの: アプリケーション開発者が安全でないコードを記述した場合、またはドキュメントや確立されたベストプラクティスに沿わない方法で Qt API を誤用した場合にのみ発生する問題。
• アプリケーション固有のロジックの欠陥に基づくもの：認証のバイパス、認可の欠陥、ビジネスロジックの脆弱性など、アプリケーション固有のロジックにおけるセキュリティ上の問題。
• 悪意のあるアプリケーションコードに依存するもの：アプリケーションが悪意のあるコードを実行することを必要とする問題。Qtは、アプリケーション開発者が自身のコードとリソースを管理していることを前提としています。
• 悪意のあるQML/JavaScriptを必要とするもの： Qt Qml すべてのQMLおよびJavaScriptコードはアプリケーション開発者によって提供されるものと想定しています。信頼できないQMLコードの実行はサポートされていません。詳細については、「信頼できないデータの取り扱い」を参照してください。
• 動作環境の問題に依存するもの：Qt に同梱されていない、基盤となるオペレーティングシステム、ハードウェア、またはシステムライブラリにおける脆弱性。
• 安全でないプロセス環境に依存する：PATH やQT_PLUGIN_PATH 環境変数内の信頼できないディレクトリなど、安全でないプロセス環境を必要とする攻撃は、Qtのセキュリティ責任の範囲外です。
• 非公開の Qt ヘッダーに依存するもの：非公開ヘッダーの使用は Qt の本来の目的に反しており、サポート対象外の構成です。非公開ヘッダーの使用によってのみ到達可能な脆弱性は、Qt のサイバーセキュリティリスク評価の基礎となる本来の目的およびサポート対象の使用条件の範囲外であるため、脆弱性としては扱われません。 とはいえ、そのような弱点に関する報告は、Qtの堅牢性を向上させる機会を示す可能性があるため、歓迎します。
• Qtのライブラリ、プラグイン、またはツールに影響を与えないもの：Qtの自動テスト、およびQtのビルドとリリースに使用されるインフラストラクチャは、展開される製品の一部ではありません。 これらを通じてのみ到達可能な弱点は、Qt における脆弱性とは扱われません。Qt に同梱されているビルドシステムファイルおよびツールは対象範囲に含まれます。「Qt の開発者ツールを安全に使用する方法」を参照してください。
• サンプルコードにのみ影響するもの：Qt のサンプルは API の使用法を説明するためのものであり、本番環境での使用を意図したものではありません。サンプル内の脆弱性は、セキュリティ上の脆弱性ではなく欠陥として扱われますが、サンプルはアプリケーションにコピーされることが多いため、報告は歓迎されます。

さらに、サイバーセキュリティ問題に関する報告には、以下の条件を満たす現実的な攻撃シナリオが必要です。

• セキュリティ境界を越えること：攻撃者が、それまで持っていなかった権限、アクセス権、または信頼を得た場合に、その問題はセキュリティ境界を越えたものとみなされます。例えば、攻撃者がすでにアプリケーションプロセスへのアクセス権を持ち、コードを実行できることを前提とする問題は、攻撃者がすでにそのアクセス権を持っているため、セキュリティ問題とは見なされません。
• ソーシャルエンジニアリングに基づいていない：Qtの技術的な脆弱性ではなく、主にソーシャルエンジニアリングやユーザーを騙すことに依存している問題。

よくある質問

ユーザー入力の検証責任は誰にあるのか？

ユーザー入力の検証は、アプリケーション開発者の責任です。Qt には検証ツール（QValidator およびQML Validators を参照）が用意されていますが、これらのツールを適切に使用し、アプリケーション固有の検証ロジックを実装するのは、アプリケーション側の責任です。

Qt SQL インジェクションの脆弱性について責任を負いますか？

いいえ。SQLインジェクションの脆弱性は、通常、SQL APIの不適切な使用に起因します。開発者は、SQLインジェクションを防ぐために、パラメータ化クエリやプリペアードステートメント（QSqlQuery::prepare など）を使用する必要があります。ただし、これらのセキュアなAPIが正しく機能することを保証するのはQtの責任です。

Qt アプリケーションにおけるクロスサイトスクリプティング（XSS）についてはどうでしょうか？

XSSの防止は、主にアプリケーション開発者の責任です。開発者は、特にWebビューやリッチテキストコンポーネントにおいて、信頼できないコンテンツを表示する際、データを適切にサニタイズおよびエスケープする必要があります。Qtは、これを支援するためにQString::toHtmlEscaped のようなAPIを提供しており、 Qt WebEngine Webプラットフォームのセキュリティ機能を実装していますが、アプリケーション側がこれらを正しく使用する必要があります。

暗号化とセキュアな通信は誰が担当するのですか？

Qtとアプリケーション開発者の双方が責任を分担します：

• Qtは、安全なデフォルト設定を備えたセキュアなネットワークAPI（QSslSocket 、QNetworkAccessManager ）を提供しています。
• アプリケーション開発者は、これらのAPIを適切に使用し、証明書の検証を実装し、鍵を安全に管理し、機密データを適切に扱う必要があります。アプリケーションにOpenSSLを同梱する場合、それを最新の状態に保ち、セキュリティパッチを適用することも開発者の責任です。

信頼できないQMLコードの読み込みはセキュリティ上の問題となりますか？

信頼できないQMLコードの実行は明示的にサポートされておらず、QMLエンジンの誤用とみなされます。 Qt Qml は、すべての QML および JavaScript コードが信頼でき、アプリケーション開発者によって提供されているという前提で設計されています。アプリケーションで信頼できないコンテンツを読み込む必要がある場合は、適切なサンドボックス機構、またはカスタムドメイン固有言語 (DSL) などの代替アプローチを使用してください。

画像ファイルの脆弱性についてはどうですか？

Qt は、画像のデコードをセキュリティ上重要な API と見なしており、信頼できないソースからの画像ファイルを安全に解析する責任を負っています。Qt の画像デコーダにおけるセキュリティ上の問題（バッファオーバーフロー、クラッシュ、および類似の問題）は、Qt Group または Qt Project に報告してください。 ただし、アプリケーション側では、画像のソースを検証し、大容量の画像を適切に処理し、アプリケーション固有の画像セキュリティ上の懸念に対処する必要があります。

セキュリティ問題を報告するにはどうすればよいですか？

Qt Project へのセキュリティ問題の報告に関する詳細な手順については、「Qt のセキュリティ」ページの「セキュリティ問題の報告」をご覧ください。

どのバージョンの Qt にセキュリティ更新プログラムが提供されますか？

セキュリティ更新プログラムは、サポート対象の Qt バージョンに対して提供されます。サポート対象のバージョンについては「Qt リリース」を、サポート終了バージョンについては「拡張セキュリティメンテナンス」を参照してください。

その他のリソース

Qtのセキュリティに関する詳細については、以下を参照してください：

• Qt のセキュリティ
• 信頼できないデータの取り扱い
• アプリケーションの権限
• QUIP 15Qtプロジェクトのセキュリティポリシー
• Qt 製品における既知の脆弱性のリスト