jeu, 10/12/2020 - 13:12
Les API (ou interfaces de programmation d’applications) sont un moyen pour les développeurs d’appeler des informations provenant de sources externes afin de les importer dans les applications qu’ils créent. Elles simplifient le processus de codage, tout en donnant accès à une multitude de données et de ressources auparavant inaccessibles, d’où leur importance pour les développeurs d’applications. Les API sont également une véritable aubaine pour les fournisseurs de services. Elles leur offrent de nouvelles sources de revenus en leur permettant de mettre des données et services de valeur à la disposition des développeurs. Enfin, les API profitent aux utilisateurs finaux et aux clients, toujours à la recherche d’applications innovantes, riches en fonctionnalités et interactives.
Comprendre les risques potentiels liés aux API
Les API devenant une composante fondamentale du développement d’applications modernes, la surface d’attaque ne cesse de s’étendre. Le cabinet Gartner estime que, d’ici 2022, l’utilisation frauduleuse des API constituera « le vecteur d’attaque le plus fréquent et entraînera des violations de données au niveau des applications Web d’entreprise ».
L’inconvénient des API Web publiques est qu’elles présentent des risques. De par leur conception, elles permettent à des personnes extérieures d’accéder aux données. Derrière chaque API se cache un endpoint, à savoir le serveur (et ses bases de données) qui répond aux requêtes. Les endpoints sont similaires aux serveurs Web connectés à Internet et comportent les mêmes risques. La différence est que de nombreux sites Web emploient généralement une certaine forme de contrôle des accès, ce qui est beaucoup moins le cas des API.
Dans le pire des scénarios, ce ne sont pas seulement les données qui courent un danger, mais aussi l’infrastructure. Les API vulnérables sont le point de départ idéal à diverses attaques de détournement de réseau. Une attaque efficace (le plus souvent multiniveau) peut potentiellement compromettre des données sensibles, qu’il s’agisse d’informations d’identification personnelles ou d’éléments de propriété intellectuelle.
Attaques courantes contre les API Web
Les API subissent un grand nombre d’attaques similaires à celles visant le réseau et les applications Web. Les attaques les plus courantes, et les mesures associées d’atténuation des risques, sont les suivantes :
Type d’attaque | Mesures d’atténuation des risques |
Une injection se produit lorsqu’un attaquant insère des commandes ou du code malveillants dans un programme, généralement à la place d’une entrée utilisateur ordinaire (comme un nom d’utilisateur ou un mot de passe). Les injections SQL sont un type spécifique d’attaque par injection qui permet à l’attaquant de prendre le contrôle d’une base de données SQL. | Validation et nettoyage de toutes les données dans les requêtes d’API. Restriction des données de réponse pour éviter les fuites involontaires de données sensibles. |
Le Cross-Site Scripting (XSS) est un type d’attaque par injection au cours de laquelle un cybercriminel profite d’une vulnérabilité pour insérer un script malveillant (souvent en JavaScript) dans le code d’une application ou page Web. | Validation des données en entrée. Filtrage et échappement de caractères. |
Les attaques par déni de service distribué (Distributed Denial-of-Service ou DDoS) rendent un réseau, un système ou un site Web indisponible pour ses utilisateurs, le plus souvent en générant une quantité de trafic supérieure à celle qu’il peut prendre en charge. Les endpoints d’API s’ajoutent à la liste de plus en plus longue des cibles DDoS. | Limitation du trafic et de la taille de la charge utile. |
Les attaques Man-in-the-Middle (MitM), se produisent lorsqu’un cybercriminel intercepte le trafic entre deux systèmes communicants et se fait passer pour l’autre auprès de chacun d’eux, agissant ainsi comme un intermédiaire invisible. Avec les API, les attaques MitM peuvent survenir entre le client (application) et l’API, ou entre l’API et son endpoint. | Chiffrement du trafic en transit. |
Le credential stuffing désigne l’utilisation d’informations d’identification volées sur les endpoints d’authentification des API pour obtenir un accès non autorisé. | Exploitation d’un flux de renseignements pour identifier le credential stuffing et définition de limites de trafic afin de contrôler les attaques par force brute. |
Les meilleures pratiques pour assurer la sécurité des API
En plus des mesures d’atténuation des risques décrites ci-avant, l’adoption de certaines pratiques de sécurité élémentaires, et l’application de contrôles de sécurité bien établis, sont primordiales si les entreprises envisagent de partager leurs API publiquement. Les principes suivants doivent notamment être observés :
- Privilégier la sécurité. La sécurité des API ne doit pas passer au second plan. Il s’agit d’une priorité à intégrer dans les API lors de leur développement.
- Tenir à jour un inventaire des API et les gérer. L’entreprise doit procéder à des analyses du périmètre pour identifier et inventorier ses API, puis les gérer en collaboration avec les équipes DevOps.
- Utiliser une authentification et une autorisation fortes. Un système d’authentification et d’autorisation inefficace ou inexistant constitue un problème majeur. Le processus d’authentification peut être compromis si les API n’imposent pas l’authentification (comme c’est souvent le cas des API privées, qui sont exclusivement réservées à un usage interne) ou qu’un facteur d’authentification (quelque chose que le client « connaît », « possède » ou « est ») est facilement piratable. Sachant que les API fournissent un point d’entrée aux bases de données de l’entreprise, il est essentiel que celle-ci en contrôle strictement l’accès. Si cela est possible, il convient de recourir à des solutions basées sur des mécanismes d’authentification et d’autorisation solides et éprouvés tels qu’OAuth 2.0 et OpenID Connect.
- Appliquer le principe de moindre privilège. Un sujet (utilisateur, processus, programme, système, appareil) ne doit pas se voir accorder des droits d’accès supérieurs à ceux nécessaires pour remplir une fonction donnée.
- Chiffrer le trafic à l’aide de TLS. Le chiffrement TLS est indispensable aux entreprises possédant des API qui échangent régulièrement des données sensibles (identifiants de connexion, informations de carte de crédit, numéros de sécurité sociale, renseignements médicaux ou bancaires, etc.).
- Supprimer les informations non destinées à être partagées. Les API sont des composants qui s’adressent essentiellement aux développeurs. C’est pourquoi elles renferment souvent des clés, mots de passe et autres informations qu’il faut supprimer avant la mise à disposition publique. Or, cette étape est parfois négligée. Les entreprises doivent intégrer des outils d’analyse dans leurs processus DevSecOps afin de limiter l’exposition accidentelle d’informations confidentielles.
- Ne pas exposer plus de données que nécessaire. Les API ne doivent pas renvoyer plus d’informations que nécessaire pour remplir leur fonction. Il est également important d’appliquer des contrôles d’accès aux données au niveau de l’API, de surveiller les données et d’offusquer les informations confidentielles contenues dans la réponse.
- Valider les données en entrée. Les données en entrée ne doivent jamais être transmises des API aux endpoints sans une validation préalable.
- Limiter le trafic. La définition d’un seuil au-delà duquel les requêtes seront rejetées (par exemple, 10 000 requêtes par jour et par compte) peut empêcher les attaques par déni de service.
- Utiliser un pare-feu d’application Web capable de comprendre les charges utiles des API.
Les API s’imposent rapidement comme la méthode privilégiée de création d’applications modernes, en particulier pour les appareils mobiles et l’Internet des objets (IoT). Toutefois, face à l’évolution constante des méthodes de développement d’applications et aux pressions de l’innovation, certaines entreprises n’ont pas pleinement saisi les risques potentiels liés à la mise à disposition publique de leurs API.
La bonne nouvelle est que la plupart d’entre elles ont déjà instauré des mesures pour combattre des attaques bien connues telles que le Cross-Site Scripting, l’injection et le déni de service distribué. En cas de doute sur la façon de s’y prendre, il suffit de commencer par le haut de la liste et de descendre. Indépendamment du nombre d’API qu’elle décide de partager publiquement, l’entreprise ne doit jamais perdre de vue la mise en place en amont de règles de sécurité solides et leur gestion proactive au fil du temps.
A propos de l'auteur
