Réagir frontend et API REST, CSRF
Réagir interface avec l'API REST comme backend, l'autorisation par JWT, mais comment gérer la session? Par exemple, après la connexion, je reçois JWT jeton de REPOS, si je l'enregistrer pour le localStorage je suis vulnérable aux attaques de type XSS, si je l'enregistre les Cookies, les mêmes problèmes que si ne suis pas de réglage HttpOnly, mais réagir ne peut pas lire les Cookies HttpOnly (j'ai besoin de lire cookie pour prendre JWT, et utiliser cette JWT avec le reste des demandes), aussi je n'ai pas mentionné CSRF problème, si vous utilisez le REPOS comme backend, vous ne pouvez pas utiliser Jeton CSRF.
Comme un résultat de Réagir avec le RESTE semble être une mauvaise solution et j'ai besoin de repenser mon architecture, comment faire? Est-il possible d'offrir aux utilisateurs de sécuriser réagir application ce logique des affaires traitées sur les API REST côté, sans crainte de perdre leurs données?
Mise à jour:
Que j'ai compris, il y a possibilité de le faire:
- Réagissent fait appel AJAX à l'API REST
- Réagir obtient JWT jeton de REPOS
- Réagir écrit cookies httponly
- En raison de réagir ne peut pas lire les cookies httponly, nous l'utilisons dans tous nos appels de REPOS où nous avons besoin de l'authentification
- Appels de REPOS vérifier XMLHttpRequest en-tête, ce qui est une sorte de protection CSRF
- RESTE vérification côté pour cookie, lire JWT et faire des trucs
J'ai un manque de connaissances théoriques ici, mais il semble logique et assez sécurisé, mais j'ai encore besoin de réponse à mes questions et d'approuver de ce "flux de travail".
- tout d'abord.. si vous utilisez le JWT jeton d'authentification, pourquoi avez-vous même envie de lire que sur le front-end. Il convient de http seule et sécurisé.... deuxième..Il est très possible d'utiliser jeton CSRF avec le RESTE. Pour référence, vous pouvez vérifier le guide de l'OWASP. Espérons que cela aidera à owasp.org/index.php/...
- mais comment je peux le lire sur le backend? Par exemple, j'ai chercher de l'api rest pour obtenir JWT, comment je peut lire et enregistrer-il pas sur le frontend?
- Aussi, que j'ai compris de votre réponse sur CSRF, il y a une possibilité de "sécuriser" votre demande et la réponse de la simple vérification XMLHttpRequest-tête? Aussi il est dit que vous pouvez ajouter votre propre en-tête et le vérifier dans les requêtes, mais pourquoi il est sécuritaire? Pourquoi possible de hacker ne peut pas modifier ses en-têtes de requête et de passer par mes chèques?
- vous pouvez lire Seulement les Cookies HTTP ici. Lorsque vous faites le reste de demande pour obtenir le jeton, le serveur va renvoyer un HTTP Seule cookie, dont le navigateur enregistre à son extrémité le long de avec d'autres cookies de votre domaine. Le même témoin est ensuite l'envoyer avec tous les autres dans toutes les demandes de votre serveur (ajax ou autre). Vous n'avez pas à faire quoi que ce soit le client final pour que cela se produise. En fait, il n'est pas autorisé par le navigateur pour lire les cookies à l'aide de Javascript. Ils ne peuvent donc pas être détourné.
- Vous pouvez lire tous les cookies sur le back-end. Vous pouvez l'obtenir à partir d'en-têtes Http. Les jetons CSRF sont afin d'éviter les demandes de site. Ils sont utilisés pour s'assurer que les demandes pour le service web est à venir à partir de la correspondante de l'INTERFACE utilisateur/utilisateur uniquement.Ils ne sont pas utilisés pour authentifier ou autoriser le demandeur. Ils sont juste utilisés pour sécuriser le service web à partir d'une demande frauduleuse de l'extérieur. Ils peuvent être de session/ demande spécifique, de sorte que personne ne puisse utiliser votre jeton.
- Avez-vous vu ce post? stackoverflow.com/questions/27067251/...
Vous devez vous connecter pour publier un commentaire.
assuré, beaucoup de réparateur de ressources client lib disponible
assuré, c'est ce que JWT devrait faire
Je ne pense pas, Il ne doit pas travailler, mais la session n'est pas une chose importante, il va bientôt sortir de la date, et vérifier de nouveau le mot de passe sur les principales opérations, même les pirates ont obtenu dans un très court laps de temps, vous pouvez lier jeton de session avec IP lors de la connexion de l'utilisateur et de le vérifier dans votre backend api. Si vous voulez plus sécurisé, il suffit de garder jeton dans la mémoire, et de refaire la connexion lors de l'ouverture de la nouvelle page ou une page se rafraîchit
assuré, vérification de l'utilisateur et les autorisations par le biais de jeton de connexion, comme csrf, vous pouvez placer votre jeton de connexion dans votre en-tête de demande, et de vérifier dans votre backend api.
Lier jeton de connexion à votre propre reposant lib vous permettra d'économiser beaucoup de codes
assuré, comme la plupart des personnes.
Aussi, lier jeton csrf à votre propre reposant lib vous permettra d'économiser beaucoup de codes
utilisation jeton de l'utilisateur dans l'en-tête https://www.npmjs.com/package/express-jwt-token
Authorization JWT < jwt token >utilisation jeton csrf dans l'en-tête https://github.com/expressjs/csurf
req.headers['csrf-token'] - the CSRF-Token HTTP request header.reposant client https://github.com/cujojs/rest
réagir avec jwt https://github.com/joshgeller/react-redux-jwt-auth-example
session+ipest valable une seule adresse IP pour de nombreux client est OK, cela signifie de garder loin de le hacker qui a obtenu jeton de l'utilisateurin memorysignifie une meilleure Fermeture paswindow.loginTokenVotre serveur peut définir le JWT cookie directement comme une réponse à la demande de connexion.
Le serveur répond à
POST /loginavecSet-Cookie: JWT=xxxxxx. Ce cookie est http uniquement et n'est donc pas vulnérables aux attaques de type XSS, et sera automatiquement inclus sur toutes récupérer les requêtes du client (aussi longtemps que vous utilisezwithCredentials: true).CSRF est atténué comme vous l'avez mentionné, voir OWASP pour détails.