Dva: exemple d'authentification oauth2

La vérification oauth2 n'est-elle pas effectuée par redirection d'URL ? C'est bien si vous vous connectez en jugeant le cookie.

Une partie de OAuht2 est effectuée via access_token, pas par URL, au format RESTFul pur

Ce serait mieux s'il y avait un exemple d'intégration dva et Spring Boot Oauth2 : D

@soulmachine J'utilise ceci, et je le

@WhatAKitty transmet le access_token, où est-il stocké access_token ? Stocké dans local/seesionStorage, il y aura des risques de sécurité XSS.

@u0x01 est stocké dans le stockage local. En fait, il n'y a pas beaucoup de risque. Access_token a une limite de temps. Vous ne pouvez pas vous reconnecter après l'expiration du délai, et il n'y a pas d'autorisation refresh_token. De plus, il n'y a pas d'autre moyen. D'autres informations connexes sont interrogées et elles sont toutes stockées dans le stockage local.

@WhatAKitty Now, les pirates utilisent ou écrivent des outils automatisés pour attaquer. La période de validité de deux heures d'access_token est suffisante pour faire beaucoup de choses. Comment en êtes-vous venu à la conclusion qu'"il n'y a pas trop de risque" ?
Deuxièmement, refresh_token n'est pas placé dans localstorage, où le mettez-vous ?
Le access_token est plus approprié pour APP. Le côté JS pur ne doit pas utiliser le schéma access_token. Il existe toujours un risque d'attaques intersites.
La solution la plus sûre maintenant est d'ajouter http-only à set-cookie.
Lors de la vérification de la connexion, apportez le cookie au serveur pour extraire l'état de la session. S'il échoue, il passera directement à la page de connexion.
La sécurité est aussi la productivité, ce qui est plus important que Taishan, vous ne pouvez donc pas être paresseux ici.

@u0x01 refresh_token, je ne le donnerai pas au client js. Par conséquent, il doit être re-certifié une fois qu'il expire. Je n'ai peut-être pas été clair avant, car notre application est comme ça : access_token est juste une clé qui vous permet d'accéder. Si vous voulez accéder à des ressources spécifiques, vous devez passer par l'authentification de l'utilisateur. Ce processus est sécurisé par SSL, donc vous n'apparaîtrez pas.Dit divers risques.
En ce qui concerne la solution la plus sûre que vous avez mentionnée, j'ai également envisagé d'utiliser des cookies, mais une : je n'ai pas rendu le serveur compatible avec OAUTH2 et LOGIN PASSWORD en même temps, car je ne peux pas retourner un access_token après m'être connecté avec LOGIN PASSWORD. , Il y a peut-être d'autres moyens, mais je ne l'ai pas trouvé. Deuxièmement : en raison des contraintes de temps du projet, cette option ne peut être sélectionnée qu'à titre de compromis. Par conséquent, ce plan semble être un peu inapproprié, mais en fait, il n'y aura pas de problèmes de sécurité.

@WhatAKitty n'a jamais entendu parler de SSL "peut protéger les sites Web contre les attaques XSS/CSRF", il n'y a pas de relation directe entre les deux.
Si vous pouvez garantir que le système de votre site Web est à 100 % exempt de vulnérabilités XSS/CSRF, vous pouvez le stocker dans localStorage et laisser JS accéder directement aux informations d'identification. (Mais je n'ai jamais vu une entreprise qui a osé voter que son système n'a pas de failles de sécurité)

Et je ne comprends pas ce que signifie accéder à des ressources spécifiques, qui doivent être authentifiées par l'utilisateur. Dans la spécification OAuth2, obtenir access_token signifie que l'utilisateur (ou le fournisseur) a approuvé cette autorisation.

De plus, vous avez mentionné :
因为没法在使用 LOGIN PASSWORD 登录后给我返回一个access_token
C'est une mauvaise compréhension de la spécification OAUth2 et une mauvaise utilisation.

