Cloud moderne Les stratégies font un usage intensif des API pour un accès contrôlé et interactif aux services hébergés. Mais l'accès n'est contrôlé que si les API sont implémentées de manière sécurisée et qu'elles ne sont pas susceptibles d'abus.
API Web
Une interface de programmation d'applications (API) permet au logiciel de communiquer avec d'autres logiciels. Cela nécessite un cahier des charges. Il doit exister un ensemble documenté de fonctions fournies par le point de terminaison de l'API et des règles sur ce que le client API doit faire pour utiliser ces fonctions. Le type et le format des données renvoyées par l'API doivent être définis pour chaque fonction. Vous souhaitez généralement restreindre l'accès à l'API, les clients API doivent donc s'authentifier d'une manière ou d'une autre. Dans une API restreinte, les demandes ne doivent être traitées que lorsque le point de terminaison de l'API a vérifié que la demande est légitime.
Comme pour tout développement de logiciels, une méthodologie de sécurité dès la conception est bien meilleure qu'une approche de construction d'abord, de sécurisation ultérieure. Le désastre de l'API Peloton l'illustre parfaitement. Une implémentation d'API défectueuse—qui est désormais corrigée—autorisait le service des appels d'API non authentifiés.
N'importe qui peut récupérer des données personnelles sur n'importe quel client Peloton. Le premier “correctif” simplement restreint l'API aux propriétaires de Peloton. Ce n'était que légèrement mieux. Avec le correctif final en place, les données d'un utilisateur Peloton sont enfin privées, à moins qu'il ne choisisse explicitement de les partager.
Il existe de nombreux autres exemples d'API faibles ou mal conçues. Facebook a exposé les données personnelles de 533 millions de ses utilisateurs car une API permettait à n'importe qui de rechercher dans une base de données à l'aide de numéros de téléphone—à un rythme allant jusqu'à 1 000 par minute.
Publicité
Plus de 80% de tout le trafic Internet est du trafic API. Cela fait beaucoup d'API. À la mi-2021, les 10 principaux risques de sécurité de l'Open Web Application Security Project (OWASP) n'avaient pas changé depuis plusieurs années. Malheureusement, les mêmes erreurs conduisant aux mêmes vulnérabilités se répètent encore et encore. Et c'est trop attrayant pour que les cybercriminels l'ignorent.
Partenaires du développement
Les API sont souvent moins bien protégées que les sites Web et les applications mobiles. Les exigences de performance peuvent forcer l'équipe de développement à se concentrer sur les rendre légères et efficaces. Tellement léger qu'ils contiennent très peu de code, voire aucun, consacré à la protection de l'API et des données qu'elles protègent. Une API mal conçue ou mal implémentée aura des faiblesses qui pourront être exploitées. La correction appropriée n'est pas de coller un pansement dessus et d'essayer de boucher les trous. Vous devez corriger le code, ou éventuellement la logique métier qui a été modélisée dans l'API.
Lorsque de nombreux composants logiciels communiquent entre eux via des appels d'API, tels que des microservices, il devient très difficile de détecter les erreurs de processus de la couche métier. Votre code peut réussir les tests unitaires, de régression et autres. Vous pouvez ne rencontrer aucun plantage. Tous vos journaux sont propres. Mais cela ne signifie pas que la logique est correcte, ni que toutes les vulnérabilités possibles ont été prises en compte. Réunir votre équipe de sécurité et votre équipe de développement peut produire des informations surprenantes.
L'équipe de développement est responsable de la rédaction des API qui fournissent les fonctionnalités requises. L'équipe de sécurité est responsable de la protection des données gérées via l'API. Ils sont tous deux acteurs de la réussite du processus de développement. Les développeurs ne penseront jamais à la sécurité, aux menaces et aux attaques comme l'équipe de sécurité. Pourquoi ne pas apporter les deux expertises pour résoudre le problème ?
Types d'attaques
Les types d'attaques courants que vous rencontrerez peuvent être regroupés en fonction de leur technique d'attaque.
- Credential Stuffing : similaire aux attaques par force brute par mot de passe, mais il utilise les informations d'identification de l'API au lieu des mots de passe des comptes utilisateur.< /li>
- Attaques par injection: Dans une attaque par injection, le cybercriminel ajoute des instructions informatiques à ses requêtes API de manière à ce que les instructions intégrées agissent sur le point de terminaison API. L'injection SQL est une attaque qui exploite les bases de données SQL. Il est souvent facile de déterminer quels éléments de texte d'un appel d'API seront inclus dans les instructions SQL. L'ajout d'instructions SQL à ces appels de fonction d'API peut conduire à ce que ces extraits de code SQL soient traités par les serveurs SQL de point de terminaison d'API. Les scripts intersites est une attaque similaire dans laquelle les instructions intégrées sont dans un langage de script, généralement JavaScript.
- Déni de service distribué (DDoS) : ces attaques sont très similaires aux attaques DDoS qui inondent un site Web de trafic, l'empêchant de répondre aux demandes authentiques. Les attaques DDoS visant les points de terminaison d'API gagnent en popularité auprès des acteurs de la menace.
- Man-in-the-Middle (MitM)Ces attaques reposent sur l'interception du trafic entre un client API authentique et innocent et le point de terminaison de l'API. Si les informations d'authentification de l'API sont capturées, elles peuvent être utilisées pour se reconnecter en se faisant passer pour le véritable client API. Parfois, les appels d'API effectués à partir du client authentique sont modifiés afin que le point de terminaison de l'API fasse ce que veulent les attaquants, et non ce que le client réel veut.
Protection Vos API
Lorsque vous cherchez à sécuriser un sous-ensemble de votre infrastructure informatique, il peut être tentant de rechercher des solutions spécifiques ou innovantes. Mais n'oubliez pas les bases de la cybersécurité.
Quantifiez ce à quoi vous avez affaire
Si vous ne savez pas ce que vous avez, vous ne pouvez pas le gérer. Vous devez identifier et caractériser toutes les API que vous utilisez, que vous les ayez créées ou non. Les résultats de votre audit d'API peuvent révéler des opportunités de simplifier ou de rationaliser votre utilisation des API. Il mettra également en évidence toutes les API anciennes ou orphelines qui doivent être mises à jour ou désactivées.
Publicité
Une fois que vous savez de quelles API vous disposez, ce qu'elles font et comment elles sont protégées et rendues résilientes, vous pouvez documenter votre stratégie de sécurité des API. Profitez de l'occasion pour définir des règles de base pour un développement axé sur la sécurité et planifier votre feuille de route API.
Quelles données sont accessibles via les appels d'API ? S'agit-il d'informations personnellement identifiables ou sensibles d'une autre manière ? Quelle est sa classification des données ? Si vos politiques de protection des données ont été correctement mises en œuvre, elles contiendront déjà ces informations. Examinez de manière critique l'accès aux données. Révélez-vous plus de données que nécessaire ?
Rendez vos API concises
Vouloir faire de votre API une expérience riche pour le consommateur de données peut conduire à des rapports excessifs et à la divulgation inutile de détails sur le point de terminaison de l'API lui-même. Les informations sur les personnes concernées, les clés de chiffrement et les jetons d'authentification ont toutes été divulguées par des API trop verbeuses. Une approche plus réfléchie et sécurisée consiste à renvoyer la quantité minimale de données dont le client API a besoin pour remplir la fonction demandée.
Cela revient au principe de moindre autorisation, un élément de base de la cybersécurité. Vous ne devez accorder aux utilisateurs, processus, appareils IoT ou tout autre élément interagissant avec votre service informatique que les privilèges minimaux requis pour que leur rôle ou leur fonction soit rempli. Faites de même avec vos API.
Utilisez le cryptage
Chiffrez votre trafic API à l'aide de TSL, le successeur de SSL. Ne vous laissez pas guider par la valeur des données. N'oubliez pas que vous protégez également les jetons d'authentification des clients API. Les attaquants peuvent ne pas se soucier des données. Mais, s'ils acquièrent des jetons d'authentification, ils pourront peut-être utiliser l'API pour extraire plus d'indices sur vos systèmes afin de pouvoir lancer différentes attaques.
Authentification et Valeurs d'entrée
Évidemment, vous devez avoir un système d'authentification fort. Ne réinventez pas la roue. Dans la mesure du possible, utilisez une solution reconnue telle que OAuth2.0. Vous pourriez penser que les API internes n'ont pas besoin de s'authentifier. Mais pouvez-vous garantir qu'une API interne ne sera pas rendue publique par erreur, peut-être parce qu'elle est réutilisée dans un autre projet ?
Publicité
N'acceptez jamais aveuglément une entrée d'une API sans la valider premier. Analysez-le à la recherche de contenu mal formé, de scripts intégrés et d'attaques par débordement.
Soyez conscient de la fréquence des demandes de connexion et appliquez des mesures raisonnables de limitation du débit. Est-ce qu'un visiteur fréquent essaie de forcer son chemin ou essaie-t-il de siphonner des données de votre base de données, demande par demande ?
Allied Technologies
Les pare-feu d'applications Web (WAF) aident à protéger les sites Web, les applications hébergées et les API en filtrant et en surveillant le trafic vers et depuis la ressource protégée. Ils peuvent détecter des attaques telles que les scripts intersites et l'injection SQL, entre autres. Un WAF est une technologie de protection de la couche application (niveau 7 dans le modèle ISO), et non une solution adaptable à l'ensemble de la sécurité de votre site Web ou de votre API. Ils sont mieux déployés en tant qu'élément d'une suite de défenses en couches.
Une passerelle API se situe entre le point de terminaison de l'API et les clients de l'API. Ils négocient les demandes d'API entre les clients et le point de terminaison de l'API, divisant parfois une demande en morceaux plus petits qui sont desservis par différents microservices principaux. les réponses sont rassemblées et renvoyées au client API. Les passerelles API peuvent s'intégrer ou fournir des fonctionnalités d'authentification et de limitation de débit. Des passerelles API Software-as-a-Service sont disponibles, offrant une haute disponibilité et une mise à l'échelle automatique.
Les API sont en première ligne
Avec l'essor incessant du cloud et des microservices, les API se retrouvent en première ligne des cyberattaques. Les cybercriminels aiment les chances quand ils sont empilés en leur faveur. avec autant d'API, il est inévitable que beaucoup d'entre elles soient mal protégées ou même non protégées. Ne les laissez pas être les vôtres.