Guide de sécurité de l’API REST

La connaissance de la sécurisation des API REST est aussi importante que d’écrire les API elles-mêmes. La plupart des API REST sont basées sur un protocole HTTP, et tout utilisateur disposant d’une connexion Internet peut y accéder, tout comme les mauvais utilisateurs. Il est très important d’écrire des API sécurisées pour protéger l’entreprise.

Avant de commencer à sécuriser les API RESTful, comprenons quelles sont toutes nos options en tant que développeurs ? Quel sera le bon ajustement pour notre cas d’utilisation?

Table of Contents1. Authentication vs. Authorization2. Four Ways to Secure RESTful Web Services- BASIC Authentication- DIGEST Authentication- Client CERT Authentication- OAUTH2 API Keys3. RESTful Web Services Security Implementations- Using SecurityContext- Using Annotations4. Best Practices

Différence entre l’authentification et autorisation

Avant de passer à la discussion principale, clarifions nos faits sur ce qu’est l’authentification et ce qu’est l’autorisation.

En anglais simple, l’authentification est le processus consistant à vérifier que « l’utilisateur est vraiment quelqu’un qu’il prétend être ». En termes techniques, il s’agit d’un processus de connexion au système via un nom d’utilisateur / mot de passe ou tout autre mécanisme similaire, par exemple une analyse des empreintes digitales, un jeton de sécurité, des questions de sécurité ou un jeton SAML reçu de la connexion SSO. Il doit y avoir quelque chose qui peut identifier l’utilisateur des autres.

Une fois que l’utilisateur est dans le système, l’autorisation fait référence à des règles qui déterminent « ce que l’utilisateur est autorisé à faire » et ce qu’il n’est pas, par exemple, un utilisateur normal peut poster un message dans n’importe quel groupe public, mais les utilisateurs uniquement avec un rôle d’éditeur pourront supprimer quelque chose. L’autorisation est souvent considérée à la fois comme la configuration initiale des autorisations par un administrateur système et la vérification des valeurs d’autorisation qui ont déjà été configurées lorsqu’un utilisateur accède au système.

Lorsque nous sécurisons des services Web RESTful, nous devons prendre en charge les deux facteurs. Les deux concepts sont complètement orthogonaux et indépendants, mais les deux sont au cœur de la conception de la sécurité, et le fait de ne pas obtenir l’un ou l’autre de ces concepts augmente les risques de compromission du système..

Quatre façons de sécuriser les Services Web RESTful

Il existe plusieurs façons de sécuriser une API RESTful en Java. Passons en revue les 4 choix les plus populaires:

2.1. Authentification DE BASE

C’est la technique la plus simple de toutes et probablement la plus utilisée également. Vous utilisez des formulaires de connexion / mot de passe – il s’agit uniquement d’une authentification de base. Vous entrez votre nom d’utilisateur et votre mot de passe et soumettez le formulaire au serveur, et l’application vous identifie en tant qu’utilisateur – vous êtes autorisé à utiliser le système – sinon vous obtenez une erreur.

Le principal problème de cette implémentation de sécurité est que les informations d’identification sont propagées de manière simple du client au serveur. Les informations d’identification sont simplement codées avec Base64 en transit, mais pas cryptées ou hachées de quelque manière que ce soit. De cette façon, n’importe quel renifleur pouvait lire les paquets envoyés sur le réseau.

HTTPS est donc généralement préféré ou utilisé en conjonction avec l’authentification de base, ce qui rend la conversation avec le serveur Web entièrement cryptée. La meilleure partie est que personne ne peut même deviner de l’extérieur que l’authentification de base a lieu.

2.2. Authentification DIGEST

Cette méthode d’authentification utilise un algorithme de hachage pour chiffrer le mot de passe (appelé hachage de mot de passe) entré par l’utilisateur avant de l’envoyer au serveur. Cela le rend évidemment beaucoup plus sûr que la méthode d’authentification de base, dans laquelle le mot de passe de l’utilisateur se déplace en texte brut qui peut être facilement lu par quiconque l’intercepte.

En savoir plus: Générer des mots de passe cryptés

Il existe également de nombreux algorithmes de hachage de ce type en Java, qui peuvent s’avérer vraiment efficaces pour la sécurité des mots de passe tels que les algorithmes MD5, SHA, BCrypt, SCrypt et PBKDF2WithHmacSHA1.

N’oubliez pas qu’une fois que ce hachage de mot de passe est généré et stocké dans la base de données, vous ne pouvez pas le convertir en mot de passe d’origine. Chaque fois que l’utilisateur se connecte à l’application, vous devez régénérer à nouveau le hachage du mot de passe et le faire correspondre au hachage stocké dans la base de données. Ainsi, si l’utilisateur a oublié son mot de passe, vous devrez lui envoyer un mot de passe temporaire et lui demander de le changer avec son nouveau mot de passe. Eh bien, c’est une tendance courante de nos jours.

