Il y a beaucoup de discussions dans presque tous les forums sur la sécurité des applications web (en ne tenant pas compte des applications mobiles) en utilisant spécialement oauth2 et jwt. Tout le monde a mis leurs commentaires/réponses ceci et cela, bla..blah..blah à propos des jetons de sécurité (en supposant que presque tout le web précieux serait devenu apatride d'ici la fin de '2016'). Sérieusement, je ne sais pas si c'est si facile, j'ai trouvé tout le monde écrit leurs réponses contre un attaquant imaginaire comme si il est si détendu et facile pour les attaquants de voler l'application web côté utilisateur access_token et refresh_token. Quelles sont les différentes manières possibles pour qu'un pirate puisse réellement compromettre votre application Web? Access_token et refresh_token du côté client? Ce type de compromis dépend également de l'utilisateur qui utilise l'application Web? Avec quelle facilité un attaquant peut-il espionner les communications entre le client et le serveur d'autorisation? Tous les exemples de code ouvert, si quelqu'un veut montrer sera hautement considéré. Chercher des réponses plutôt que des discussions fatigantes sur la sécurité des applications web. Je veux m'excuser si c'était comme Quora.Quelles sont les différentes manières possibles pour un pirate de compromettre access_token et/ou refresh_token?
Répondre
Il existe de nombreuses questions justifiées à propos de la sécurité OAuth2 en général.
Il y a quelques années, lorsque OAuth2 n'était qu'un brouillon, l'un des principaux contributeurs de cette spécification écrivait an interesting blog post sur ce sujet. Et il a raison: out of the box, ce protocole de cadre offre beaucoup de possibilités d'usurper l'identité d'un client et d'avoir accès aux ressources de l'utilisateur ou d'envoyer des demandes valides, y compris des demandes d'administration.
La raison principale est que le RFC6749 indique clairement qu'il repose sur une connexion TLS. Les attaques dépendent rarement de l'utilisateur sauf si le jeton d'accès est exporté. L'homme au milieu, l'application mobile malveillante, l'ingénierie inverse, la force brute ... sont quelques-uns des moyens disponibles pour obtenir un jeton d'accès. Il est difficile d'obtenir une liste exhaustive de tous les types d'attaques.
Toutefois, comme il s'agit d'un protocole de structure, rien n'empêche d'implémenter des fonctions de sécurité supplémentaires. C'est pourquoi the IETF OAuth2 Working Group travaille sur des améliorations très intéressantes pour protéger toutes les parties prenantes (client, serveurs d'autorisation, serveurs de ressources) et les communications entre eux.
je vous recommande de lire les documents RFC suivants ou les courants d'air:
- RFC6819: donne des considérations de sécurité supplémentaires pour OAuth.
- RFC7800, POP Key Distribution et POP Architecture qui tentent de remplacer le abandonned MAC access tokens
- RFC7009 de révocation jeton
- RFC7521, RFC7521 et RFC7521 qui implémente de nouvelles méthodes d'authentification client basées sur des affirmations JWT ou SAML2
- RFC7636: clé Preuve pour le code Échange pour empêcher l'application mobile malveillante d'obtenir le code d'autorisation, puis le jeton d'accès
En outre, vous pouvez également être intéressé par le token binding draft qui est (à partir de mon POV) une amélioration majeure car il lie des jetons à la connexion TLS. En d'autres termes, même si le jeton d'accès est compromis (ou délibérément exporté), il ne peut pas être utilisé car la connexion TLS sera différente.
Plus projets liés à la sécurité de OAuth2 sont disponibles sur la page the IETF OAuth2 Working Group (voir signed requests, closing redirectors, X.509 Client authentication ...).