La méthode LOGIN PASSWORD est essentiellement un processus dans lequel l'UA demande directement l'authentification au fournisseur OAUth2, voir RFC6749 . À ce stade, le code_autorisation doit être obtenu. Une fois que l'UA a obtenu le code_autorisation, il sera envoyé au client pour vérifier la validité du fournisseur OAUth2. Si la vérification est réussie, le client obtiendra le jeton d'accès du fournisseur OAUth2. À ce stade, le client peut utiliser access_token pour accéder aux ressources. Le client émet ensuite un SessionID à l'UA.
(Le client fait ici référence au serveur ou à l'application de l'entreprise, et non à l'utilisateur final, l'utilisateur final est le propriétaire de la ressource et l'UA est le navigateur)

Dans l'ensemble, SessionID doit être utilisé pour authentifier les utilisateurs, même si SessionID n'est pas utilisé, access_token doit être placé dans le cookie http uniquement :

1. Don't use local storage for session identifiers. Stick with cookies and use the HTTPOnly and Secure flags.
2. If cookies won't work for some reason, then use session storage which will be cleared when the user closes the browser window.
3. Be cautious with storing sensitive data in local storage. Just like any other client side storage options this data can be viewed and modified by the user. 

Si vous voulez vraiment exposer le access_token au client, la méthode de compromis est :

// GET /seesion
    access_token := ctx.Session().GetString("access_token")

    if access_token != "" {
        ctx.JSON(200, {"signed": true, "access_token": access_token})
    } else {
        ctx.Redirect("//yoursite.com/login")
    }

Mais je recommande toujours de ne le mettre que dans le cookie. JS utilise la méthode GET /seesion pour déterminer si vous vous êtes connecté. Les autres ressources sont accessibles comme d'habitude. Le serveur passera directement à la page de connexion après avoir découvert que le access_token a expiré :

// GET /seesion
    access_token := ctx.Session().GetString("access_token")
    if signed != "" {
        ctx.JSON(200, {"signed": true})
    } else {
        ctx.Redirect("//yoursite.com/login"， "you need login first.")
    }

// GET /posts/:postid
    access_token := ctx.Session().GetString("access_token")

    if access_token != "" && isValidAccessToken(access_token) {
        ctx.JSON(200, getPostWithAccessToken(access_token, postid))
    } else {
        ctx.Redirect("//yoursite.com/login"， "you need login first.")
    }

Bien sûr, si vous pensez que votre système de site Web n'a aucune valeur d'attaque, je n'ai rien dit.

Ce genre de « apparemment inapproprié, mais en fait, il n'y aura pas de problèmes de sécurité ».
Inventaire des fuites de sécurité des informations d'entreprise
Un million d'informations clients ont été colportées en temps réel (le problème de fuite de sécurité des informations de cette entreprise n'a pas été complètement résolu jusqu'à présent, il a été interdit par un certain nombre de grandes entreprises de commerce électronique comme un club de produits)

La sécurité de l'information a un long chemin à parcourir.

@u0x01
Permettez-moi de parler de ce que j'ai déjà répondu. Ce n'est peut-être pas clair. Dans le processus d'obtention du token d'accès, non seulement client_id et client_secret (cela peut ne pas être nécessaire) sont requis, mais également un nom d'utilisateur et un mot de passe sont requis.

Peut protéger le site Web contre les attaques de XSS/CSRF

Il y a CSRF a été désactivé. Comme pour XSS, tout le contenu stocké dans la base de données sera automatiquement transféré et les champs illégaux seront filtrés. Bien qu'il puisse y avoir des omissions, il est impossible de l'éliminer complètement. La sécurité de l'information n'est pas absolument sûre. Il en va de même pour Microsoft et Apple Je ne vous crois pas, le système peut atteindre 100 % de sécurité.

Même si vous n'utilisez pas SessionID, vous devez mettre access_token dans le cookie http uniquement

Http n'est pas non plus absolument sûr.

C'est une mauvaise compréhension de la spécification OAUth2 et une mauvaise utilisation.

Je ne sais pas si cela est considéré comme une utilisation incorrecte, mais est-il possible pour ma propre application de demander une page d'autorisation. Une fois que l'utilisateur s'est connecté, il obtient la page d'autorisation puis accepte d'y accéder ? Est-ce trop d'ennuis? Pour l'instant, aucun site Web ne fait cela pour ses propres applications, n'est-ce pas ?

De plus, ma méthode d'authentification idéale peut être différente de ce que vous avez dit, car mon propre serveur fournit des services d'authentification OAuth2. Donc je pense que pour mon navigateur client, c'est comme ça : UA demande AS, AS constate qu'il n'est pas authentifié, passe à LOGIN, puis après que l'utilisateur s'est connecté, il obtient avec succès l'autorisation d'accéder au serveur (cela peut be access_token, ou cela peut être) Vous pouvez ouvrir directement les autorisations d'accès au service de ressources), puis les utilisateurs peuvent directement/indirectement (access_token) demander des ressources sur le serveur de ressources du côté js.

