Modèle de sécurité partagée Qt

Le modèle de sécurité partagée Qt définit la répartition des responsabilités en matière de sécurité entre les développeurs d’applications Qt, le groupe Qt et le projet Qt en tant que fournisseurs du framework Qt, ainsi que les opérateurs ou les fabricants d’appareils. Ce modèle établit des attentes claires concernant la responsabilité en matière de sécurité à travers les différentes couches de la pile technologique d’une application ou d’un appareil Qt type.

Cette page fournit des conseils aux développeurs qui créent des applications Qt ainsi qu’aux chercheurs en sécurité qui signalent des failles de sécurité dans Qt.

Présentation

La sécurité dans les applications Qt relève d’une responsabilité partagée. Qt fournit des frameworks et des bibliothèques sécurisés, mais la sécurité finale d’une application dépend de la manière dont les développeurs utilisent ces composants et dont ils gèrent les problèmes spécifiques à l’application.

Une application Qt typique peut être représentée sous la forme d’une pile :

Rôles et responsabilités

Responsabilités du développeur d'applications

En tant que développeur d’application, vous êtes responsable de la sécurité du code, des ressources et de la configuration propres à l’application. Vous assumez également la responsabilité de toutes les bibliothèques tierces autonomes fournies avec l’application.

Qt vise à fournir une API conviviale et sécurisée par défaut. Cependant, il vous incombe d’utiliser cette API avec diligence, notamment en vérifiant les conditions d’erreur et en les gérant de manière appropriée. Pour un aperçu des considérations de sécurité lors de l’utilisation de Qt, consultez la section Sécurité dans Qt.

Vérifiez dans votre application quelles sources de données sont fiables et lesquelles ne le sont pas. Veillez à valider et à nettoyer les données non fiables à l’aide des API Qt appropriées. Consultez également la section « Gestion des données non fiables » pour plus d’informations.

Prévoyez des mécanismes pour mettre à jour l’application et appliquer les mises à jour de sécurité de Qt en temps opportun. Suivez les versions de Qt et les annonces de sécurité, et mettez à jour Qt en conséquence. Veillez également à vous procurer Qt auprès d’une source fiable.

Il en va de même pour les projets que vous compilez. Les outils de développement de Qt s'exécutent sur votre machine de compilation et traitent le projet qu'ils traitent comme une entrée fiable ; ne compilez donc que des projets provenant de sources auxquelles vous faites confiance. Pour plus d'informations, consultez la section « Utilisation sécurisée des outils de développement de Qt ».

Si vous intégrez Qt à votre application, limitez le nombre de bibliothèques et de plugins afin de réduire la surface d'attaque. Par exemple, n'intégrez que les plugins d'image correspondant aux formats dont vous avez réellement besoin.

Lorsque vous modifiez les paramètres par défaut de Qt, veillez à ne pas désactiver accidentellement des fonctionnalités de sécurité ou à ne pas affaiblir les garanties de sécurité. Par exemple, ne désactivez pas la validation des certificats SSL/TLS, sauf si vous avez une très bonne raison de le faire. Un autre exemple concerne les modifications apportées aux chemins de recherche de Qt, par exemple via le fichier qt.conf. Assurez-vous que tous les chemins sont fiables.

Responsabilités de Qt

Le Groupe Qt et le Projet Qt sont responsables de la sécurité du framework Qt lui-même, y compris de tous les binaires et éléments redistribuables officiellement distribués. Cela inclut la maintenance et la mise à jour de tout composant tiers fourni avec les bibliothèques et les plugins Qt, le suivi des vulnérabilités connues et la fourniture de correctifs en temps opportun.

Qt vise à fournir des API sécurisées par défaut. Les cas d’utilisation courants sont conçus pour minimiser le risque d’utilisation abusive, tandis que les opérations ayant des implications en matière de sécurité nécessitent une action explicite de la part du développeur.

Qt fournit des API qu’un développeur peut utiliser pour traiter et valider des données provenant de sources non fiables, telles que les entrées utilisateur, les communications réseau ou les fichiers externes. Lorsqu’il n’est pas raisonnable pour un développeur de mettre en œuvre sa propre validation, Qt fournit une validation intégrée. Par exemple, les décodeurs d’images de Qt sont conçus pour analyser les fichiers image en toute sécurité. Il peut toutefois exister des API pour lesquelles aucune de ces deux options n’est possible ou raisonnable ; dans ces cas-là, la documentation met en garde contre l’appel de l’API avec des données non fiables.

Responsabilités de l’opérateur ou du fabricant de l’appareil

Qt et l’application doivent toutes deux s’appuyer sur la sécurité et l’intégrité de l’environnement d’exécution (matériel, système d’exploitation et services). Sur les systèmes de bureau, cette responsabilité incombe généralement à l’opérateur de l’application ; par exemple, en veillant à ce que le système d’exploitation soit à jour. Sur les appareils embarqués, elle incombe au fabricant de l’appareil.

Cela inclut l’environnement de processus dans lequel l’application Qt s’exécute. Par exemple, toutes les applications de bureau partent du principe que les répertoires spécifiés dans la variable PATH sont fiables.

Hypothèses

Les garanties de sécurité de Qt et les critères d’acceptation ci-dessous reposent sur les hypothèses de base suivantes concernant l’environnement dans lequel s’exécute une application Qt. Si l’une de ces hypothèses ne se vérifie pas, les problèmes associés ne relèvent pas de l’objectif visé ni des conditions d’utilisation prises en charge sur lesquelles repose l’évaluation des risques de cybersécurité de Qt, et ne sont donc pas considérés comme des vulnérabilités dans Qt.

• L’attaquant ne contrôle pas déjà l’appareil ou le compte: Qt ne protège pas contre un attaquant qui dispose déjà d’un contrôle physique ou à distance de l’appareil sur lequel l’application s’exécute, ou du compte utilisateur sous lequel elle s’exécute (par exemple, un appareil volé ou déverrouillé, une session de bureau à distance ouverte ou un compte compromis), qu’il puisse ou non accéder au processus de l’application lui-même. Le critère déterminant est de savoir si l’attaquant obtient des privilèges, un accès ou une confiance dont il ne disposait pas auparavant. Lorsqu’un acteur local non privilégié acquiert les privilèges de l’application ou l’influence par le biais de données implantées à un emplacement lu par l’application, une limite de sécurité a été franchie et le problème entre dans le champ d’application, même si l’attaque est locale. Voir également les problèmes que Qt n'accepte pas.
• Le système d’exploitation et son environnement sont correctement configurés: Qt part du principe que le système d’exploitation, sa configuration et l’environnement du processus (tels que les variables ` PATH ` et ` QT_PLUGIN_PATH `) n’ont pas été altérés ni mal configurés. Voir Responsabilités de l’opérateur ou du fabricant de l’appareil.
• Le matériel exposé est authentique: Qt part du principe que le matériel avec lequel l’application interagit (périphériques, capteurs ou autres appareils connectés) est authentique et n’a pas été substitué ni compromis physiquement. Cela ne s’étend pas aux données envoyées par ce matériel : les entrées provenant de périphériques externes ne sont pas fiables, et les vulnérabilités accessibles par leur intermédiaire restent dans le champ d’application. Voir « Gestion des données non fiables ».

Critères d’acceptation des problèmes de sécurité

Les chercheurs en sécurité doivent suivre les directives suivantes pour déterminer si un problème de sécurité potentiel doit être signalé au projet Qt :

Problèmes acceptés par Qt

Le Groupe Qt et le Projet Qt acceptent les problèmes de sécurité qui :

• Affectent le code du framework Qt: les vulnérabilités présentes dans le code propre à Qt, notamment les bogues de corruption de mémoire, les confusions de types, les utilisations après libération, les débordements de tampon et autres problèmes similaires liés à la sécurité de la mémoire dans les bibliothèques Qt.
• Affectent les composants tiers intégrés: les failles de sécurité dans les bibliothèques et composants tiers intégrés à Qt.
• Enfreignent les garanties de sécurité: problèmes pour lesquels les API Qt ne fournissent pas les garanties de sécurité documentées ou ne respectent pas les attentes raisonnables en matière de sécurité pour les API critiques.
• Affectent les configurations par défaut: problèmes de sécurité dans les configurations par défaut de Qt susceptibles d’affecter des applications courantes sans intervention du développeur.

