IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

CORS / Access-Control-Allow- Headers


Sujet :

Sécurité

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé Avatar de adrienfehr
    Homme Profil pro
    Inscrit en
    Mai 2008
    Messages
    203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2008
    Messages : 203
    Par défaut CORS / Access-Control-Allow- Headers
    Bonjour,

    Une petite question par rapport aux bonnes pratiques avec le CORS et les headers Access-Control-Allow-.

    Si l'on considère ce context:

    • Une application vueJS qui doit appeler une Rest API
    • Si cette Rest Api n'implemente pas ces headers:

      Nom : Headers.png
Affichages : 59
Taille : 185,1 Ko


    alors le browser (chrome, Firefox ...) va générer une exception Cross-Origin Request Blocked dés lors que le service rest sera appelé.

    Nom : CorsException.png
Affichages : 53
Taille : 153,9 Ko


    On peut ajouter ces headers (Access-Control-Allow-...) dans les microservices afin de ne plus avoir ces problèmes de Cross Origin (ces services seront tôt ou tard appelés par la UI [VueJS]). On peut même faire mieux en ayant un API gateway : La front end appelera uniquement un rest service et ce même rest service appèlera les autres microservices (mais ce n'est pas le topic dans ce post)
    Nom : ApiGateway.png
Affichages : 53
Taille : 105,4 Ko

    En fait cette erreur (CORS) va seulement apparaitre quand on va appeler le service rest à partir du Browser (par exemple à partir d'une application vue JS).

    Si un hacker crée un service rest externe à votre application il peut appeler votre microservice (qui n'a pas ces headers) mais n'aura pas cet exception Cross Origin car il l'appelera à partir d'un service Rest et non d'un browser.

    Quelle est ici la bonne pratique : dois je porter une attention particulière à ces headers (est-ce dangereux de les setter à Access-Control-Allow-Origin=* ou à son nom de domaine) ?

    Merci pour votre aide

  2. #2
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 582
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 582
    Par défaut
    Hello,

    oui, eh bien, il faut vérifier.

    Le hacker dont tu nous parles, n'est pas le problème des mécaniques CORS. Les mécaniques CORS sont relativement récentes et réfléchies depuis HTML 5 (enfin plus exactement depuis les techniques AJAX), alors que le hacker qui fait ce que tu décris, il existe depuis qu'Internet existe.

    Concernant le hacker dont tu parles, c'est pour te protéger de lui que tu demandes un login/mot de passe à tes utilisateurs. Le hacker peut bien essayer ce qu'il veut, sans le login et le mot de passe de quelqu'un d'autre, il ne peut faire que des requêtes qu'on peut faire normalement avec son propre login/mot de passe. Pas un problème donc. S'il veut faire des achats sur ta plate-forme sans passer par ta VueJS, c'est son problème. C'est quand même lui qui les fait, pour lui. C'est un peu exagéré d'appeler ça un hacker.

    Alors CORS, c'est pour se protéger de quoi ?

    S'il est vrai que le web moderne encourage à créer des APIs pour qu'une vue JavaScript lui fasse des requêtes, il ne faut pas oublier que ces APIs ne sont jamais que des applications web, qui reçoivent des requêtes HTTPS et qui y répondent normalement. Du point de vue d'un ordinateur, une API web n'est qu'un site web normal.

    Et qu'est-ce qu'il y a d'autre comme site web normal ? Par exemple un site d'achat en ligne. Le site typique, qui connaît ta carte bleue et qui te propose d'acheter simplement des articles en quelques clics et en indiquant à quelle adresse les livrer. L'utilisateur va sur achats-geniaux.com et le site le connaît bien, grâce aux cookies, et il affiche donc le nom du visiteur et lui propose d'utiliser la carte bleue qu'il connaît pour acheter des trucs. Normal.

    Et donc, puisqu'un site web et une API, c'est la même chose, on peut tout à fait utiliser achats-geniaux.com comme une API. Un site web, pas-suspect-du-tout.com, lorsque quelqu'un vient le visiter, peut parfaitement envoyer une requête à achats-geniaux.com comme à une API, demandant à acheter 600 lingots d'or à livrer à monsieur ESCROW, 42 rue de l'arnaque facile.

    Puisque achats-geniaux.com connaît le visiteur grâce à ses cookies, et qu'il connaît sa carte bleue, la commande est valide, et monsieur ESCROW vient de se faire livrer 600 lingots d'or payés avec l'argent de quelqu'un qui a visité son site. Simplement parce que cette personne utilise aussi achats-geniaux.com.

    Les CORS, ça sert à dire, ouais non.

    Les navigateurs n'ont pas envie que leurs utilisateurs soient escroqués en se servant de leurs cookies. Les sites webs n'ont pas envie que leurs clients soient escroqués. Alors les navigateurs et les sites webs ont mis en place un arrangement.

    Quand un site web dit à un navigateur de faire un appel d'API, et que cet appel est fait vers un autre domaine, le navigateur se méfie. Il se dit que c'est pas forcément légitime. Il demande d'abord à l'API si elle est d'accord. Pour ça il va faire une première requête OPTION vers la même URL et avec les mêmes headers, et en ajoutant le header "Origin" qui indique quel site web a déclenché la requête.

    L'API, voyant ça, va réagir "ah ouais non. Nous n'acceptons de requête que de notre propre origine. Ou par l'un de nos deux autres domaines. Mais personne d'autre" et la requête est rejetée. Et monsieur ESCROW a échoué.

    Si par contre la requête est faite par un des domaines autorisés, le navigateur reçoit l'autorisation, et fait la véritable requête en réindiquant tout le reste pareil.

    C'est à ça que servent "Access-Control-Allow-Origin" et consorts : indiquer au navigateur quels domaines ont le droit de faire des requêtes à cette API. Et si un site qui n'a pas le droit essaie de le faire quand même, le navigateur lui dit d'aller se faire cuire un œuf chez les grecs ou quelque chose comme ça.

    Mais donc, que vérifier ?

    Est-ce que tes APIs stockent des cookies/données persistentes sur les navigateurs de leurs visiteurs, pour se rappeler de qui ils sont ?

    Si oui, attention, ça veut dire que n'importe quel site web du monde peut envoyer ses visiteurs sur tes APIs pour leur faire faire ce qu'ils veulent, comme acheter 600 lingots d'or et les faire livrer n'importe où.

    Dans ce cas, il faudrait pas que tous les sites webs du monde aient le droit de le faire. Il vaudrait mieux limiter ça à ton site web à toi.

    Si tes APIs ne savent jamais rien du navigateur qui vient leur dire quelque chose, et qu'elles identifient les utilisateurs à partir d'un access token que VueJS ajoute à la requête à l'API, alors a priori elles ne risquent pas d'attaque de CORS... Mais bon, on sait jamais à quoi un pirate peut penser. Il vaut mieux limiter les accès autant que possible.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  3. #3
    Membre confirmé Avatar de adrienfehr
    Homme Profil pro
    Inscrit en
    Mai 2008
    Messages
    203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2008
    Messages : 203
    Par défaut
    Merci beaucoup thelvin bon ta réponse claire et riche.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 4
    Dernier message: 26/02/2019, 09h32
  2. Service Rest et Access-Control-Allow-Headers
    Par clem_alain dans le forum Services Web
    Réponses: 1
    Dernier message: 24/08/2015, 08h05
  3. [Débutant] Access Control Allow Headers
    Par Ma29200 dans le forum ASP.NET Ajax
    Réponses: 2
    Dernier message: 21/03/2013, 19h10
  4. Ext.Ajax et Access-Control-Allow-Origin:*
    Par sebxid dans le forum Ext JS / Sencha
    Réponses: 1
    Dernier message: 22/02/2012, 15h46
  5. Access Control Allow Origin dans .htaccess
    Par gégé140488 dans le forum Général JavaScript
    Réponses: 0
    Dernier message: 05/01/2012, 20h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo