QUELLE RECETTE POUR SECURISER SES API ? - Wavestone
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
QUELLE RECETTE POUR
SECURISER SES API ?
Les APIs sont partout aujourd’hui et permettent aussi bien les échanges à
l’intérieur du système d’information que les accès partenaires et clients.
AUTEUR Quelles bonnes pratiques de sécurité adopter ?
Ce que l’on appelle aujourd’hui communément APIs ou Application Programming Interfaces
regroupe un ensemble de méthodes de communications inter applicative allant des services
web (REST ou SOAP) aux appels entre processus (RPC) locaux ou distants. Les services
web de ce type, même s’ils ne sont pas les seuls à utiliser des API, se sont répandus comme
une trainée de poudre ces dernières années et représentent un mécanisme de commu-
nication prépondérant et incontournable pour toutes les entreprises lancées dans leur
transformation numérique. Ils sont rencontrés maintenant dans un nombre toujours plus
important de cas d’usages : données publiques, personnelles ou sensibles, applications
BERTRAND CARLIER
mobiles, échanges entre partenaires, IoT, applications dites « client-side », etc.
bertrand.carlier@wavestone.com
Le concept n’est pas nouveau. Dès l’introduction et la définition de la notion d’architecture
REST, en 2000, les premières APIs voyaient le jour. Les pionniers ont été eBay notamment
ou encore Flickr puis Facebook et Twitter en ont fait le cœur de leur produit sur lequel des
développeurs tiers pouvaient venir bâtir leurs propres services. Et dès la naissance de ce
Cette publication a été réalisée avec concept s’est évidemment posée la question de sécuriser les accès à ce nouveau type de
les contributions de Samantha MARECAUX services web.
et Parfait NANGMO.
L’expérience le montre, la sécurisation des APIs est une recette à base de 4 ingrédients qu’il
faut savamment doser.
U N E BA S E DE SECURITY AS USUAL
Selon un benchmark Wavestone sur le su- pour les APIs. La réponse est simple mais Un certain nombre de mesures de sécurité
jet de la sécurité des applications web1, souvent difficile à mettre en œuvre, les et bonnes pratiques de développement
sur 128 applications auditées, des failles recommandations habituelles de la sécurité sont à la disposition des développeurs
graves sont observées dans 60% des cas. web, par exemple celles d’OWASP doivent
2 et équipes d’exploitation pour couvrir les
La situation sur le terrain est très similaire être prises en compte de la même manière. zones à risques traditionnellement visées
par un attaquant :
Applications web & APIs – Security as usual
GESTION DES SESSIONS DONNÉES SENSIBLES
Authentification & Maintien de session Séparation des environnements
Côté client vs côté serveur Stockage et gestion des secrets
1 2
Identifiant de sessions non devinables Faire usage de mécanismes de sécurité éprouvés
Ré-authentifier pour des actions critiques
CONTRÔLE D’ACCÈS Les « zones » GESTION DES EXCEPTIONS
6 3
Gestion des profils & privilèges à risques Interception et traitement
Situation de concurrence de toutes les erreurs
Séparation des espaces utilisateurs
5 4
GESTION DES ENTRÉES/SORTIES GESTION DE LA MÉMOIRE
Encodage des données avant réponse Allocation de la mémoire
Initialisation des objets et des variables
N’OUBLIONS PAS LES RECOMMANDATIONS DE BASES DE LA SÉCURITÉ WEB… Supervision consommation mémoire
UNE PINCÉE D’OAUTH2
Une fois cette base bien maîtrisée et ap- OAuth2 se propose de couvrir un large
pliquée, se pose la question de la bonne éventail de cas d’usages (applications web,
mobile, accès ou non via un navigateur, Resource
gestion des accès dans l’application. Il owner
accès serveur-à-serveur, etc.) et offre à cet
s’agit de déterminer les moyens d’au-
effet :
thentification pour accéder à une API
Client
(pour authentifier aussi bien l’utilisateur // 4 cinématiques principales pour obte-
que l’application appelante) et de s’en- nir un jeton (RFC 6749)
tendre sur un protocole commun entre // 3 mécanismes d’utilisation de ce jeton
(RFC 6750)
des acteurs tiers. Access token
// Un document à part entière détaillant
OAuth2 est aujourd’hui le standard le le threat model et les bonnes ques-
plus approprié et le plus répandu dans le tions à se poser dans l’implémentation
cadre d’APIs REST. Il s’agit d’un standard d’OAuth2 au sein d’une architecture
Authorization Resource
de délégation d’autorisation qui permet server Server (API)
à une application d’obtenir l’autorisation
d’accès à une ressource (API) au nom
d’un utilisateur.
Enfin, une surcouche dédiée à l’authenti- Si l’on se limite à ces 4 documents, cassés les dents, et ont vu des données per-
fication complète ce premier ensemble : qui représentent déjà l’équivalent de sonnelles de leurs utilisateurs accessibles
OpenID Connect. Ce standard permet 250 pages, on comprend plus facile- disponibles sans authentification préalable3.
de contrôler plus finement les carac- ment la mauvaise réputation d’OAuth2 :
Il faut bien comprendre que ce n’est pas
téristiques de l’authentification de un protocole complexe, lourd et sujet à
le protocole en soi qui est en cause, il est
l’utilisateur (moyens d’authentification, erreurs d’implémentation.
heureusement tout à fait possible d’implé-
Single Sign-On, transmission d’attributs
Cette réputation n’est pas entièrement menter OAuth2 de manière sécurisée, mais
d’identité dans un format standard, réau-
usurpée : de grands acteurs du Web, tels une abondance d’options dans l’implé-
thentification forcée, etc.)
Facebook ou Twitter, s’y sont eux-mêmes mentation qui si elles sont mal évaluées et
1- xxxxxxxx xxxxxxxxxx
2- xxxxxxxx xxxxxxxxxx
2
3- xxxxxxxx xxxxxxxxxxQUELLE RECETTE POUR SECURISER SES API ?
choisies aboutissent à des failles critiques : // Redirect URI : Valider strictement les // State and PKCE : utiliser ces options
usurpation d’identité d’une application, URLs de redirection vers l’applica- du protocole pour garantir l’intégrité
tion, sans caractère générique (type d’une cinématique complète
accès aux données personnelles d’un uti-
wildcard)
lisateur tiers, vol de cookie Facebook/ // Authorization ≠ Authentication:
Google lors d’un social login ou encore // I mplicit : Éviter le flow OAuth2 Utiliser OpenID Connect4 pour authen-
« Implicit » dont la sécurité est dis- tifier, OAuth pour déléguer l’accès
compromission de compte utilisateur.
cutable (des tokens présent dans les
Quelques recommandations ci-dessous URLs peuvent être dans l’historique du
permettent d’offrir un premier niveau de navigateur par exemple) ainsi que l’er-
gonomie lors de l’expiration des jetons
sécurité à votre implémentation :
// uthorization code : Valider stricte-
A
// ecret local : L’application cliente est
S
ment les authorization codes : un code
munie d’identifiants lui permettant de
ne doit être vérifié qu’une seule fois
s’authentifier auprès du serveur OAuth,
et uniquement par le client auquel il
il ne faut pas mettre ce secret (iden-
était destiné.
tifiant du service) dans l’application
mobile ou le considérer compromis
LIMITEZ LES ADDITIFS
À peine cette première pincée d’OAuth
L’AUTHENTIFICATION CONTEXTUELLE, de définir et appliquer ces politiques
digérée, nécessaire pour débuter, se d’accès aux données en un point unique,
posent déjà des questions sur des cas
OU COMM ENT A DA PT ER L E NI V EAU au sein du serveur d’autorisation. Il s’agit
d’usages très fréquents D’ACCÈS À UNE DONNÉE EN FONCTION notamment d’un besoin essentiel lorsque
DE LA C R I T I C I T É D E C EL L E- C I l’on veut appliquer une authentification
L E SI NGLE S IGN- O N MOBILE , liée au niveau de risque du contexte
Un des nombreux enjeux concernant l’au-
OU CO MMENT P ERM E T T RE À DE S (géolocalisation, terminal connu ou non,
thentification est de simplifier au maxi-
E M PLOY ÉS EN MO BILIT É OU D E S mum l’accès des utilisateurs à leurs don-
habitudes de transactions, etc.). Et il faut
reconnaitre qu’aujourd’hui les solutions
CL I E NTS D’ACC ÉDER AIS É ME N T À nées tout en garantissant un niveau de
disponibles sur le marché n’offrent pas
PLUSIEURS APP LIC AT ION S S AN S sécurité satisfaisant. L’authentification
encore toute la souplesse requise.
SE RÉ AUTHENTIFIER ? contextuelle permet de répondre à cet
enjeu, en adaptant le niveau d’accès P R O PAG AT I O N D E L’ I D ENTI TÉ , OU
Qu’il s’agisse d’un agent terrain en contact à la nature de la transaction, à ses
clientèle ou en tournée d’intervention qui
CO M M ENT T R A NSM ET T R E UN JE TON
caractéristiques, aux habitudes
peut utiliser plus d’une dizaine d’applica- utilisateurs, à son contexte…
D’ACCÈS ENTRE DEUX APPLICATIONS
tions par jour ou qu’il s’agisse d’un client (O U P LU S) ?
Dans le cadre d’une application mobile
ayant installé plusieurs applications sur
bancaire, par exemple, cela permet à Il est de plus en plus courant qu’un appel vers
le store public, le besoin d’accéder à l’en-
l’utilisateur de consulter son compte en une API déclenche une cascade d’appels
semble des applications sans avoir à se
banque, de visualiser les soldes de ses vers d’autres API, notamment dans le cadre
réauthentifier sur chacune est aujourd’hui
comptes sans avoir à se réauthentifier d’une architecture de type micro-service. La
très présent. Depuis 2008, les tec hniques
à chaque accès. L’application requerra transmission de l’identité de l’utilisateur doit
le permettant ont varié au gré des possibi-
toutefois une authentification au moment alors être assurée tout en restant sécurisée :
lités offertes par les OS mobiles (KeyChain
de réaliser une opération sensible (un
iOS, paramètres d’URL, Mobile Device / Transmettre un seul et même jeton tout
virement interne par exemple), et une
Management…). Néanmoins, Apple et le long de la chaîne est très risqué : le
authentification forte au moment de réaliser jeton a trop de droits et son détourne-
Google ont su converger vers une solution
une opération très sensible (ajout d’un ment est possible à chaque niveau de
commune en 2015 : utiliser le navigateur
bénéficiaire par exemple). la chaîne
système comme point d’ancrage d’une
session SSO. C’est maintenant une bonne Les solutions du marché proposent / Ne vérifier l’identité de l’utilisateur
qu’en début de chaîne puis n’authen-
pratique officielle matérialisée par la Best aujourd’hui des solutions pensées selon
tifier que les services ensuite en trans-
Current Practice « OAuth2 for native appli- une logique où le client applicatif est
mettant l’identité est également risqué :
cations » responsable d’initier la demande de jeton un service compromis peut usurper
en précisant le niveau d’authentification l’identité de n’importe quel utilisateur
requis. Mais le vrai besoin est en réalité
4- https://openid.net/specs/openid-connect-core-1_0.html
3Par ailleurs, les droits (ie. scopes) contenus chaîne transite ainsi que les droits néces- Son vol est donc une menace permanente
dans le jeton initial ne correspondent peut- saires à l’appel de ce service). dont il convient de se protéger.
être pas aux droits nécessaires à chaque
Un apport majeur de cette nouvelle ciné- Deux approches sont alors possibles :
niveau de la chaîne d’appels de services.
matique est qu’elle permet de centraliser
// Tenter d’empêcher ce vol (dans un jeu
C’est pour répondre à ce cas d’usage, et à la politique d’appels entre micro-services aussi appelé « le chat et la souris »)
celui de la traçabilité de l’impersonnation, ainsi que l’application de cette même
// Rendre ce jeton nécessaire mais non
qu’un nouveau grant type est actuellement politique et donc d’assurer la traçabilité des
suffisant pour accéder à une API
proposé : Token Exchange5. appels.
Cette seconde approche, spécifiée dans le
Chaque appelant intermédiaire peut
PROTECTION CONTRE LE VOL DE JETON, draft « OAuth2 Token Binding6 », demande
échanger le jeton qu’il a reçu du
service amont (qui contient l’identité de ce
OU COMMENT SE PRÉMUNIR DU VOL au client applicatif de s’authentifier à l’aide
d’une paire de clés cryptographiques lors
dernier et celle de l’utilisateur) contre un D’UN OU D’UNE BASE DE JETONS ?
de la génération du jeton et d’utiliser cette
jeton qui pourra être transmis à une service
Dès la conception du protocole OAuth2, même paire de clés lors de l’utilisation du
aval (avec toujours l’identité de l’utilisateur,
le jeton proposé est considéré comme jeton. Jeton et paire de clés sont liés et un
les identités des services par lesquels la
suffisant pour accéder à une ressource. jeton volé sans la clé privée du client est
alors inutilisable.
ÉCRIRE ET PARTAGER LA RECETTE
Dernier ingrédient de la recette, il convient // Formant et outillant les développeurs : Au final, comme la recette du bon miel,
de décliner une architecture de référence Des sessions de formation et de pré- sécuriser des APIs nécessite une succes-
de OAuth pour l’adapter au contexte du SI sentations des principes adoptés sion d’ingrédients allant du plus basique
doivent être organisées. Les équipes
de l’entreprise. Pour cela, il faut définir le jusqu’au plus élaboré tout en tenant compte
projets peuvent être rendues auto-
cadre d’utilisation des API en : nomes dans leur intégration au reste du besoin et du contexte. Et surtout un tra-
du SI. vail en commun, dans un objectif partagé !
// Définissant et partageant les règles
de sécurité : Les cinématiques // Intégrant les ressources sécurité dans
autorisées et le cadre d’application, les sprints agiles : Les ressources
les checklists sécurité et l’archi- agissant en tant que coach sécurité
tecture de référence doivent être doivent être identifiées pour accom-
formalisées. pagner la conception applicative et
apporter des solutions prêtes à l’em-
ploi et être un accélérateur.
La recette pour des APIs sécurisées
ÉCRIRE LA RECETTE
Une architecture de référence et un cadre d’application
LIMITEZ LES ADDITIFS
Se poser la question des besoins réels vs standard
UNE PINCÉE D’OAUTH
Sans tomber dans les pièges du standard
UNE BASE DE SECURITY AS USUAL
Une API est une application web
www.wavestone.com
Wavestone est un cabinet de conseil, issu du rapprochement de Solucom et des activités européennes de Kurt Salmon (hors
consulting dans les secteurs retail & consumer goods). Il figure parmi les leaders indépendants du conseil en Europe.
5- xxxxxxxx xxxxxxxxxx La mission de Wavestone est d’éclairer et guider ses clients dans leurs décisions les plus stratégiques en s’appuyant sur une
6- xxxxxxxx xxxxxxxxxx triple expertise fonctionnelle, sectorielle et technologique.
2017 I © WAVESTONEVous pouvez aussi lire
