Considérations relatives à la sécurité de Qt OpenAPI

Gestion des spécifications OpenAPI provenant de sources externes

Le fichier de spécification OpenAPI constitue la principale source d’entrée du pipeline de génération de code. Il définit l’ensemble de la surface du client généré : points de terminaison de l’API, modèles de données, URL de serveur, schémas d’authentification et paramètres opérationnels. Étant donné que le générateur traduit directement le contenu de la spécification en code source C++, il ne doit être utilisé qu’avec des données d’entrée fiables.

Il incombe aux utilisateurs de vérifier toute spécification OpenAPI obtenue auprès d’une source externe avant de générer du code à partir de celle-ci. Une spécification téléchargée depuis un service tiers ou un référentiel public peut contenir des valeurs qui, une fois compilées, se comportent de manière inattendue ou nuisible. Avant d’utiliser une spécification externe, vérifiez qu’elle ne présente pas :

• Des modèles d’URL de serveur et des définitions de variables inattendus ou d’une complexité suspecte.
• Des champs de description ou des attributs d’extension contenant du contenu qui ne devrait pas apparaître dans le code source généré.
• Des références de modèle trop profondes ou circulaires susceptibles d’affecter la stabilité à l’exécution.
• Des valeurs d’énumération ou des valeurs par défaut de variables de serveur susceptibles de modifier les cibles de requête prévues.

Bien que le générateur applique un échappement pour empêcher l’injection directe de code via des chaînes dérivées de la spécification, une spécification malveillante contrôle toujours la structure et le comportement du client généré — y compris les noms de classes, les URL des points de terminaison, le flux de données et la sémantique opérationnelle. Aucun échappement ne peut rendre sûre l’utilisation d’une spécification fondamentalement non fiable sans examen préalable.

Protection contre l’épuisement des ressources

Outre l’examen du contenu sémantique d’une spécification OpenAPI, les utilisateurs traitant des spécifications provenant de sources non fiables devraient envisager de limiter les ressources consommées lors de la génération et de l’exécution du code.

Une spécification conçue de manière malveillante peut entraîner une consommation excessive de ressources pendant le processus de génération de code lui-même, par exemple via des structures de schémas extrêmement complexes, un grand nombre de références ou des modèles profondément imbriqués. De plus, le code généré à partir d’une telle spécification peut consommer des ressources excessives lors de l’exécution si la spécification est conçue pour déclencher des chemins de code ou des structures de données gourmands en ressources, ce qui peut entraîner un épuisement des ressources ou des conditions de déni de service.

L’analyseur YAML sous-jacent prend en charge plusieurs options de configuration permettant d’atténuer les attaques par déni de service causées par des entrées YAML malveillantes, telles que l’expansion excessive d’alias (par exemple, les attaques « Billion Laughs »), les collections profondément imbriquées, les clés de mappage récursives ou les documents d’une taille inhabituelle. Ces limites peuvent être configurées via les propriétés système de la JVM (par exemple, à l’aide de ` JAVA_OPTIONS ` ou ` JAVA_TOOL_OPTIONS`), notamment :

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

Exemple :

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}
)

Bien que l’analyseur YAML bloque les attaques au niveau syntaxique, il ne peut pas empêcher toutes les variantes d’épuisement des ressources. Ni l’analyseur ni l’OpenAPI Generator ne limitent la complexité du schéma, ne mesurent la profondeur des chaînes d’ $ref ni ne calculent l’espace de pile que la structure C++ résultante va consommer. Par conséquent, une génération et une compilation de code réussies ne garantissent pas la sécurité à l’exécution. Lors du traitement du trafic réseau en production, l’application reste vulnérable à deux vecteurs d’attaque critiques :

• Expansion horizontale (charges utiles étendues) : un schéma peut présenter une profondeur d’imbrication minimale tout en autorisant un nombre immense d’objets frères. L’analyse de ces éléments lors de l’exécution nécessite une allocation excessive de mémoire sur le tas, provoquant une fragmentation sévère de la mémoire ou des plantages dus à un manque de mémoire (OOM).
• Approfondissement vertical (charges utiles profondes) : un schéma peut valablement définir des tableaux de tableaux profondément imbriqués ou des chaînes d’objets qui passent la compilation. Cependant, lorsqu’une charge utile malveillante exploitant cette profondeur arrive sur le réseau, l’exécution récursive de l’analyseur d’exécution épuisera rapidement l’espace de pile fixe du thread, déclenchant un débordement de pile irrécupérable.

Pour les applications traitant des spécifications provenant de sources non fiables, les utilisateurs doivent procéder à une vérification manuelle supplémentaire de la spécification avant d’appeler le générateur. Pensez à vérifier les points suivants :

Communication réseau

Les clients générés effectuent des requêtes HTTP à l'aide de QNetworkAccessManager. Les identifiants (clés API, jetons « bearer », authentification de base) sont joints aux requêtes sortantes. La bibliothèque n'impose pas l'utilisation du protocole HTTPS ; les applications doivent s'assurer que les identifiants ne sont transmis que via des connexions sécurisées.