web-dev-qa-db-fra.com

CSRF est-il possible dans un spa SSR avec authentification de cookie?

J'ai une application à une seule page, qui est fondamentalement un consommateur à mon API qui authentifie à l'aide de l'en-tête Authorization. Maintenant parce que je fais un rendu côté serveur, j'ai besoin d'authentifier sur La demande initiale, qui signifie Je dois utiliser des cookies pour stocker le jeton d'authentification.

Maintenant, autant que je sache, CSRF fonctionne comme ceci dans un site Web typique:

  • Trouvez un point final qui fait quelque chose de nocif comme /delete-account qui authentifie avec des cookies
  • Dans example.com, mettre un <img href="http://mywebsite.com/delete-account"> (ou quoi que ce soit pour a POST)

Cependant, à moi, il semble que cela soit impossible pour les attaques de CSRF de se produire dans le cas d'un spa, même si le jeton d'authentification est envoyé en tant que cookie. La procédure normale est un peu comme:

  • L'utilisateur visite une page, disons /account
  • Server Rend Page de la page selon l'utilisateur authentifié (étant donné le cookie d'autorisation)
  • La page Web est renvoyée
  • Maintenant, si l'utilisateur souhaite supprimer leur compte, ils pourraient appuyer sur le bouton, qui enverrait une demande à l'API qui authentifie uniquement les demandes de Authorization en-tête.

Maintenant, dans une attaque CSRF:

  • <img href="/account">
  • Le serveur rend le serveur et renvoie la page Web
  • Umm, rien ne se passe?

Je veux dire que je ne peux pas penser à une manière que je puisse être vulnérable à la CSRF dans cette situation, même si j'utilise des cookies pour l'authentification, et aussi loin que je le comprise, les attaques de la CSRF ne peuvent pas gratter les données de pages Web, ainsi de retour sensible. Les données n'auraient pas d'importance, tant qu'elle ne déclenche pas une action.

Donc, ma question est que c'est bien de ne pas mettre en œuvre une sorte de protection de la CSRF dans ce cas? J'ai tellement peur d'avoir une question de sécurité à ce sujet.

web-applicationcookiescsrfsingle-page-app
5
OverCoder

Maintenant, si l'utilisateur souhaite supprimer leur compte, ils pourraient appuyer sur le bouton, qui enverrait une demande à l'API qui authentifie uniquement les demandes de Authorization en-tête.

En fin de compte, il envoie une demande d'exécution d'une action qui doit être authentifiée d'une manière ou d'une autre. Et, puisque vous utilisez l'en-tête d'autorisation de l'authentification, cela empêche la CSRF, sauf si vous utilisez HTTP Basic Auth ou [~ # ~ # ~ # ~] . Ces jetons d'authentification sont envoyés dans chaque demande similaire aux cookies.

Je veux dire que je ne peux pas penser à une manière que je puisse être vulnérable à la CSRF dans cette situation, même si j'utilise des cookies pour l'authentification, et aussi loin que je le comprise, les attaques de la CSRF ne peuvent pas gratter les données de pages Web, ainsi de retour sensible. les données n'auront pas d'importance, tant qu'elle ne déclenche pas une action

Il existe des situations que vous pourriez vous trouver vulnérables au CSRF, voici quelques-uns;

  1. Et si votre serveur accepte l'un des deux, c'est-à-dire des cookies ou un jeton?

-> J'avais récemment rencontré la même chose. La demande aurait besoin de cookies ou d'authentification. Étant donné que les cookies sont toujours envoyés, vous êtes supposé être authentifié et votre demande est traitée en vous laissant vulnérable à la CSRF en supposant que votre application permet d'envoyer un jeton d'autorisation de n'importe quel domaine.

  1. Et si votre application fuit Auth Jeton, qui peut être lu croisé?

-> J'ai vu un certain nombre d'applications récupérer des jetons d'un point d'extrémité prédéfini qui peut être lu en quelque sorte. Certaines possibilités sont, JSONP, CORS, CROSSDDOMAIN.XML, JSON Pijacking, etc. Cela conduit à nouveau au CSRF.

même si j'utilise des cookies pour l'authentification

C'est toujours vulnérable, il vous suffit de jouer avec la demande finale qui est une demande d'API dans votre cas.

Donc, ma question est que c'est bien de ne pas mettre en œuvre une sorte de protection de la CSRF dans ce cas? J'ai tellement peur d'avoir une question de sécurité à ce sujet

En fait, oui. En outre, assurez-vous de vos domaines blanchissants qui peuvent apporter une demande à votre API et de retourner Access-Control-Allow-Credentials: false. Ceci, à mon avis, le rend assez sûr contre la CSRF- Considérant les points mentionnés ci-dessus.

4
1lastBr3ath

Premièrement, il est important de comprendre ce qui suit: Vous devez mettre en œuvre quelque chose pour authentifier un utilisateur et mettre en œuvre quelque chose pour authentifier une demande (anti-CSRF). L'attaque CSRF utilise une session d'une victime, donc si votre valeur d'en-tête Authorization est identique à toute session, votre application pourrait être vulnérable à une attaque CSRF, car votre application ne valide qu'une session d'utilisateur, elle doit Validate une demande et cela est possible en utilisant un jeton avec les fonctionnalités suivantes:

  • Assez long.
  • Pseudo-aléatoire.
  • Valeur unique.
  • Une par demande.

Premièrement, vous devez valider la session utilisateur, s'il s'agit d'un utilisateur valide et de ses autorisations ou son rôle, après cela, vous devez valider la demande via le jeton, s'il s'agit d'un jeton valide, vous pouvez permettre la demande.

J'espère que cette information vous aide.

2
hmrojas.p