En d'autres termes, ma méthode d'authentification idéale est pour notre propre UA. Je pense que s'il s'agit d'un tiers, il peut être nécessaire d'utiliser le allow_code que vous avez mentionné pour obtenir la page d'autorisation à laquelle l'utilisateur peut accéder.

Ce qui précède est ma méthode d'authentification idéale, mais malheureusement mon niveau est limité et je ne peux pas obtenir l'effet que je souhaite via OAuth2 de Spring.

Je ne sais pas combien de dommages cela causera à votre employeur à l'avenir

Tout d'abord, je tiens à préciser que notre projet est très urgent et que l'architecture n'a rattrapé son retard que récemment, si c'était possible, ne pourrais-je pas viser l'excellence ? Cependant, le temps ne le permet pas, votre patron vous permet de faire glisser le projet du client tout en jouant la sécurité technique ? La réalité est souvent cruelle. Votre patron peut ne pas se soucier du tout de la sécurité de vos clients. Ils sont plus préoccupés par les intérêts. La seule chose que je puisse faire est d'assurer autant de sécurité que possible.

@u0x01 En fait, pour ma part, je souhaite également réaliser l'architecture que j'ai conçue sans aucun problème de sécurité, mais la réalité est la suivante :

1. Je ne peux pas répondre à cette exigence avec mon niveau technique personnel.Je ne suis pas un expert technique moi-même.
2. Manque d'un vrai expert technique pour me guider, si quelqu'un veut bien me guider, je pense que je serai heureux

Jusqu'à présent, toutes mes technologies ont été explorées par une seule personne sans orientation. Certaines solutions manquantes sont en effet mes lacunes.

@WhatAKitty
Puisque votre projet est pressé et que le patron s'en moque, faites-le simplement selon vos idées maintenant.

Mais est-il possible pour votre propre application de demander une page d'autorisation. Une fois l'utilisateur connecté, obtenez la page d'autorisation puis acceptez d'y accéder ? Est-ce trop d'ennuis? Pour l'instant, aucun site Web ne fait cela pour ses propres applications, n'est-ce pas ?

Veuillez vous référer aux spécifications pertinentes d'OAuth2, OAuth2 a le concept d'autorisation implicite.

En d'autres termes, ma méthode d'authentification idéale est pour notre propre UA. Je pense que s'il s'agit d'un tiers, il peut être nécessaire d'utiliser le allow_code que vous avez mentionné pour obtenir la page d'autorisation à laquelle l'utilisateur peut accéder.

OAuth2 ne semble pas avoir le concept de tiers.

