Qt Network Authorization Considérations relatives à la sécurité

Cette page traite des considérations de sécurité relatives aux applications utilisant Qt Network Authorization. Une grande partie du contenu présenté ici porte sur le cadre d'autorisation OAuth 2.0 et OpenID.

Reportez-vous à la RFC 6749 pour le flux du protocole OAuth 2.0 et à la RFC 8252 pour les questions de sécurité concernant les applications natives.

Contrôle d’accès

Le contrôle d’accès consiste à attribuer des ressources aux utilisateurs à l’aide d’un système de vérification des identités et des autorisations. Il englobe donc les services d’autorisation, d’authentification et de journalisation. L’API de Qt Network Authorization met en œuvre le contrôle d’accès en s’appuyant principalement sur le cadre d’autorisation OAuth 2.0. Qt Network Authorization prend en charge le flux « Code d’autorisation » (avec PKCE) et le flux « Autorisation d’appareil ».

Pour les systèmes, une séparation délibérée en fonction des privilèges et des autorisations constitue la première étape du contrôle d’accès. Les catégories d’utilisateurs peuvent déterminer les groupes autorisés à accéder à certaines ressources et à certains services. De même, les autorisations sur les ressources ou les services peuvent définir les actions disponibles sur celles-ci. Ne demandez que les périmètres OAuth dont votre application a besoin. Limiter le périmètre réduit l’impact potentiel en cas de compromission des jetons.

Les systèmes doivent également mettre en œuvre une gestion des accès pour garantir flexibilité et supervision. L’attribution des accès et des services doit faire partie intégrante de la conception du système afin de faciliter l’ajout ou la suppression d’utilisateurs et de ressources sans compromettre la sécurité. Les journaux d’activité facilitent les audits et les analyses de sécurité.

Le contrôle d’accès basé sur les rôles (RBAC) est une architecture bien connue.

Authentification et authentification unique

L’authentification consiste à vérifier l’identité d’un utilisateur. Des méthodes d’authentification faibles conduisent à accorder l’accès à de mauvais utilisateurs et peuvent entraîner la divulgation de données privées ainsi que l’exécution d’actions malveillantes.

Les applications connectées doivent vérifier l’identité des utilisateurs qui accèdent à des ressources restreintes. En général, les applications vérifient l’identité des utilisateurs en contrôlant leurs identifiants (nom d’utilisateur et mot de passe) dans une base de données existante. Cette méthode est vulnérable aux fausses authentifications et aux fuites de données. De nombreuses techniques d’atténuation portent sur le comportement des utilisateurs, et les applications peuvent appliquer des politiques de sécurité, comme l’exigence de mots de passe forts. Les applications peuvent utiliser les validateurs et les Qt Widgets pour guider les utilisateurs à l’aide de messages et en limitant la création de mots de passe faibles.

L’utilisation d’un système d’authentification centralisé, tel que l’authentification unique (SSO), permet de minimiser les erreurs de gestion des mots de passe et des identités.

Qt Network Authorization Il est possible de récupérer des jetons Web JSON (JWT) via OpenID Connect, une couche d’identité s’appuyant sur OAuth 2.0. Souvent, l’authentification et l’autorisation font partie du même système. Traitez les jetons d’accès, les jetons de rafraîchissement et les jetons d’identification comme des données sensibles. Stockez-les en toute sécurité à l’aide d’un stockage sécurisé de la plateforme ou d’un chiffrement. Ne stockez pas les jetons en texte clair.

Autorisation et mise à disposition des ressources

L’autorisation consiste à vérifier si un utilisateur a accès à une ressource en fonction de ses privilèges et autorisations sur cette ressource. Sans autorisation appropriée, les utilisateurs peuvent accéder à une ressource et effectuer des actions même s’ils n’en ont pas l’autorisation. Les attaquants peuvent modifier et compromettre l’intégrité des données ou abuser des ressources, provoquant ainsi un déni de service.

Par mesure de précaution élémentaire, effectuez des contrôles d’autorisation avant d’exécuter des actions susceptibles d’entraîner une utilisation abusive des ressources. Ce contrôle peut avoir lieu chaque fois que les utilisateurs accèdent à des ressources côté serveur. Les privilèges des utilisateurs et les autorisations sur les ressources déterminent si l’utilisateur peut effectuer une action sur la ressource. Des contrôles d’autorisation supplémentaires peuvent s’avérer nécessaires selon la ressource. Révoquez les jetons d’accès et de rafraîchissement lorsque les utilisateurs se déconnectent ou lorsque votre application n’en a plus besoin.

Utilisez un agent utilisateur externe

Conformément à la RFC 8252, les applications peuvent utiliser soit un agent utilisateur externe, soit un agent utilisateur intégré pour le point de terminaison d’autorisation, tel que défini dans OAuth 2.0. Les agents utilisateurs intégrés sont généralement les vues Web fournies et contrôlées au sein de l’application. Les agents utilisateur externes sont les navigateurs système ou d’autres applications non contrôlées par l’application requérante.

La RFC 8252 recommande d’utiliser des agents utilisateur externes plutôt que des vues Web intégrées pour l’autorisation. L’application contrôle l’agent utilisateur intégré et ne parvient pas à séparer l’accès privilégié entre l’application et le nœud d’autorisation. Cette configuration est peu sûre, car l’application peut enregistrer les frappes au clavier et donner aux utilisateurs un faux sentiment de sécurité. Cependant, des navigateurs intégrés correctement configurés, tels que Qt WebEngine, peuvent également être utilisés lorsque les agents utilisateurs externes ne sont pas pratiques.

De plus, lorsque le navigateur système sert d’agent utilisateur externe, les onglets du navigateur et les identifiants enregistrés peuvent simplifier l’expérience utilisateur. Par exemple, les utilisateurs peuvent utiliser leurs noms d’utilisateur et mots de passe enregistrés dans le navigateur. De même, l’utilisation de gestionnaires de mots de passe comme agent utilisateur externe renforce la simplicité et la confiance.

PKCE et paramètre d’état

Le protocolePKCE (Proof Key for Code Exchange) protège contre les attaques par interception de code d’autorisation dans le flux de code d’autorisation. Qt Network Authorization active le PKCE par défaut.

Qt Network Authorization génère par défaut des valeurs d’état aléatoires afin de prévenir les attaques de falsification de requêtes intersites (CSRF). Si vous remplacez le paramètre d’état, évitez d’utiliser des chaînes de caractères codées en dur.

Considérations relatives à la plateforme

La gestion des URI de redirection varie selon les plateformes. Sur les plateformes mobiles, les URI de redirection HTTPS peuvent être gérées en toute sécurité via des URL revendiquées par l’application. Sur les plateformes de bureau, les URI de redirection HTTP vers localhost restent une option valable pour les applications natives.

Ressources de sécurité pour les applications connectées

Voici des ressources contenant des conseils en matière de cybersécurité :

• Common Weakness Enumeration (CWE) – Un catalogue des vulnérabilités connues et des techniques d’atténuation possibles.
• Série d’aide-mémoire OWASP – Une liste de différents sujets relatifs à la sécurisation des applications.
• RFC 6749 - Cadre d'autorisation OAuth 2.0
• RFC 8252 – OAuth 2.0 pour les applications natives
• RFC 7636 - Clé de preuve pour l'échange de code (PKCE)