2.3. Authentification par certificat client

Il s’agit d’un mécanisme dans lequel un accord de confiance est établi entre le serveur et le client via des certificats. Ils doivent être signés par une agence établie pour s’assurer que le certificat présenté pour l’authentification est légitime, ce qui est connu sous le nom de CA.

En utilisant cette technique, lorsque le client tente d’accéder à une ressource protégée, au lieu de fournir un nom d’utilisateur ou un mot de passe, il présente le certificat au serveur. Le certificat contient les informations de l’utilisateur pour l’authentification, y compris les informations d’identification de sécurité, en plus d’une paire de clés privée-publique unique. Le serveur détermine ensuite si l’utilisateur est légitime via l’autorité de certification. De plus, il doit vérifier si l’utilisateur a accès à la ressource. Ce mécanisme doit utiliser HTTPS comme protocole de communication car nous n’avons pas de canal sécurisé pour empêcher quiconque de voler l’identité du client.

Vous pouvez trouver un tutoriel complet pour générer un certificat de sécurité dans les documents officiels oracle.

2.4. Clés API OAUTH2

Si vous avez déjà développé des applications qui interagissent avec d’autres applications sur le cloud, par exemple l’intégration Facebook ou l’authentification Twitter, etc. ensuite, vous l’avez déjà utilisé. Ils exigent que vous fournissiez une clé d’API et un secret d’API pour vous identifier correctement. Ces clés et secrets d’API sont une chaîne codée aléatoire impossible à deviner.

Pour comprendre comment cela fonctionne, supposons que vous utilisiez un Flickr (application de partage de photos) et que vous souhaitiez publier certaines de vos photos en utilisant son API REST. Vous créez la demande comme documentée dans Flickr docs, puis vous l’envoyez.

Puis, lors de la réception de la requête, Flickr authentifie l’utilisateur en lisant les informations de la clé API avec la clé secrète qui lui appartient. Une fois ces validations réussies, le serveur délivre la réponse au client. Ainsi, nous obtenons une réponse avec toutes les photos qui ont été récemment postées sur Flickr.

Comme vous le remarquerez, de cette façon, vous pouvez facilement créer des applications en utilisant l’API du fournisseur. En outre, le fournisseur vous permettra de vous authentifier, d’accéder aux informations publiques.

Si quelqu’un commence à manquer de respect aux accords, par exemple l’envoi de trafic indésirable ou toute violation de stratégie, le fournisseur retire la clé API et empêche l’utilisation abusive de ses API.

Implémentations de sécurité de l’API REST

En dehors des concepts ci-dessus, vous devrez généralement sécuriser vos API RESTful dans votre entreprise en utilisant les méthodes ci-dessous.

3.1. Instance JAX-RS SecurityContext

L’interface javax.ws.rs.core.SecurityContext permet d’accéder aux informations liées à la sécurité pour une requête et est très similaire à javax.servlet.http.HttpServletRequest.

Vous accédez au SecurityContext en injectant une instance dans un champ de classe, une méthode setter ou un paramètre de méthode à l’aide de l’annotation javax.ws.rs.core.Context, par exemple dans le code ci-dessous sc.isUserInRole() est utilisé pour vérifier l’autorisation de l’utilisateur.

3.2. Annotations JAR-RS pour l’autorisation au niveau de la méthode

Cette technique est largement utilisée dans les applications d’entreprise et utilisée pour vérifier les rôles et les responsabilités d’un utilisateur authentifié – pour toute opération spécifique. JAX-RS fournit les annotations ci-dessous à cet effet.

• @ PermitAll
• @DenyAll
• @RolesAllowed

Un exemple d’utilisation de l’annotation peut être:

Lire La Suite : Exemple d’authentification et d’autorisation JAX-RS

Meilleures pratiques de sécurité de l’API REST

Notons quelques points importants lors de la conception de la sécurité de vos services Web RESTful.

1. Utilisez uniquement le protocole HTTPS afin que toute votre communication soit toujours cryptée.
2. N’envoyez jamais d’informations d’identification d’authentification ou de clés d’API en tant que paramètre de requête. Ils apparaissent dans l’URL et peuvent être facilement enregistrés ou suivis.
3. Utilisez toujours le niveau de cryptage le plus difficile. Cela aidera à avoir plus de confiance.
4. Pour les ressources exposées par les services Web RESTful, il est important de s’assurer que toute demande PUT, POST et DELETE est protégée contre la falsification de demandes intersite.
5. Validez toujours les données d’entrée dès que possible, elles sont reçues dans la méthode du serveur. Utilisez uniquement des données primitives comme paramètre d’entrée autant que possible.
6. S’appuyer sur les fonctionnalités de validation fournies par le framework car elles sont déjà testées par une grande communauté.

Faites-moi part de vos réflexions et expériences sur la façon de sécuriser les services Web RESTful dans votre organisation.

Bon apprentissage!!