De plus, que faites-vous avec la protection CSRF désactivée... N'est-ce pas vous creuser un trou ?
Je n'ai pas dit que http seul est absolument sûr. Le principal problème de sécurité que http ne résout que est d'empêcher js de lire les cookies. La coopération avec SSL peut empêcher des tiers de surveiller les cookies (en cas d'attaques non-man-in-the-middle).

@WhatAKitty
J'avais l'habitude d'être du point de vue du patron, mais en fait, c'est bien d'avoir des problèmes de sécurité. D'une part, votre patron sera attentif aux problèmes de sécurité, et d'autre part, vous laisserez un repas à l'ingénieur en sécurité de l'information.

Les ingénieurs en sécurité de l'information devraient remercier les programmeurs qui laissent délibérément des bogues :)

@ u0x01 Il semble que vous connaissiez bien OAuth2 ? Est-il possible de créer un groupe ?Je n'ai pas trouvé beaucoup d'informations sur l'application dans ce domaine, et je n'ai pas eu trop de temps pour les collecter.Je peux vous poser quelques questions.

@ u0x01 Le backend est sans état et il n'y a aucune session. Vous devez utiliser le jeton pour redis pour déterminer s'il a expiré.Puis-je demander où le jeton est en sécurité ?

@longzb stateless ≠ session aucune, vous avez mentionné

Utilisez le jeton pour redis pour déterminer s'il a expiré

En fait, le access_token est utilisé comme une session. Il est recommandé de se renseigner sur la définition et les méthodes de travail de séance.

Où est le jeton en sécurité ?

Le placer dans le cookie http_only peut empêcher JS d'acquérir directement le cookie, réduisant ainsi la valeur et la possibilité d'attaques XSS/CSRF.

@u0x01 Hum. Je suis allé à Baidu hier. Je vais mettre des cookies, c'est mieux d'être plus sûr.

Cet article est bon sur l'analyse implicite.
Aujourd'hui, je termine l'exemple SSM + ANTD. Après avoir lu cet article, je pense que le moyen le plus sûr est d'utiliser le serveur implicite pour demander le serveur d'authentification et obtenir le jeton, et demander implicitement au serveur implicite d'obtenir les ressources du serveur de ressources.

Parce que comme le dit cet article, l'autorisation implicite est risquée, comme le phishing, il est facile pour le pirate de se faire passer pour un client sécurisé pour demander des ressources.

Mais pour ce faire, dva doit prendre en charge le rendu côté serveur. Maintenant qu'antd le prend en charge, est-ce que dva le prend déjà en charge ? @désolé

Vous ne vous inquiétez pas des bonnes choses

Protéger les informations situées sur le client ?

Vous n'avez rien à faire une fois que l'information est parvenue à votre client (ex. : votre navigateur) afin de la protéger.Vous pouvez stocker le jeton d'accès dans un cookie, dans un champ caché de votre page Web, dans le cache local html5 ou bien visible directement au milieu de la page et cela ne change rien (sauf le surf à l'épaule...).

S'inquiéter du jeton d'accès une fois qu'il est sur le client, c'est comme ouvrir le bloc-notes pour écrire votre mot de passe de messagerie, puis craindre qu'un attaquant puisse voler ces informations à partir d'un emplacement distant. Cela n'arrive pas. À moins que votre ordinateur ne soit déjà compromis, mais à ce stade, vous avez déjà perdu.

Où est-il logique de s'inquiéter?

Généralement, vos informations sont vulnérables lorsqu'elles sont en transit. Dans le cas d'OAuth2 (flux implicite), le jeton d'accès sera en transit à deux endroits :

du serveur d'autorisation à votre navigateur
de votre navigateur au serveur de ressources
Protéger les informations pendant qu'elles sont en transit est aussi simple que d'utiliser TLS partout, ce que vous devriez déjà faire puisque vous utilisez OAuth2 et que le protocole l'exige.

Maintenant le vrai problème

La façon dont vous avez l'intention d'utiliser OAuth2 n'est probablement pas la façon dont vous devriez l'utiliser.

Pour comprendre pourquoi vous allez probablement abuser d'OAuth2, vous devez connaître les flux. OAuth2 définit 4 flux d'autorisation

Code d'autorisation (seulement un bon mais... continuez à lire)
Implicite (faux sentiment de sécurité)
Identifiants de mot de passe du propriétaire de la ressource (idée horrible)
Informations d'identification du client (ne s'applique pas à votre cas)
Puisque vous utilisez un client javascript, le seul flux qui fonctionne pour vous est le flux implicite et lance maintenant les problèmes.

Problèmes de flux implicites

Il y en a beaucoup, mais parlons juste du plus critique. Les jetons d'accès ne sont pas liés à un client spécifique ! À partir de la section de spécification 10.16 :

