Sécuriser son API HTTP (1)

Leave a Comment

Nous vivons une époque où les API web sont légion et les organisations qu’elles soient des “géants du web” ou non en développent pour être utilisées à la fois par leurs propres applications et par celles de tiers. Dans ce contexte de généralisation et d’ouverture des API la question de la sécurité se pose assez rapidement.

La bonne nouvelle est que les problèmes de sécurité que nous rencontrons sont assez classiques et ont déjà été, dans leur grande majorité, résolus par d’autres personnes. La mauvaise, eh oui il en a une, est que les solutions et standards sont tellement nombreux (OAuth, TLS, JWS, JWE, OpenID...) qu’on y perd rapidement !

En ce moment j’explore ces solutions et standards et compte partager ici mes notes en espérant qu’elles aideront les plus pressés d’entre vous.

Dans ce premier article je parle brièvement de quelques principes fondamentaux de la sécurité à savoir la confidentialité, l’intégrité, la disponibilité, la non répudiation, l’authentification, l’autorisation et l’audit.

Sans faire trop de chichis rentrons dans le vif du sujet.

La confidentialité

La confidentialité consiste à protéger les données de sorte qu’elles ne soient intelligibles qu’aux destinataires. Dans le cas qui m’intéresse le cas des APIs web la confidentialité peut être obtenue grâce au TLS (a.k.a HTTPs) qui ajoute une protection à la couche de transport du protocole HTTP. De nombreux sites utilisent HTTPs sur l’ensemble de leurs pages et non seulement sur les pages où transitent des informations sensibles comme les mots de passe ou des transactions financières.

L’intégration

L’intégrité consiste à s’assurer que les données n’ont pas été altérées au cours de leur transfert. En général on fait cette vérification avec un code d'authentification des données (MAC). Le protocole TLS, donc HTTPs, permet aussi la vérification de l’intégration des données !

La disponibilité

Toute API a une certaine utilité et s’adresse à un public donné. Elle doit être conçue de sorte qu’elle soit toujours disponible pour ses utilisateurs. La sécurité de l'API consiste aussi à fournir à cette garantie.

La non répudiation

Super importante surtout quand vous faites des transactions business (paiement, consommation de crédit, contraintes légales de traçabilité etc.) avec votre API, la non répudiation permet d’assurer qu’une entité ne peut rejeter (ou répudier) une action qu’elle effectue sur le système. Par exemple une consommation de crédits par un client via l’API ne pourrait être rejetée plus tard. La non répudiation nécessite un tiers de confiance comme une autorité de certification qui procède à la vérification de la transaction. Dans la pratique l’entité qui initie la transaction signe les données et l’autre entité vérifie l’intégrité des données auprès du tiers de confiance avant d’exécuter la transaction.

L’authentification

L’authentification consiste à s’assurer qu’une entité (un utilisateur) est bien qui elle prétend être. En général cela s’accomplit de trois manières différentes : à partir de quelque chose qu'il connait, à partir de quelque qu'il détient et à partir de quelque chose qu'il est ! Voyons ce que signifie chacune de ces trois options.

  • S’authentifier à partir de quelque chose que l’on connaît : C’est peut-être la manière la plus répandue. Il s’agit en fait de demander à l’utilisateur de fournir une information qui permet de l’authentifier. C’est par exemple le cas quand on lui demande un mot de passe sur un site web ou un code PIN pour accéder à un téléphone.
  • S’authentifier à partir de quelque chose que l’on détient : Dans cette forme d’authentification on se sert de quelque chose dont dispose une entité pour l’authentifier. Les cartes à puce et les certificats numériques en sont deux exemples courants.
  • S’authentifier à partir de quelque chose que l’on est : C'est la forme la plus forte car elle se base sur des choses comme la reconnaissance faciale ou rétinienne, les empreintes digitales etc.

Certains système utilisent plus d’une manière (ou facteur) d’authentifier un utilisateur d’où le terme “authentification multi-facteur”.

L’autorisation

L’autorisation, qui sous-entend que l’utilisateur a déjà été authentifié, consiste à s’assurer qu’un utilisateur authentifié ne peut accéder qu’aux ressources ou actions qui lui sont autorisées au sein du système. Par exemple quand vous vous connectez à votre compte Google vous pouvez accéder à vos mails et vos docs mais pas à ceux d’un autre compte Google.

L’audit

Il est important que le système produise des logs qui seront utilisés plus tard pour des besoins d’audit, de détection d’intrusion, d’abus etc. Ces logs doivent également être protégés notamment pour qu’ils ne soient pas altérés par un attaquant qui souhaite dissimuler ses activités illicites :-)).

Pour la route

Voilà pour les concepts de base ! Dans le prochain article j’essaierai d’illustrer mes propos avec du code mais en attendant place à l’exploration...

© Nouhoum TRAORE.. Fourni par Blogger.