Qt s'attend également à ce que les problèmes de sécurité s'inscrivent dans un scénario d'attaque réaliste. Les problèmes qui ne peuvent pas être exploités dans la pratique ou qui nécessitent des conditions irréalistes seront traités comme des défauts, mais ne seront pas considérés comme des problèmes de sécurité.

Problèmes que Qt n’acceptera pas

Le Groupe Qt et le Projet Qt n’acceptent pas les rapports concernant des problèmes de sécurité qui :

• Nécessitent un code d’application non sécurisé: les problèmes qui ne se manifestent que lorsque le développeur de l’application écrit du code non sécurisé ou utilise à mauvais escient les API Qt d’une manière non conforme à la documentation ou aux bonnes pratiques établies.
• Reposent sur des failles de logique spécifiques à l’application: les problèmes de sécurité liés à la logique propre à l’application, tels que les contournements d’authentification, les failles d’autorisation ou les vulnérabilités de la logique métier.
• Dépendent d’un code d’application malveillant: les problèmes qui nécessitent que l’application exécute du code malveillant. Qt part du principe que les développeurs d’applications contrôlent leur propre code et leurs propres ressources.
• Nécésitant du code QML/JavaScript malveillant: Qt Qml part du principe que tout le code QML et JavaScript est fourni par le développeur de l’application. L’exécution de code QML non fiable n’est pas prise en charge. Voir Gestion des données non fiables pour plus d’informations.
• Dépendant de problèmes dans l'environnement d'exploitation: vulnérabilités dans le système d'exploitation sous-jacent, le matériel ou les bibliothèques système qui ne sont pas fournis avec Qt.
• Dépend d’un environnement de processus non sécurisé: les attaques nécessitant un environnement de processus non sécurisé, telles que des répertoires non fiables dans les variables d’environnement ` PATH ` ou ` QT_PLUGIN_PATH `, ne relèvent pas de la responsabilité de Qt en matière de sécurité.
• Liées à des en-têtes Qt privés: l’utilisation d’en-têtes privés est contraire à l’usage prévu de Qt et ne constitue pas une configuration prise en charge. Les faiblesses accessibles uniquement via l’utilisation d’en-têtes privés ne relèvent pas de l’usage prévu ni des conditions d’utilisation prises en charge sur lesquelles repose l’évaluation des risques de cybersécurité de Qt ; elles ne sont donc pas considérées comme des vulnérabilités. Nous encourageons néanmoins le signalement de ces faiblesses, car elles peuvent indiquer des possibilités d'améliorer la robustesse de Qt.
• N’affectent pas les bibliothèques, les plugins ou les outils de Qt: les autotests de Qt, ainsi que l’infrastructure utilisée pour compiler et publier Qt, ne font pas partie du produit tel qu’il est déployé. Les faiblesses accessibles uniquement par leur intermédiaire ne sont pas considérées comme des vulnérabilités dans Qt. Les fichiers et outils du système de compilation fournis avec Qt sont concernés ; voir « Utilisation sécurisée des outils de développement de Qt ».
• Ne concernent que le code d’exemple: les exemples de Qt illustrent l’utilisation de l’API et ne sont pas destinés à une utilisation en production. Les faiblesses qu’ils contiennent sont traitées comme des défauts plutôt que comme des vulnérabilités, mais les rapports sont les bienvenus, car ces exemples sont souvent copiés dans des applications.

De plus, les rapports concernant des problèmes de cybersécurité doivent inclure un scénario d'attaque réaliste qui

• franchit une frontière de sécurité: un problème franchit une frontière de sécurité lorsqu’il confère à l’attaquant des privilèges, un accès ou une confiance dont il ne disposait pas auparavant. Par exemple, les problèmes qui exigent qu’un attaquant ait déjà accès au processus de l’application et soit capable d’exécuter du code ne sont pas considérés comme des problèmes de sécurité, car l’attaquant dispose déjà de cet accès.
• Ne repose pas sur l’ingénierie sociale: les problèmes qui reposent principalement sur l’ingénierie sociale ou la manipulation des utilisateurs plutôt que sur des vulnérabilités techniques de Qt.