Pour les clients publics utilisant des flux implicites, cette spécification ne fournit aucune méthode permettant au client de déterminer à quel client un jeton d'accès a été émis.
Cela ouvre la porte à un attaquant pour se faire passer pour vous, le propriétaire de la ressource, puis accéder au serveur de ressources. Continuons à lire la section 10.16 :

Un propriétaire de ressource peut volontairement déléguer l'accès à une ressource en accordant un jeton d'accès au client malveillant d'un attaquant. Cela peut être dû à l'hameçonnage ou à tout autre prétexte. Un attaquant peut également voler un jeton via un autre mécanisme. Un attaquant peut alors tenter de usurper l'identité du propriétaire de la ressource en fournissant le jeton d'accès à un client public légitime.

Dans le flux implicite (response_type=token), l'attaquant peut facilement basculer le jeton dans la réponse du serveur d'autorisation, remplaçant le jeton d'accès réel par celui précédemment délivré à l'attaquant.

Les serveurs communiquant avec des applications natives qui dépendent de la transmission d'un jeton d'accès dans le canal arrière pour identifier l'utilisateur du client peuvent être compromis de la même manière par un attaquant créant une application compromise qui peut injecter des jetons d'accès arbitrairement volés.

Tout client public qui suppose que seul le propriétaire de la ressource peut lui présenter un jeton d'accès valide pour la ressource est vulnérable à ce type d'attaque.
Cette première attaque n'est en fait même pas une attaque mais plutôt juste une "défaut" dans le flux implicite...

La prochaine attaque

Maintenant commence les gros problèmes. Vous semblez essayer d'utiliser le flux implicite OAuth2 comme une forme d'authentification d'utilisateur final déléguée qu'il n'est pas censé fournir. Retour à la section de spécification 10.16

L'authentification des propriétaires de ressources auprès des clients est hors de portée de cette spécification. Toute spécification qui utilise le processus d'autorisation comme une forme d'authentification d'utilisateur final déléguée au client (par exemple, un service de connexion tiers) NE DOIT PAS utiliser le flux implicite sans des mécanismes de sécurité supplémentaires qui permettraient au client de déterminer si le jeton d'accès a été émis pour son utilisation (par exemple, en limitant l'audience du jeton d'accès).
À ce stade, c'est principalement la fin du jeu pour vous.

Comment monter cette attaque ?

C'est assez simple. Disons que votre service REST nécessite un jeton d'accès de Facebook. Tout ce qu'un attaquant doit faire est d'héberger un service, par exemple stackoverflow, et d'exiger un jeton d'accès de Facebook. Lorsque vous donnez le jeton d'accès facebook à stackoverflow, stackoverflow (notre attaquant) peut maintenant vous usurper l'identité de votre service REST.

Tout cela parce que les jetons d'accès ne sont pas liés à un client spécifique.

Une solution

N'utilisez pas le flux implicite et utilisez plutôt le flux de code d'autorisation.Ce qui signifie que votre application 100% côté client n'aura plus besoin d'être une application 100% côté client.

Pourquoi n'utilisez-vous pas le serveur qui sert le client angularjs à votre utilisateur pour gérer le flux OAuth2 ?

Référence : http://tools.ietf.org/html/rfc6749

@WhatAKitty Si un certain identifiant du navigateur de chaque utilisateur est unique, l'utilisateur apportera automatiquement cet identifiant lors de l'envoi de la demande, et il ne peut pas être modifié. Le backend peut lier le jeton à cet identifiant lors de la demande de jeton pour la première fois. Une fois que la prochaine demande ne correspond pas à l'ID de navigateur stocké dans le jeton, elle sera considérée comme une demande illégale. .
Je veux donc demander, existe-t-il un tel logo lorsque le navigateur le demande ? ?

@longzb utilise généralement JSESSIONID, ou il peut être personnalisé. Par exemple, oschina utilise son propre identifiant

@WhatAKitty @soulmachine @longzb

