Pas facile de sécuriser les API…

Après des débuts hésitants, les institutions financières se mettent (enfin !) à généraliser l'exposition de leurs services sous forme d'API, bien au-delà des seules exigences réglementaires. Mais attention ! Cette ouverture n'est pas sans risques et les pratiques de sécurité doivent être soigneusement adaptées à ce nouveau mode de distribution.
Une anomalie détectée par un étudiant dans les systèmes d'accès aux scores de crédit des consommateurs américains déployés par Experian nous sert de point de départ dans cette réflexion. Au hasard de ses errances virtuelles, le jeune chercheur a repéré au sein du site web d'un client de la firme une API qui lui permettait d'interroger la note de n'importe quel individu en fournissant son nom et son adresse. Et, en dépit d'une correction apportée, le doute plane toujours sur la persistance du défaut.
En effet, l'analyse du problème révèle que, d'une part, la dite interface n'aurait jamais dû être rendue visible dans le code d'une page publique et que, d'autre part, si elle est, en principe, conçue pour être sollicitée avec un paramètre supplémentaire (la date de naissance, qui relève légèrement son niveau de confidentialité), ce dernier n'est, en réalité, pas déterminant pour son fonctionnement (il a suffi à Bill Demirkapi, notre hacker éthique, de transmettre une valeur nulle – 00/00/0000 – afin de contourner l'obstacle).
Le cas relève d'une double faute dans la mise en œuvre de l'API, entre celle d'Experian, dont les mesures de protection des informations sensibles sont manifestement insuffisantes, et celle de l'entreprise utilisatrice, qui l'a exploitée dans des conditions incompatibles avec ses spécifications. Il reflète de la sorte les enjeux supplémentaires de sécurité, plus ou moins inédits, qu'induit l'émergence du concept de banque en services (« bank as a service ») et, surtout, son adoption (potentielle) à grande échelle.
Historiquement, les établissements financiers ont l'habitude de gérer deux grands types d'interactions en ligne : publiques mais très contrôlées, essentiellement avec les clients, ou privées, notamment avec des partenaires dûment audités et certifiés. Désormais, un nouveau modèle vient se glisser entre ce deux-là, offrant la possibilité de partager des capacités « réservées » avec des acteurs tiers, dans une approche industrialisée. En l'absence de précautions particulières, cela revient à ouvrir une boîte de Pandore.
Le point critique est alors de toujours conserver en perspective les deux paliers de danger présents dans un tel dispositif. Outre les failles intrinsèques aux services proposés (qui sont une menace dans toutes les situations, y compris en interne), les API doivent également assumer l'hypothèse d'une mauvaise implémentation par l'entité qui les intègre dans ses propres applications, susceptible d'engendrer des situations considérées a priori impossibles, et prévenir les conséquences de ce genre d'irrégularité.
La difficulté réside dans la nécessité de changer d'attitude dans les relations avec les partenaires auxquels sont fournis les services bancaires : la confiance ne suffit pas à garantir la qualité. La moindre erreur technique peut avoir un impact dramatique et nul n'en est à l'abri. À défaut d'instaurer des contrôles exhaustifs et permanents, il est impératif de mettre en place des mécanismes de sécurité renforcés afin de parer à tous les scénarios d'utilisation, normaux et anormaux, qu'il faut donc au préalable anticiper.