Foire aux questions

Qui est chargé de valider les données saisies par l’utilisateur ?

C'est au développeur de l'application qu'il incombe de valider les entrées utilisateur. Bien que Qt fournisse des outils de validation (voir QValidator et les validateurs QML), il appartient à l'application d'utiliser ces outils de manière appropriée et de mettre en œuvre une logique de validation spécifique à l'application.

Qt est-il responsable des vulnérabilités liées à l’injection SQL ?

Non. Les vulnérabilités par injection SQL résultent généralement d’une mauvaise utilisation des API SQL. Les développeurs doivent utiliser des requêtes paramétrées et des instructions préparées (telles que QSqlQuery::prepare) pour prévenir l’injection SQL. Cependant, Qt est chargé de s’assurer que ces API sécurisées fonctionnent correctement.

Qu'en est-il du cross-site scripting (XSS) dans les applications Qt ?

La prévention du XSS relève principalement de la responsabilité du développeur d’applications. Les développeurs doivent correctement nettoyer et échapper les données lors de l’affichage de contenu non fiable, en particulier dans les vues Web ou les composants de texte enrichi. Qt fournit des API telles que QString::toHtmlEscaped pour faciliter cette tâche, et Qt WebEngine implémente des fonctionnalités de sécurité de la plateforme web, mais l’application doit les utiliser correctement.

Qui se charge du chiffrement et de la sécurité des communications ?

La responsabilité est partagée entre Qt et le développeur de l’application :

• Qt fournit des API de réseau sécurisées (QSslSocket, QNetworkAccessManager) avec des paramètres par défaut sécurisés.
• Les développeurs d’applications doivent utiliser correctement ces API, mettre en œuvre la validation des certificats, gérer les clés en toute sécurité et traiter les données sensibles de manière appropriée. S’ils intègrent OpenSSL à l’application, il leur incombe également de le maintenir à jour et d’appliquer les correctifs de sécurité.

Le chargement de code QML non fiable constitue-t-il un risque de sécurité ?

L’exécution de code QML non fiable n’est explicitement pas prise en charge et est considérée comme une utilisation abusive du moteur QML. Qt Qml est conçu en partant du principe que tout le code QML et JavaScript est fiable et fourni par le développeur de l’application. Si votre application doit charger du contenu non fiable, utilisez des mécanismes de sandboxing appropriés ou des approches alternatives, comme un langage spécifique au domaine (DSL) personnalisé.

Qu’en est-il des vulnérabilités liées aux fichiers image ?

Qt considère le décodage d’images comme une API critique pour la sécurité et assume la responsabilité de l’analyse sécurisée des fichiers image provenant de sources non fiables. Les problèmes de sécurité dans les décodeurs d’images de Qt (débordements de tampon, plantages et problèmes similaires) doivent être signalés au Qt Group ou au Qt Project. Toutefois, les applications doivent toujours valider les sources des images, gérer correctement les images volumineuses et prendre en charge les problèmes de sécurité liés aux images spécifiques à l’application.

Comment signaler un problème de sécurité ?

Consultez la section « Signaler des problèmes de sécurité » de la page Sécurité dans Qt pour obtenir des instructions détaillées sur la manière de signaler des problèmes de sécurité au Qt Project.

Quelles versions de Qt bénéficient de mises à jour de sécurité ?

Des mises à jour de sécurité sont fournies pour les versions prises en charge de Qt. Consultez la section « Versions de Qt » pour obtenir des informations sur les versions prises en charge et la section « Maintenance de sécurité étendue » pour les versions en fin de support.

Ressources supplémentaires

Pour plus d’informations sur la sécurité dans Qt, consultez :

• Sécurité dans Qt
• Gestion des données non fiables
• Autorisations des applications
• QUIP 15 Politique de sécurité du projet Qt
• Liste des vulnérabilités connues dans les produits Qt