Lorsque les modes Mot de passe et Client d'OAuth2.0 sont utilisés en même temps, un proxy d'entrée peut être ajouté au serveur principal pour stocker le access_token, et ce proxy peut également être utilisé comme CORS frontal (Spring Boot Oauth2 semble intercepter le contrôle en amont de CORS)

Le mode mot de passe frontal n'a besoin que d'envoyer le nom d'utilisateur et le mot de passe à l'agent. L'agent obtient l'autorisation et stocke le access_token. Ensuite, le SESSION_ID généré par l'agent est renvoyé à l'interface et l'agent doit gérer le l'expiration et l'actualisation de l'access_token. La seule chose exposée au front-end est Remember-Me etc. sont juste différents dans la tête de Set-Cookie: Expires=

Le mode Client du client n'a pas besoin d'accéder au proxy, il suffit d'aller directement à l'interface OAuth pour obtenir l'autorisation

Quant à la réponse de @ u0x01 , j'ai dit beaucoup d'informations confuses et inutiles

En fait, il peut être résumé comme suit :

1. Lancer le access_token directement sur le front-end au lieu de la session est dû au fait qu'il doit partager l'interface avec le mode client. Ce type d'interface ne prend souvent pas en charge la vérification de session, ou il n'est pas pratique de gérer la session sur un système distribué.

2. La sécurité contre les attaques XSS et CSRF doit être analysée séparément

   2.1 Pour éviter CSRF, le front-end met le access_token dans l'en-tête HTTP à envoyer, et le back-end ne supporte que la vérification d'en-tête.En même temps, il suffit de bien concevoir l'interface. Parce que le site Web tiers ne peut pas envoyer d'en-têtes HTTP supplémentaires uniquement via le formulaire et que le JS du site Web tiers ne peut pas envoyer de données à son propre site Web (lorsque CORS est correctement défini)

   2.2 Pour empêcher XSS, le stockage frontal access_token n'est en effet pas sécurisé et peut être lu par JS à volonté et envoyé à travers les domaines ; et les cookies avec HttpOnly défini sont des ressources d'informations d'identification. Les navigateurs HttpOnly ne peut être considéré que comme un remède

3. La mesure la plus sûre consiste à agir en tant que proxy d'entrée au niveau du back-end et à définir le Access-Control-Allow-Origin de CORS pour autoriser uniquement les noms de domaine frontaux. Une fois que l'utilisateur s'est connecté avec succès, la session de HttpOnly est renvoyée et un code aléatoire tel que X-CSRF-TOKEN est ajouté au champ d'en-tête. Ce code aléatoire existe avec le access_token obtenu à partir de l'interface OAuth . Le front-end utilise Ajax ou fetch pour envoyer des données avec le cookie et cet en-tête. Une fois que le back-end a vérifié la validité du cookie, il doit vérifier la validité de l'en-tête X-CSRF .Cela peut essentiellement empêcher CSRF et XSS ordinaire de voler des autorisations

En bref, la gestion frontale d'access_token ne peut pas être grossièrement considérée comme non sécurisée

Mise à jour 1 :

Le middleware ou le backend utilise jwt pour chiffrer access_token, et en même temps, forme la détection d'injection et le CSP pour empêcher XSS

@mdluo a une idée claire, bravo 👍

@mdluo Désolé, je suis novice en front-end. Dans la troisième méthode que vous avez mentionnée, je peux essentiellement réaliser la partie back-end avec Spring boot + Spring security, mais comment puis-je apporter des cookies à la récupération frontale ? Parce qu'il implique plusieurs domaines, certaines solutions sur Internet utilisent le paramètre credentials: "include" résoudre, mais ce paramètre ne peut résoudre que les requêtes GET. POST et d'autres problèmes ont des problèmes. Parce que c'est la première fois que vous l'utilisez, il peut être stupide de l'écrire vous-même. L'environnement est :
Front-end : port DVA 8000
Backend : Spring boot + Spring security, X-CSRF-TOKEN et Cookie

@yoster0520 Configurer Access-Control-Allow-Origin selon la liste blanche, afin qu'il puisse apporter des cookies