Qt Test Considérations relatives à la sécurité

Le framework Qt Test gère l'exécution des tests et génère des rapports sur leurs résultats. Lors de son utilisation, il convient de garder à l'esprit bon nombre des considérations relatives à l'utilisation sécurisée des outils de développement Qt. Comme expliqué dans le modèle de sécurité partagé de Qt pour Qt en général, les utilisateurs d'Qt Test doivent faire attention à la manière dont ils utilisent Qt Test et aux données qu'il va produire.

Une bonne suite de tests mettra, à certains moments, le code testé à rude épreuve et risquera donc d’entraîner des défaillances, notamment des plantages ou des comportements indéfinis. À mesure que le code testé évolue, cette suite permettra ainsi, de temps à autre, de détecter des erreurs avant qu’elles n’atteignent les utilisateurs finaux. De tels échecs peuvent avoir des effets secondaires inattendus, notamment la corruption d’autres ressources accessibles au processus de test, telles que le code source ou les artefacts de compilation.

L’échec d’un test peut s’accompagner d’informations supplémentaires décrivant la nature de l’échec. Même lorsque les tests réussissent, ceux-ci ou le code qu’ils testent peuvent générer des sorties, soit en déclenchant des messages d’avertissement ou de débogage, soit en réponse à des options de ligne de commande. La forme de ces données peut, dans certains cas, rendre leur intégration dans un rapport difficile, ou perturber la mise en forme de tout rapport dans lequel elles sont incluses, que ce soit directement par Qt Test ou par un autre processus utilisant les sorties générées par Qt Test.

Il est conseillé aux utilisateurs d’ Qt Test de garder ces points à l’esprit :

• Les résultats des tests peuvent contenir des données sensibles, les rendant ainsi accessibles à toute personne en mesure de les consulter.
• En particulier lorsque le code de test ou le code testé n’est pas considéré comme parfaitement fiable, les tests doivent être exécutés, dans la mesure du possible, par un processus sans privilèges et dans un environnement isolé (tel qu’une machine virtuelle) dont seul le rapport des résultats de test sera conservé après les tests.
• Il ne faut pas partir du principe que les éléments présents sur le système de test resteront tels qu’ils étaient avant l’exécution des tests.
• Bien qu’ Qt Test prenne toutes les précautions possibles pour échapper ou adapter les données qu’il intègre dans ses résultats de test, afin que ceux-ci respectent le format demandé, assurez-vous que les outils qui exploitent ces résultats sont robustes face aux types de résultats que vos tests pourraient produire.

Artefacts de la phase de compilation

Avant même la compilation du code de test, la configuration d’un test au moment de la compilation peut modifier l’environnement de compilation, par exemple en ajoutant à la configuration une dépendance vis-à-vis d’un logiciel impliqué dans les tests.

Il est donc important de comprendre les impacts que de telles adaptations peuvent avoir sur la compilation elle-même. Cela peut inclure des modifications de l’emplacement où les outils de compilation recherchent le code source à intégrer ou les bibliothèques à lier. Dans la mesure du possible, les adaptations nécessaires à un test ne doivent pas être appliquées à la compilation des livrables destinés aux utilisateurs finaux, mais uniquement à la compilation de chaque test qui en a besoin.

Ceci est particulièrement important lorsque les modifications apportées à la configuration de compilation proviennent de sources non fiables. De telles modifications ont déjà été impliquées dans des failles de sécurité de progiciels.

Considérations générales

Les tests automatisés ne sont pas une solution miracle. Les tests existants peuvent ne pas détecter des erreurs accidentelles ou des modifications malveillantes, et le simple fait d’exécuter des tests peut offrir à une telle modification l’occasion de causer des dommages. Les nouveaux tests ajoutés à la suite d’une modification du code testé peuvent ne pas détecter de problèmes importants dans cette modification, ni de problèmes dans le code existant qui apparaissent à la suite de celle-ci.

Le respect des bonnes pratiques décrites dans «Qt Test » peut contribuer à rendre le comportement des tests plus prévisible et à faciliter la prévention des risques, y compris ceux liés à la sécurité. Comme indiqué dans ce document, les dépendances externes peuvent entraîner des problèmes, comme décrit dans la section « Éviter les dépendances externes ».

Quant à l’utilisation sécurisée des outils de développement Qt, vous êtes responsable de l’intégrité de l’environnement de test, du code de test et du code testé. « Qt Test » n’est pas conçu pour faire face à un code de test ou à un code testé malveillant, mais uniquement pour fournir un cadre pratique permettant d’écrire des tests capables de générer des rapports informatifs en cas d’échec.

Séparer les versions de test et de production

Il est généralement prudent de compiler les artefacts logiciels destinés à la livraison séparément des artefacts de test et de stocker les artefacts de livraison dans un emplacement où ni la compilation des artefacts de test ni les effets de l’exécution des tests ne peuvent les perturber.

Cette séparation permet d’éviter les problèmes potentiels pouvant survenir en raison d’un dysfonctionnement lors de la compilation du test, du test lui-même ou du code testé. Tous ces éléments sont potentiellement capables de modifier des fichiers sur le disque. Cela peut constituer un risque particulier si l’une de ces étapes utilise une connexion réseau vers un serveur distant susceptible d’être compromis.

Les artefacts de test ne devraient normalement pas être nécessaires dans les systèmes de production. Lorsqu’il est nécessaire de tester sur des systèmes de production, il est prudent de regrouper les tests séparément du code qu’ils testent, afin de faciliter leur désinstallation une fois que les tests ont été exécutés sur le système pour vérifier que tout fonctionne correctement. Cela permet également de n’installer que les livrables principaux sur les copies du système de production, une fois qu’un nombre suffisant de copies a été testé pour s’assurer que tous les systèmes fonctionneront comme prévu.

Vérifier les noms des fichiers de sortie

Comme tout logiciel qui écrit dans des fichiers, les programmes d’ Qt Test ation disposent d’options permettant de contrôler l’emplacement et le format d’enregistrement des résultats.

Lorsque les noms des fichiers de sortie transmis à ces options sont générés automatiquement, par exemple par le système de compilation ou un système de gestion de la qualité exécutant les tests, il convient de veiller à ce que les noms générés correspondent bien à ce qui est prévu. Le système générant automatiquement ces noms doit vérifier que les noms qu’il produit répondent aux attentes et ne placent pas les données de sortie à des emplacements où elles pourraient être mal interprétées par d’autres systèmes, risqueraient d’écraser ou de remplacer des données provenant d’autres sources, ou seraient elles-mêmes susceptibles d’être écrasées ou remplacées par de telles données.