S’il y a bien un sujet qui a manqué au cours de mes études, c’est la sécurité informatique. Et autant certains concepts de sécurité relèvent de l’expérience ou du bon sens, autant j’ai du finir par me former sur des concepts plus poussés afin d’éviter de livrer à mes clients des gruyères. Et en arrivant sur certains projets clients développés parfois par des agences sur plusieurs années, j’y ai vu des failles assez grosses et évidentes qui pourtant n’avaient pas été corrigées, ni même parfois repérées.
Ne jetons pas la pierre trop vite, bien souvent ce genre de projet était le résultat de mois (si ce n’est plus) d’allers-retours de demandes clients avec souvent des specs qui ont changé avec le temps et on se retrouve avec une architecture lourde et incohérente. Les failles de sécurité sont souvent dues à deux facteurs majeurs:
- Le manque de temps pour terminer le projet
- Le manque de connaissances dans le domaine
Pour éviter cela, il est important que les développeurs se forment (ne serait-ce qu’aux bases) et surtout qu’ils intègrent les normes de sécurité dès le développement des fonctionnalités. Faire une passe de sécurité une fois le produit fini expose non seulement à un oubli/manque de temps, mais surtout en fait perdre puisqu’il faudra revenir sur plusieurs parties du code.
Voici donc les principaux axes à garder en tête lors du développement d’une API REST.
Gestion des accès et des droits
On pourrait penser qu’une API n’est pas ou est moins exposée que le front vu qu’elle est moins visible et n’est pas directement accessible aux utilisateurs. C’est non seulement faux (une floppée d’outils permettent de mapper le site via tous les calls qui sont faits, donc mapper l’API REST également), mais c’est surtout s’exposer à des attaques faciles et dévastatrices. Une bonne gestion de comment accéder aux ressources et de qui y a accès est donc déjà un premier élément à surveiller sur chacun de nos endpoints.
L’authentification
Vous avez créé un système de login, parfait ! Mais à quel point est-il robuste ?
Il n’est pas rare de tomber sur des identifiants par défaut, même parfois chez des gros groupes (il suffit de regarder les résultats de Bugs Bounty pour s’en convaincre). Et il y a une grosse différence de ce qu’on peut faire entre une visite anonyme d’un site et le moment où on y accède en tant qu’utilisateur ! Ajouter à votre form de login un rate limiting ou un captcha (voire directement un fail2ban sur le serveur si vous y avez accès) permet d’éviter au maximum le bruteforce.
La sécurité des JWT générés est aussi un gros sujet, mais il fera l’objet d’un article à part tant il y a des choses à dire dessus. Pensez simplement à garder vos packages à jour et à utiliser des clés suffisamment longues et aléatoires.
L’accès aux endpoints
Ça semble évident, pourtant je retrouve plus souvent qu’on ne pourrait le penser des routes exposées à un utilisateur anonyme. Parfois parce qu’on les pense suffisamment cachées, parfois parce qu’y accéder sans token génère de toutes façons une erreur.
Le jour où quelqu’un veut réellement s’en prendre à vous (ce que je ne vous souhaite pas), il ne se contentera pas d’un scrapper pour voir quelles sont toutes les routes exposées. Il viendra utiliser des outils pour tester différentes combinaisons et repérer toutes les routes possibles. Si on respecte les bests practices (rien ne ressemble plus à une API REST qu’une autre API REST), on gardera une cohérence sur toutes nos routes, donc si un bouton supprimer appelle l’endpoint DELETE /post/:id, il existe sûrement une route pour les admins de type DELETE/user/:id vu que je récupère un profil avec un GET /user/:id. Et avec des outils comme FUFF, il est très simple de venir vérifier en quelques instants toute une série d’endoints communs et faire un mapping plus précis de votre API.
Les IDOR
Probablement une de celles que j’ai le plus croisé. Vous avez bien pensé à ne rendre les routes sensibles accessibles qu’aux admins, génial ! Mais vos efforts peuvent être vains si les accès aux routes classiques ne sont pas bien gérées. Je m’explique !
Imaginez une route pour changer son adresse email. Il arrive que pour garder une structure linéaire vous décidiez de faire un endpoint dans ce style: POST /user/:id/update. Que se passe t’il si vous remplacez votre id par un autre dans l’URL ? Si vous réussissez à récupérer (en listant tous les utilisateurs par exemple) l’id d’un admin, vous éditez son email pour le remplacer par un à vous. Même si la route d’édition de mot de passe est sécurisé, vous pouvez désormais faire une demande de réinitialisation de mot de passe qui atterrira donc dans votre boîte. Ça n’est qu’un exemple parmi tant d’autres, il est également assez simple de poster des XSS chez les autres pour récupérer quelques tokens via cette méthode.
Vérifiez donc sur chaque route quels accès sont donnés et si un utilisateur malicieux pourrait en détourner l’usage. Le mieux est de stocker l’id de l’utilisateur courant dans le JWT et de ne se servir que de ça pour savoir qui doit être modifié.
Filtrez tous, tout le temps
« Never trust user input« , on l’entend souvent, mais on doit l’appliquer constamment. Les injections font partie chaque année du top 10 de l’OWASP. XSS, Injection de commandes, Injections SQL, …, il y en a pour tous les goûts !
Les données peuvent être filtrées à deux moments: à l’entrée et à la sortie. Les données qui sont récupérées peuvent facilement faire du dégat même sans être stockées. Au moment même de la récupération il est important de vérifier à quoi est destinée chaque donnée et faire un petit coup de nettoyage tant des paramètres d’URL, des données GET que des données POST. Pour la sortie, même idée. Pour éviter de transmettre au front des XSS ou autres codes malicieux, il est important de venir nettoyer tous les champs envoyés, même s’ils ne sont pas directement affichés à l’utilisateur.
Conclusion
Il existe encore bon nombre de failles possibles sur les API REST, mais moins communes que celles citées (et surtout il faudrait plusieurs articles pour tout analyser). En prenant au moins garde à appliquer ces différents points dès la conception du projet, il s’en verra grandement renforcé à toutes les petites attaques communes et simples à repérer à qui connaît un tant soi peu les notions de sécurité.
Il est important que les développeurs s’éduquent sur ce sujet, mais aussi les clients et chefs de projets. Souvent la notion de sécurité est mise de côté pour des raisons de temps ou de budget, mais c’est s’exposer à de gros risques. Ce qui peut être le meilleur moyen de perdre du temps et de l’argent en fin de compte !
