Nous annonçons aujourd'hui le lancement de la solution Cloudflare Sequence Analytics destinée aux API. Grâce à cette solution, les clients abonnés au service API Gateway peuvent voir les plus importantes séquences de requêtes d'API vers leurs points de terminaison. Cette nouvelle fonctionnalité aidera les clients à déployer une protection sur les points de terminaison les plus importants en premier lieu.
Qu'est-ce qu'une séquence ? Il s'agit simplement d'une liste chronologique des requêtes d'API HTTP effectuées par un visiteur spécifique pendant qu'il navigue sur un site web, qu'il utilise une application mobile ou qu'il interagit avec un partenaire B2B via API. Une partie d'une séquence effectuée pendant un transfert de fonds bancaires pourrait, par exemple, ressembler à ce qui suit :
.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-1wig{font-weight:bold;text-align:left;vertical-align:top} .tg .tg-0lax{text-align:left;vertical-align:top}
| Order | Method | Path | Description |
|---|---|---|---|
| 1 | GET | /api/v1/users/{user_id}/accounts | user_id is the active user |
| 2 | GET | /api/v1/accounts/{account_id}/balance | account_id is one of the user’s accounts |
| 3 | GET | /api/v1/accounts/{account_id}/balance | account_id is a different account belonging to the user |
| 4 | POST | /api/v1/transferFunds | Containing a request body detailing an account to transfer funds from, an account to transfer funds to, and an amount of money to transfer |
Order
Méthode
Chemin d'accès
Description
1
GET
| Order | Method | Path | Description |
|---|---|---|---|
| 1 | GET | /api/v1/users/{user_id}/accounts | user_id is the active user |
| 2 | GET | /api/v1/accounts/{account_id}/balance | account_id is one of the user’s accounts |
| 3 | GET | /api/v1/accounts/{account_id}/balance | account_id is a different account belonging to the user |
| 4 | POST | /api/v1/transferFunds | Containing a request body detailing an account to transfer funds from, an account to transfer funds to, and an amount of money to transfer |
| … attacker copies the request to a debugging tool like Postman … | |||
| 5 | POST | /api/v1/transferFunds | Attacker has modified the POST body to try and trick the API |
| 6 | POST | /api/v1/transferFunds | A further modified POST body to try and trick the API |
| 7 | POST | /api/v1/transferFunds | Another, further modified POST body to try and trick the API |
/api/v1/users/{user_id}/accounts
user_id est l'utilisateur actif
2
GET
/api/v1/accounts/{account_id}/balance
account_id est l'un des comptes de l'utilisateur
3
GET
/api/v1/accounts/{account_id}/balance
account_id est un compte différent appartenant à l'utilisateur
4
POST
/api/v1/transferFunds
Contient un corps de requête détaillant un compte à partir duquel transférer les fonds, un compte vers lequel transférer les fonds et un montant à transférer
Pourquoi est-il important de prêter attention aux séquences concernant la sécurité des API ? Si l'API ci-dessus recevait des requêtes POST /api/v1/transferFunds sans les requêtes précédentes, l'opération paraîtrait suspecte. Comment le client de l'API pourrait-il connaître les ID des comptes concernés sans en dresser la liste pour l'utilisateur ? Comment le client de l'API pourrait-il savoir quel montant est disponible pour le transfert ? Si cet exemple peut sembler évident, le volume même de requêtes d'API vers n'importe quelle API de production peut compliquer la tâche aux analystes humains tentant de repérer les cas d'utilisation suspecte.
Dans le domaine de la sécurité, une approche de la défense contre un nombre incalculable de menaces impossibles à filtrer par une équipe humaine consiste à créer un modèle de sécurité positive. Plutôt que d'essayer de bloquer tous les événements potentiellement susceptibles d'être une menace, vous autorisez ainsi l'ensemble du trafic connu (anodin ou utile) et bloquez tout le reste par défaut.
Les clients pouvaient déjà créer des modèles de sécurité positive avec API Gateway dans deux secteurs principaux : la protection contre les abus volumétriques et la validation de schéma. Les séquences formeront le troisième pilier d'un modèle de sécurité positive pour le trafic lié aux API. La solution API Gateway pourra faire appliquer la préséance des points de terminaison au sein d'une séquence API donnée. En établissant la préséance au sein d'une séquence API, le service API Gateway journalisera ou bloquera n'importe quel trafic ne correspondant pas aux attentes et contribuera ainsi à la réduction du trafic abusif.
Détection des abus par la séquence
Lorsque des acteurs malveillants tentent d'exfiltrer des données de manière abusive, ils suivent rarement les schémas attendus pour le trafic API. Les attaques font souvent usage de logiciels spécialisés pour « tromper » l'API. Ces derniers envoient alors plusieurs requêtes dotées de différents paramètres de requête en espérant trouver des réponses inattendues de la part de l'API, qui indiqueraient des occasions d'exfiltrer des données. Les pirates peuvent également envoyer manuellement des requêtes conçues pour amener les API à exécuter des actions non autorisées, comme accorder des privilèges plus élevés à un acteur malveillant ou octroyer un accès aux données par l'intermédiaire d'une attaque Broken Object Level Authentification (Violation de l'authentification au niveau de l'objet). La protection des API à l'aide de mesures de limitation du débit constitue une bonne pratique courante. Toutefois, dans les deux exemples ci-dessus, les acteurs malveillants peuvent délibérément exécuter des séquences de requêtes plus lentement, afin d'essayer de déjouer la détection des abus volumétriques.
Repensez à la séquence de requêtes ci-dessus, mais cette fois, imaginez qu'un acteur malveillant tente de copier la requête de transfert de fonds légitime et de modifier le contenu de cette dernière dans l'optique de piéger le système :
.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-1wig{font-weight:bold;text-align:left;vertical-align:top} .tg .tg-0lax{text-align:left;vertical-align:top} .tg .tg-5frq{font-style:italic;text-align:center;vertical-align:top} .tg .tg-8zwo{font-style:italic;text-align:left;vertical-align:top}
Order
Méthode
Chemin d'accès
Description
1
GET
/api/v1/users/{user_id}/accounts
user_id est l'utilisateur actif
2
GET
/api/v1/accounts/{account_id}/balance
account_id est l'un des comptes de l'utilisateur
3
GET
/api/v1/accounts/{account_id}/balance
account_id est un compte différent appartenant à l'utilisateur
4
POST
/api/v1/transferFunds
Contient un corps de requête détaillant un compte à partir duquel transférer les fonds, un compte vers lequel transférer les fonds et un montant à transférer
… l'acteur malveillant copie la requête dans un outil de débogage, comme Postman…
5
POST
/api/v1/transferFunds
L'acteur malveillant a modifié le corps de la requête POST afin d'essayer de duper l'API
6
POST
/api/v1/transferFunds
Une autre requête POST modifiée dans l'idée de duper l'API
7
POST
/api/v1/transferFunds
Une autre requête POST modifiée dans le but de tromper l'API
Si le client savait à l'avance que le point de terminaison du transfert de fonds était essentiel à protéger et qu'il n'intervenait qu'une seule fois au cours d'une séquence, il pourrait établir une règle visant à s'assurer que le point de terminaison ne soit jamais appelé deux fois de suite et qu'une requête GET /balance précède toujours une requête GET /balance. Or, sans savoir au préalable quelles séquences de point de terminaison sont essentielles à protéger, comment le client pourrait-il avoir connaissance des règles à définir ? Une faible limitation de débit est trop risquée, car un utilisateur d'API pourrait légitimement demander l'exécution de quelques requêtes de transfert de fonds sur une courte période de temps. En réalité, peu d'outils existent pour prévenir ce type d'abus et la plupart des clients n'ont d'autre choix que de s'en remettre à une attitude réactive pour « nettoyer » les abus avec leurs équipes chargées des applications et leurs services des fraudes une fois que ceux-ci se sont produits.
En définitive, nous pensons que le fait de proposer à nos clients la possibilité de définir des modèles de sécurité positive sur les séquences de requêtes d'API nécessite une approche sur trois fronts :
L'analyse des séquences : déterminer les séquences de requêtes d'API qui se sont produites, tout en résumant les données sous une forme plus compréhensible.
La détection de l'abus des séquences : identifier quelles séquences de requêtes d'API sont probablement inoffensives ou d'origine malveillante.
L'atténuation des séquences : identifier les règles pertinentes portant sur les séquences de requêtes d'API afin de décider quel trafic autoriser ou bloquer.
Défis de la création de séquences
L'analyse des séquences présente certaines difficultés techniques, car les sessions peuvent être de longue durée et peuvent se composer de nombreuses requêtes. Par conséquent, il ne suffit pas de définir des séquences par leur identificateur de session uniquement. À la place, nous avons dû développer une solution capable d'identifier automatiquement plusieurs séquences se produisant au cours d'une session donnée. De même, comme les séquences importantes ne se caractérisent pas nécessairement par le volume seul et que l'ensemble des séquences possibles est étendu, il fut nécessaire de développer une solution capable d'identifier les séquences importantes, plutôt que de simplement faire ressortir les séquences fréquentes.
Afin d'aider à illustrer ces défis pour l'exemple d'api.cloudflare.com, nous pouvons grouper les requêtes d'API par session et représenter graphiquement le nombre de séquences distinctes par rapport à la longueur des séquences :
Le graphique se base sur une période d'une heure comprenant approximativement 88 000 sessions et 260 millions de requêtes d'API, pour 301 points de terminaison d'API distincts. Nous traitons les données en appliquant une fenêtre coulissante de longueur fixe à chaque session, puis en comptant le nombre total de séquences différentes de longueur fixe (les « n-grammes ») que nous observons suite à l'application de la fenêtre. Le graphique donne les résultats pour une taille de fenêtre (la « longueur de n-gramme ») variant entre une et dix requêtes. Le nombre de séquences distinctes s'étend entre 301 (pour une taille de fenêtre d'une requête) et environ 780 000 (pour une taille de fenêtre de 10 requêtes). En fonction du graphique, nous remarquons un vaste nombre de séquences possibles, qui s'accroît avec la longueur de la séquence. Ainsi, si nous augmentons la taille de la fenêtre coulissante, nous constatons un accroissement du nombre de séquences différentes dans l'exemple. Cette tendance lisse peut s'expliquer par le fait que nous appliquons une fenêtre coulissante (les sessions peuvent elles-mêmes contenir plusieurs séquences) en association avec un grand nombre de sessions longues, par rapport à la longueur de la séquence.
Compte tenu du grand nombre de séquences possibles, essayer de trouver les séquences abusives revient à « chercher une aiguille dans une meule de foin ».
Présentation du service Sequence Analytics
Vous trouverez ci-dessous une capture d'écran du tableau de bord de la solution API Gateway mettant en valeur le service Sequence Analytics :
Décomposons la nouvelle fonctionnalité observée sur la capture d'écran.
La solution API Gateway détermine de manière intelligente les séquences de requêtes effectuées par vos utilisateurs d'API à l'aide des méthodes décrites plus haut dans cet article. Elle évalue ensuite les séquences selon un indicateur que nous appelons le score de corrélation (Correlation Score). Le service Sequence Analytics affiche les 20 premières séquences selon les scores de corrélation les plus élevés. Nous nommons ces dernières vos séquences les plus importantes. Les séquences de haute importance contiennent des requêtes d'API susceptibles de se produire ensemble, dans l'ordre.
Vous devriez inspecter chacune de vos séquences afin de comprendre leurs scores de corrélation. Les séquences présentant un score de corrélation peuvent se composer de points de terminaison rarement utilisés (un comportement utilisateur potentiellement anormal), ainsi que de points de terminaison couramment utilisés (un comportement utilisateur probablement anodin). Comme les points de terminaison trouvés dans ces séquences interviennent fréquemment ensemble, ils représentent le véritable schéma d'utilisation de votre API. Vous devriez appliquer toutes les protections possibles de la solution API Gateway à ces points de terminaison (suggestions de limitation de débit, validation de schéma, validation JWT and mTLS) avant de vérifier l'ordre spécifique de ces points de terminaison avec votre équipe de développement.
Nous savons que les clients souhaitent définir explicitement le comportement admissible sur leurs API au-delà des protections actives proposées par la solution API Gateway à l'heure actuelle. Nous lancerons bientôt des règles de préséance des séquences, ainsi que la possibilité de bloquer les requêtes en fonction de ces règles. Les nouvelles règles de préséance des séquences permettront aux clients de spécifier l'ordre exact des requêtes d'API admissibles, afin de proposer un autre moyen d'établir un modèle de sécurité positive, de manière à protéger votre API contre les menaces inconnues.
Premiers pas
Tous les clients de la solution API Gateway ont désormais accès au service Sequence Analytics. Rendez-vous dans une zone de votre tableau de bord Cloudflare, puis cliquez sur l'onglet Sécurité > l'onglet API Gateway > l'onglet Séquences. Vous découvrirez alors les séquences les plus importantes que vos utilisateurs d'API demandent.
Les clients Enterprise qui n'ont pas acheté la solution API Gateway peuvent commencer en activant l'essai de la solution API Gateway dans le tableau de bord Cloudflare Dashboard ou en contactant le responsable de leur compte.
Et maintenant ?
La détection basée sur les séquences constitue une fonctionnalité puissante et unique, capable d'ouvrir de nombreuses nouvelles opportunités d'identifier et de bloquer les attaques. En parallèle de nos efforts visant à affiner les méthodes d'identification de ces séquences et à les déployer sur notre réseau mondial, nous lancerons des fonctionnalités de correspondance de séquences personnalisées et d'atténuation en temps réel à un moment ultérieur. Nous nous assurerons également que vous disposiez d'informations exploitables à proposer à votre équipe quant à l'identité des utilisateurs d'API qui ont tenté de demander des séquences ne correspondant pas à votre politique.