Qt Network Considérations de sécurité relatives à l'autorisation

Cette page couvre les considérations de sécurité pour les applications utilisant l'autorisationQt Network . Une grande partie du contenu se concentre 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 à fournir des ressources aux utilisateurs à l'aide d'un système de vérification des identités et des permissions. Le contrôle d'accès comprend les services d'autorisation, d'authentification et de journalisation. Qt Network L'API d'autorisation met en œuvre le contrôle d'accès en se concentrant sur le cadre d'autorisation OAuth 2.0. Qt Network L'autorisation prend en charge le flux de code d'autorisation (avec PKCE) et le flux d'autorisation de l'appareil.

Pour les systèmes, une séparation délibérée en fonction des privilèges et des permissions est la première étape du contrôle d'accès. Les catégories d'utilisateurs peuvent dicter les groupes autorisés à accéder à certaines ressources et à certains services. De même, les autorisations sur les ressources ou les services peuvent dicter les actions disponibles sur ceux-ci. Ne demandez que les champs d'application OAuth dont votre application a besoin. La limitation du champ d'application réduit l'impact potentiel en cas de compromission des jetons.

Les systèmes doivent également mettre en œuvre la gestion des accès pour des raisons de flexibilité et de supervision. Le provisionnement de l'accès et des services doit faire partie de la conception du système afin qu'il soit facile d'ajouter ou de supprimer des utilisateurs et des ressources sans compromettre la sécurité. Les journaux d'activité facilitent les audits et l'analyse de la sécurité.

Le contrôle d'accès basé sur les rôles (RBAC) est un concept bien connu.

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 aux mauvais utilisateurs et peuvent entraîner l'exposition de données privées et l'exécution d'actions malveillantes.

Les applications connectées doivent vérifier l'identité des utilisateurs qui utilisent des ressources restreintes. Généralement, les applications vérifient les utilisateurs en contrôlant les informations d'identification de l'utilisateur, telles que le nom d'utilisateur et le mot de passe, dans une base de données existante. Cette méthode est vulnérable aux fausses authentifications et aux violations de données. De nombreuses techniques d'atténuation concernent le comportement de l'utilisateur et les applications peuvent mettre en œuvre des politiques de sécurité telles que l'exigence de mots de passe forts. Les applications peuvent utiliser les validateurs et les widgets de 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), peut minimiser la mauvaise gestion des mots de passe et des identités.

Qt Network L'autorisation peut récupérer des jetons Web JSON (JWT) par l'intermédiaire d'OpenID Connect, une couche d'identité au-dessus d'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'une plateforme de stockage sécurisée ou d'un système de cryptage. Ne stockez pas les jetons en texte clair.

Autorisation et fourniture de ressources

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

Par mesure de précaution, il convient d'effectuer des contrôles d'autorisation avant d'exécuter des actions susceptibles d'entraîner une mauvaise utilisation des ressources. Ce contrôle peut avoir lieu chaque fois que des 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 exécuter une action sur la ressource. Des contrôles d'autorisation supplémentaires peuvent être nécessaires en fonction de 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.

Utiliser un user-agent externe

Selon la RFC 8252, les applications peuvent utiliser un user-agent externe ou intégré pour le point de terminaison d'autorisation, comme défini dans OAuth 2.0. Les user-agents intégrés sont généralement les webviews fournies et contrôlées dans l'application. Les user-agents externes sont les navigateurs du système ou d'autres applications non contrôlées par l'application requérante.

LeRFC 8252 recommande d'utiliser des user-agents 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 n'est pas sûre, car l'application peut enregistrer les frappes au clavier et tromper les utilisateurs en leur donnant un faux sentiment de sécurité. WebEngine Cependant, des navigateurs intégrés correctement configurés comme Qt XML peuvent également être utilisés lorsque les user-agents externes ne sont pas pratiques.

De plus, lorsque le navigateur du système est l'agent utilisateur externe, les onglets du navigateur et les informations d'identification enregistrées peuvent simplifier l'expérience de l'utilisateur. Par exemple, les utilisateurs peuvent utiliser leurs noms d'utilisateur et leurs mots de passe enregistrés dans le navigateur. De même, l'utilisation de gestionnaires de mots de passe en tant qu'agent utilisateur externe accroît la simplicité et la confiance.

PKCE et paramètre d'état

Laclé de preuve pour l'échange de code (PKCE) protège contre les attaques d'interception du code d'autorisation dans le flux du code d'autorisation. Qt Network L'autorisation active la PKCE par défaut.

Qt Network L'autorisation génère des valeurs d'état aléatoires par défaut afin d'empêcher les attaques de type CSRF (cross-site request forgery). Si vous remplacez le paramètre state, évitez d'utiliser des chaînes codées en dur.

Considérations relatives aux plates-formes

La gestion des URI de redirection varie selon les plateformes. Sur les plateformes mobiles, les URI de redirection HTTPS peuvent être gérés en toute sécurité par le biais d'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 en matière de sécurité pour les applications connectées

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

• Common Weakness Enumeration - Un catalogue des problèmes connus et des techniques d'atténuation possibles.
• OWASP Cheat Sheet Series - Une liste de divers 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)