API : la surface d'attaque qui nous connecte tous - État des lieux d'Internet Volume 7, numéro 4
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Volume 7, numéro 4
[État des lieux d'Internet]
API : la surface
d'attaque qui nous
connecte tous
Table des matières 3 Édito 4 Exposé d'invité — Sécurité des API : le passé se répète 6 Introduction 7 Sécurité des API 13 Dans les règles de l'art avec Akamai 18 Conclusion 18 Annexe A — Meilleures pratiques : sécurité des API 19 Annexe B — Méthodologies 21 Sources
Édito Bienvenue dans le rapport État des lieux d'Internet / Sécurité (SOTI) d'Akamai, volume 7, numéro 4. Que vous lisiez ce rapport depuis le début ou que vous soyez un nouveau lecteur, nous vous souhaitons la bienvenue et espérons que nos recherches vous fourniront des renseignements que vous ne trouverez nulle part ailleurs. Saviez-vous que la première instance d'une interface de programmation d'application (API) a été créée par Salesforce.com le 7 février 2000, selon le blog API Evangelist ? Ce qui devait à l'origine être une méthode de communication système à système relativement simple a évolué vers l'un des plus grands moteurs du trafic Internet. Nous avons contacté Chris Eng, Chief Research Officer chez Veracode, pour lui demander de nous parler de la croissance des API et des vulnérabilités auxquelles elles exposent les entreprises. Chris a commencé à travailler dans la sécurité à l'époque de l'écriture de la première API et, en raison du rôle de Veracode dans l'espace de la sécurité des applications, il a une connaissance approfondie du sujet. Sans surprise, Chris voit des parallèles significatifs entre les premiers jours de développement des logiciels et l'état actuel du trafic des API. Nous pensons que les attaques contre les API ne sont pas suffisamment détectées, et ne sont pas assez signalées lorsqu'elles sont détectées, ce qui en fait l'une des plus grandes menaces auxquelles les organisations sont confrontées. Les attaques DDoS et les ransomware sont deux problèmes majeurs, et ils font tous les deux la une de l'actualité aujourd'hui en raison de leur impact immédiat et visible. Les attaques sur les API ne reçoivent pas le même niveau d'attention, en grande partie parce que les criminels n'utilisent pas les API d'une manière aussi spectaculaire qu'une attaque ransomware bien exécutée. Notre volonté de faire évoluer le rapport SOTI a toujours été l'un de nos principaux atouts. Nous voulons continuer cet effort de mise en avant de nouvelles recherches et d'idées intéressantes qui n'ont jamais été vues auparavant. Nous prévoyons d'utiliser des sources de données provenant d'un large spectre, dont les renseignements recueillis par des partenaires comme Veracode. Nous avons hâte d'en apprendre davantage sur ce qui se passe réellement dans le monde méconnu des API et de partager ces découvertes avec vous. Martin McKeay Editorial Director API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 3
EXPOSÉ D'INVITÉ
Sécurité des API : le passé se répète
Chris Eng
Chief Research Officer, Veracode
L'Internet en lui-même est robuste et doué de plus robustes, mais avec les API, nous sommes
remarquables capacités d'autoréparation en de retour à la case départ. Par exemple, Lebin
cas de perturbations aléatoires, mais plus on Cheng de CloudVector a recueilli une liste
se rapproche de la couche applicative et en d'incidents liés aux API en 2020. Bien sûr la
particulier de la couche humaine, plus on en liste n'est pas exhaustive, mais elle illustre
vient à se demander comment on a bien pu le exactement les schémas répétés qu'on a pu
faire fonctionner à ses débuts. observer aux débuts du développement et des
tests d'applications.
Les cyberattaques de grande envergure sont
devenues plus courantes et plus étendues, en Les API sont souvent masquées dans les
particulier les ransomware. Cela ne devrait pas applications pour mobile, ce qui conduit à croire
vous déranger, à moins bien sûr que vous ne qu'elles sont à l'abri de toute manipulation.
dépendiez de ressources comme l'essence, Les développeurs partent du principe que les
le bœuf, les compagnies aériennes ou votre utilisateurs n'interagiront avec les API que via
sauvegarde de données. l'interface utilisateur mobile.
Ce rapport met l'accent sur la sécurité des API, Comparez les 10 principaux risques et les
et si vous avez déjà un tant soit peu observé 10 principaux risques pour la sécurité des API,
des API, vous savez déjà que la sécurité est une deux listes établies par l'OWASP. La seconde vise
considération qui vient trop souvent après coup. à pointer du doigt les « vulnérabilités et les risques
de sécurité uniques » des API, mais en y regardant
La première règle lors de l'écriture de logiciels de plus près, vous verrez les mêmes vulnérabilités
sécurisés est de ne pas faire d'hypothèses pour le Web, dans un ordre légèrement différent,
sur la façon dont les personnes interagiront décrites avec des mots légèrement différents. Pour
avec le produit fini. Lorsque j'ai commencé ajouter de l'huile sur le feu, les appels d'API sont
dans ce secteur il y a plus de vingt ans, en tant plus faciles et plus rapides à automatiser (de par
que testeur d'intrusion, presque tous les sites leur conception !) — une épée à double tranchant
Web étaient facilement piratables en raison qui profite aussi bien aux développeurs qu'aux
de mauvaises hypothèses : « on ne peut pas hackers.
changer la valeur d'un menu déroulant », « la
validation côté client fonctionne bien » et mon Nous répétons les mêmes erreurs avec les API
préféré, « personne ne ferait jamais ça ». Les que celles que nous avons faites il y a 20 ans
développeurs Web étaient déjà tellement avec la sécurité Web.
éloignés de la technologie sous-jacente que
la plupart d'entre eux ne comprenaient même L'API entre la sécurité et le
pas le protocole HTTP — et c'est probablement
pareil, voire pire, aujourd'hui. développement (les personnes)
Penser aux API, qui permettent aux composants
Au fil du temps, les applications Web se sont logiciels d'interagir entre eux, conduit à penser
lentement améliorées avec l'émergence à l'interface entre les équipes de sécurité et de
d'outils de test plus sophistiqués et de SDLC développement.
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 4
La sécurité et le développement n'ont jamais les ont jamais utilisées. Et elles ont tendance à
vraiment parlé la même langue, en partie penser que tout est une faille de sécurité béante.
parce que ces personnes ont des expériences, Cela devient improductif, car si tout est une
un vocabulaire et des priorités très différents. priorité, plus rien ne l'est.
Cependant, cette relation tendue devient de
plus en plus critique, en particulier en raison D'un autre côté, les breakers purs ont tendance
de l'inévitable pression à fournir plus de à ne pas comprendre comment fonctionnent les
fonctionnalités, publier plus rapidement et processus de développement. Ils simplifient de
à tout faire sous l'égide du « DevOps », pour manière excessive le coût et la complexité associés
toujours être à la pointe des dernières lubies aux modifications de code, et ils ne parlent souvent
technologiques. Que doit-on changer pour pas le langage du développeur. Ils n'ont peut-être
obtenir un meilleur alignement ? jamais eu à créer ou à expédier un produit et sont
incapables de saisir la complexité des compromis
Prenons un peu de recul. D'après mon commerciaux. Et parfois ils n'en ont aucune
expérience, les hackers sont les meilleurs envie, car s'introduire dans des programmes est
défenseurs. Je ne suis pas en train de dire beaucoup plus amusant.
qu'il faut recruter votre personnel de sécurité
de l'information parmi les hackers de PLA Voilà la situation aujourd'hui. Très peu de
Unit 61398 ou Lazarus Group. Ma définition professionnels de la sécurité arrivent à passer
d'un hacker est celle d'une personne qui a d'un monde à l'autre de manière efficace. Ce
une mentalité et une expertise axées sur les sont les employés idéaux : ils correspondent
infractions, comme les « breakers ». parfaitement à la description du poste mais sont
très difficiles à trouver.
Les breakers voient plus facilement les
possibilités d'attaque. Souvent, un breaker Et maintenant ?
signale une vulnérabilité, et elle sera corrigée
juste assez pour contrecarrer l'exploitation de Dans les sphères de la gestion des produits, vous
la démonstration, mais ce sera tout. Changez un entendrez parfois parler du « délai de rentabilité »,
caractère minuscule en majuscule, ou essayez la qui se rapporte au temps qu'il faut à un nouveau
même attaque sur une autre partie du site Web, client ou prospect pour tirer profit de ce que vous
et tout est à recommencer. Que s'est-il donc lui avez vendu. Naturellement, l'objectif est de le
passé ? Le défenseur n'a pas corrigé le problème rendre « le plus rapide possible ».
jusqu'au bout. Pourquoi ? Parce qu'il ne sait
pas vraiment pourquoi l'attaque fonctionne et Nous devons réduire le délai nécessaire aux
comment le hacker pense. Et cela ne sert à rien nouveaux professionnels de la sécurité pour être
de lui dire « pense comme un hacker » s'il ne l'a réellement opérationnels.
jamais fait avant. Cela revient à dire à un coiffeur
de « penser comme un plombier » en s'attendant En faisant référence à l'ampleur et à l'impact
à ce que, comme par magie, il ait le savoir-faire récents des violations, Jeremiah Grossman a
requis pour déplacer une conduite d'égout. déclaré que ce n'est pas tant que les techniques
offensives se soient améliorées, mais plutôt que
Les personnes qui n'ont jamais été breakers ont les adversaires se sont montrés plus capables
également tendance à mal caractériser le risque, que le secteur de la sécurité de l'information de
un peu comme dans le film Chicken Little. Pour recruter et de former des personnes de niveau
elles, les exploitations de vulnérabilités relèvent débutant.
parfois de la magie noire, parce qu'elles ne
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 5Le manque de compétences en cybersécurité L'autre stratégie que nous pouvons adopter
dont nous entendons tant parler est en grande consiste à recruter des développeurs dans la
partie une réticence (ou pire, une incapacité sécurité. Il faut trouver l'occasion de démontrer
systémique) à former les gens. Et si nous faisions certaines exploitations de failles et chercher les
davantage d'efforts en vue d'une formation sur le développeurs qui auront une ampoule lumineuse
terrain ? Par exemple, enseigner simultanément les au-dessus de leur tête. Il faut exploiter la curiosité
compétences en matière d'attaque et de défense et s'en servir. Imaginez une équipe de sécurité
en exploitant telle vulnérabilité d'injection SQL, composée de breakers chevronnés travaillant aux
puis en écrivant le code pour la corriger. Puis, côtés d'anciens développeurs. Vous bénéficiez
trouver comment contourner son propre correctif. d'une expérience approfondie des deux côtés, et
Essayez maintenant de répéter l'exercice sur une surtout, vous commencez à ne plus travailler de
application d'entreprise vieille de 10 ans qui doit manière compartimentée, mais en collaboration.
réussir tous les tests d'unité et d'intégration avant la
sortie du correctif.
Clause de non-responsabilité : les opinions exprimées dans cet essai sont celles de l'auteur et ne
reflètent pas les opinions d'Akamai.
Introduction d'attaques Web, suivie par l'inclusion de fichiers
locaux (LFI) avec 3,3 milliards et le cross-site
scripting (XSS) avec 1 019 milliards.
Dans cette édition de l'État des lieux d'Internet /
Le credential stuffing a été la source d'un flux
Sécurité, nous allons parler de la sécurité des
constant d'attaques jusqu'à présent cette année,
interfaces de programmation d'applications (API). Il
avec des creux et des pics au cours des deux
s'agit d'un sujet important — Gartner a prédit que
premiers trimestres. Akamai a observé deux pics
« d'ici 2022, les exploitations d'API passeront du
notables en janvier et mai 2021. Le nombre
statut de vecteur d'attaque peu fréquent à celui de
d'attaques par credential stuffing a alors dépassé le
vecteur le plus fréquent, entraînant des violations de
milliard. Par coïncidence, les deux pics ont été
données pour les applications Web d'entreprise ».1
enregistrés le deuxième jour de chaque mois ; rien
ne permet d'expliquer pourquoi c'est ce jour-là que
En plus de nos propres recherches, nous avons
les criminels ont décidé de frapper plus fort.
établi un partenariat avec Veracode pour ce
rapport, car leurs connaissances de l'espace de
Les États-Unis ont été la cible principale des
sécurité des applications ont contribué à
attaques d'applications Web pendant cette période
approfondir nos recherches sur les API et les défis
observée, avec un trafic six fois plus élevé que celui
de développement. Comme vous l'avez vu, Chris
du Royaume-Uni, qui s'est classé deuxième. Les
Eng, Chief Research Officer chez Veracode, est
États-Unis ont également été en tête de liste des
l'auteur de notre exposé d'invité.
sources d'attaques, se trouvant en première place
loin devant la Russie, avec un trafic presque quatre
En ce qui concerne l'état des attaques en ligne,
fois plus élevé que cette dernière.
nous avons passé en revue 18 mois de trafic
d'attaques entre janvier 2020 et juin 2021. En
Enfin, le trafic DDoS est resté constant en 2021 jusqu'à
juin 2021, en une seule journée, Akamai a observé
présent, avec des pics enregistrés plus tôt au premier
113,8 millions d'attaques. C'est plus de trois fois le
trimestre 2021. En janvier, Akamai a enregistré
nombre d'attaques que nous avons vu pendant la
190 événements DDoS en une seule journée, puis
même période en 2020. Avec 6,2 milliards de
183 en mars, également sur la même journée.
tentatives enregistrées, l'injection SQL (SQLi) reste
en tête de la liste des tendances en matière
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 6Sécurité des API Gartner a prédit que « d'ici 2022, les
exploitations d'API passeront du
statut de vecteur d'attaque peu
Interface avec le monde fréquent à celui de vecteur le plus
Les API sont partout. Si une application ou un fréquent, entraînant des violations
service est disponible sur Internet, vous pouvez être de données pour les applications
sûr qu'il y a une API derrière. Actuellement, les API
sont le moteur des applications pour mobile, de
Web d'entreprise ».1
l'Internet des objets (IoT), des services cloud
destinés aux clients, des applications internes, des
applications partenaires, etc.
En plus des préoccupations de sécurité posées par
les API, il faut également prendre en compte l'aspect
des performances. Du côté d'Akamai, nous
constatons régulièrement les améliorations de
performances offertes par les API, car le trafic des API
est délesté des serveurs d'origine vers les serveurs
en bordure de l'Internet du côté des réseaux de
diffusion de contenu (CDN). Cette configuration
accélère l'accès et assure la disponibilité.
Mais, un problème se développe de plus en plus.
Les organisations qui défendent leurs API à l'aide
de solutions de sécurité réseau traditionnelles
n'obtiennent, au mieux, qu'un succès modéré, voire
nul. En effet, les anciennes méthodes de défense du
réseau ne peuvent pas tout faire. De manière
générale, les mêmes risques qui existent pour les
sites Web et les applications Web s'appliquent aux
API, mais ils doivent être traités séparément.
Les API élargissent considérablement la surface
d'attaque qui préoccupe les entreprises. Cela signifie
que les équipes de sécurité et de développement
doivent travailler plus dur pour régler ces problèmes.
Selon Gartner, « d'ici 2021, 90 % des applications
Web auront une surface d'attaque plus importante
sous la forme d'API exposées au lieu de l'interface
utilisateur, contre 40 % en 2019 ».1
La bonne nouvelle, c'est que les dirigeants
d'entreprise et les équipes de sécurité adoptent
déjà des stratégies de sécurité plus fortes
concernant leurs pratiques en matière d'API.
Cependant, il reste encore beaucoup à faire et les
criminels ne se gênent pas pour tirer profit des
failles de sécurité des API.
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 7Défendre le code l'utilisateur final. La plupart des entreprises utilisent
des API d'une manière ou d'une autre, que ce soit
L'Open Web Application Security Project (OWASP)
en interne ou en externe, pour des clients ou des
est une fondation à but non lucratif qui travaille à
partenaires commerciaux, ou bien les deux. La
améliorer la sécurité des logiciels. Elle est très
fonction clé et les attentes en matière de
connue pour son Top 10 des risques, qui met en
développement et de déploiement des API sont
évidence les risques de sécurité les plus critiques
l'intégration et l'accès aux données, mais
auxquels sont confrontées les applications Web,
l'utilisation des API pour les lignes commerciales et
dont les attaques par injection, la violation
les services digitaux a connu une croissance
d'authentification, l'exposition des données
considérable ces dernières années (par exemple,
sensibles, la violation du contrôle d'accès et les
Checkr, Twilio, Scale, Segment).
erreurs de configuration.
C'est pourtant avec cette polyvalence que le bât
La dernière version du Top 10 de l'OWASP, au
blesse, car parfois le compromis entre facilité
moment de la rédaction de ce rapport, a été
d'utilisation et sécurité est difficile à équilibrer.
publiée en 2017 (A1-10:2017). L'OWASP a
également publié une liste des 10 principaux
Un bon exemple de la difficulté à trouver l'équilibre
risques pour la sécurité des API (API1-10:2019), et
entre convivialité et sécurité est la divulgation sur la
les similitudes qu'on retrouve entre les deux sont
sécurité de l'API de Twitter en février 2020. Dans
édifiantes. Au fil du temps, le secteur de la sécurité
une notification publique, Twitter a révélé qu'un
a mis au point un certain nombre de moyens
grand nombre de faux comptes exploitaient son API
d'assurer le suivi des vulnérabilités logicielles et de
et faisaient correspondre des noms d'utilisateur à
les mettre en corrélation avec des guides de
des numéros de téléphone. La fonction de l'API
bonnes pratiques comme les listes de l'OWASP —
était de faciliter la recherche d'amis par les
y compris les définitions de Common Weakness
utilisateurs, mais des acteurs malveillants ont
Enumeration (CWE), gérées par MITRE.
exploité cette fonctionnalité pour enrichir les
données. Cet incident est enregistré sous CWE-284
Compte tenu du nombre de vulnérabilités
et A2:2017/API5:2019 de l'OWASP.
divulguées publiquement et d'attaques signalées,
il est clair que les API sont confrontées aux mêmes
Un autre exemple de cas où le compromis entre
types de problèmes que ceux que les applications
disponibilité et sécurité peut être difficile à gérer a
Web doivent repousser depuis des années.
été révélé plus tôt cette année (juillet 2021) par le
chercheur Muhammad Sholikhin. Il a pu identifier
Par exemple, examinons les identifiants codés en dur.
des membres de groupes fermés sur Facebook, en
utilisant l'API du géant des réseaux sociaux.
Le 29 juillet 2020, Cisco a publié un correctif pour L'appartenance d'une personne à un groupe fermé
Data Center Network Manager (DCNM), après avoir est censée être confidentielle, Facebook a donc
déterminé que les identifiants codés en dur dans corrigé le défaut et versé une prime au chercheur
l'API REST pouvaient permettre à un attaquant pour son travail.
distant non authentifié de contourner
l'authentification et d'exécuter des commandes
GitLab, un gestionnaire populaire de référentiels
avec des privilèges d'administrateur. Cette
Git, a eu des problèmes semblables à ceux
vulnérabilité, CWE-798 (identifiants codés en dur),
rencontrés par Facebook. Il a été informé par son
peut être directement reliée aux listes API2:2019 et
programme de recherche de bugs que le chercheur
A2:2017 de l'OWASP, pour la catégorie violation
Riccardo Padovani avait découvert qu'il était
d'authentification.
possible de voir des projets de groupes privés via
l'API. Finalement, GitLab a offert une récompense
Les API sont censées être polyvalentes, afin de pour cette divulgation et corrigé le problème.
faciliter l'utilisation et l'accès pour l'entreprise et
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 8Des criminels cherchent à accéder que ces fichiers doivent être ajoutés au fichier .
gitignore afin que le contenu sensible ne soit pas
à Twilio
mis en ligne en texte brut. Les administrateurs de
Les criminels sont attentifs aux recommandations sites Web encouragent souvent le stockage de tels
de sécurité et aux meilleures pratiques suggérées, fichiers en dehors du répertoire racine principal
et cherchent à exploiter les entreprises et les (/www/ ou /public_html/) pour empêcher l'accès.
services qui suivent ces suggestions, mais qui ont Mais, cela ne se produit pas toujours, et cette erreur
commis des erreurs en apparence mineures (mais peut coûter très cher.
dont les répercussions sont coûteuses).
Les criminels cherchent activement à accéder aux
Twilio en fait partie. Twilio est un service d'API SID et aux jetons auth de Twilio, en analysant les
extrêmement performant qui permet aux sites Web pour trouver des noms de variables
développeurs d'améliorer l'expérience utilisateur d'environnement communs, comme ceux qui se
en gérant les communications par SMS, chat, vidéo terminent par .env, .dev, ou même .prod. Les « pots
et e-mail. de miel » d'Akamai ont observé des explorations
directes à la recherche de fichiers « twilio.env » au
Pour sécuriser les identifiants nécessaires au 25 août 2021 (au moment de la finalisation de ce
fonctionnement de Twilio, le service demande aux rapport). De plus, juste avant que ces explorations
développeurs de stocker l'identificateur de sécurité atteignent nos pots de miel, SANS a signalé avoir vu
(SID) et le jeton d'authentification (auth) du compte des analyses similaires pour l'accès à Twilio.
Twilio de manière à empêcher tout accès non
autorisé. La documentation de l'entreprise met Ceux qui recherchent ces failles pour exposer le SID
l'accent sur cette protection et suggère des et les jetons d'authentification peuvent alors
variables d'environnement comme moyen d'y effectuer une reconnaissance passive sur les
parvenir. Les variables sont une solution logique comptes compromis pour les vendre à des
couramment associée au développement d'API. acheteurs, comme c'est le cas dans la figure 1.
Toutefois, l'emplacement de stockage de ces
variables est important. Les comptes Twilio compromis peuvent être utilisés
pour l'envoi d'e-mails non sollicités, l'hameçonnage
Twilio dit que les SID et les jetons auth peuvent être passif, l'hameçonnage ciblé et d'autres fraudes. Il est
stockés dans des fichiers .env, mais insiste sur le fait donc important que ces comptes soient protégés.
Fig. 1 : Un acteur menaçant cherche à acheter un accès à Twilio, et est
particulièrement intéressé par les comptes où la recharge
automatique est activée
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 9Santé La moitié des API testées dans le cadre de l'étude
d'Alissa Knight permettait l'accès aux pathologies, aux
Comme nous l'avons dit précédemment, l'intégration
radios et aux résultats cliniques d'autres patients, ainsi
et l'accès aux données sont les principales attentes
qu'à des dossiers d'admission pour les patients sur le
pour le développement et le déploiement d'API par
point d'entrer à l'hôpital, ce qui était en dehors du
une organisation. Ce raisonnement est d'autant plus
niveau d'autorisation accordé.
évident dans le secteur de la santé.
Toutes les applications mHealth testées avaient des
En 2020, alors que la pandémie de COVID-19 a
API vulnérables au niveau des autorisations accordées
commencé à changer notre vie, la capacité d'utiliser
(BOLA). Cela a permis à Alissa Knight de consulter les
des applications mobiles de santé (mHealth) — pour
informations à caractère personnel (PII) et les
gérer les ordonnances, les dossiers médicaux et
informations médicales protégées (PHI) des personnes
même les rendez-vous chez le médecin — est devenue
qui n'étaient pas affectées au compte du praticien
cruciale. En outre, les gens ont continué à utiliser des
testé. En outre, près de 80 % des applications testées
dispositifs de suivi de santé comme moyen de gérer
contenaient des clés API codées en dur (dont certaines
leur régime alimentaire et leur activité physique.
n'expirent jamais), des jetons, des clés privées et
même des noms d'utilisateur et des mots de passe
En février 2021, Alissa Knight, partenaire de Knight
codés en dur pendant leur conception.
Ink, a publié un rapport sponsorisé par Approov (un
fournisseur de sécurité des API) sur l'application
« Les principes élémentaires de cybersécurité, comme
mHealth et la sécurité des API. Les résultats de cette
le fait de ne pas coder en dur les noms d'utilisateur et
enquête réalisée pendant six mois ont été étonnants.
les mots de passe dans le code source et d'autoriser
toutes les demandes, est un problème endémique
dans le domaine mHealth », conclut le rapport d'Alissa
Knight.
« Les entreprises mHealth doivent mettre en œuvre
une approche plus fiable de la sécurité de leurs
applications et des API, en veillant à ce qu'une
personne authentifiée ne soit pas autorisée à accéder
à toutes les données. »
En bref, les applications mHealth testées par Alissa
Knight ont sérieusement besoin d'un check-up. Grâce
à la coopération entre Alissa Knight et les entreprises
qui gèrent les applications, c'est exactement ce qui
s'est passé.
À condition de ne pas divulguer les noms des
entreprises, Alissa Knight a pu tester librement
Spring Boot
30 applications mHealth différentes. Certaines
organisations impliquées dans l'étude d'Alissa Knight Java Spring Framework permet aux entreprises de
comptaient plus de 1 000 API gérant leurs développer des applications d'entreprise qui
applications. L'un des défis de la sécurité des API est s'exécutent sur la machine virtuelle Java (JVM). Java
d'identifier et de suivre le déploiement des API. Plus Spring Boot (Spring Boot) facilite et accélère le
cette base de déploiement est importante, plus il développement des applications et des services
devient difficile de la défendre. avec Spring Framework. De par leur nature même,
les applications Spring Boot ont une API ou
interagissent avec une API.
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 10Pour ce rapport, Veracode a partagé des informations La majorité des applications Spring Boot testées (86 %)
avec Akamai concernant la sécurité de étaient vulnérables à l'injection (CWE 117) de CRLF
5 000 applications Spring Boot au fil du temps. Les (Carriage Return Line Feed) dans les journaux. Il existe
résultats ont été obtenus à partir de tests de sécurité de nombreux types de vulnérabilités CRLF, mais dans
d'applications statiques et dynamiques, ainsi que le cas présent, il s'agit de celles pour lesquelles le
d'analyses manuelles. Dans l'ensemble, 100 % des logiciel en question ne neutralise pas, ou neutralise de
applications testées présentaient au moins une manière incorrecte, toute donnée écrite dans les
vulnérabilité. Bien que toutes les vulnérabilités ne journaux. Dans de tels cas, un attaquant pourrait
soient pas égales, le fait est que l'écriture d'un code falsifier les données des journaux ou injecter du
sans vulnérabilité n'est pas aussi facile qu'il n'y paraît. Il contenu malveillant dans les journaux eux-mêmes. Les
faut beaucoup de temps et de ressources, ainsi que le vulnérabilités CRLF peuvent être exploitées pour
soutien de la direction. mener d'autres attaques, notamment le XSS. Dans le
même ordre d'idées, 42 % des applications Spring
Boot incluses dans cet ensemble de données étaient
Mappage des CWE à l'OWASP vulnérables au XSS de base (CWE 80). Pour clarifier
cependant, lors des tests, Veracode a également
signalé des vulnérabilités XSS dans les catégories
Si vous souhaitez faire correspondre les CWE au Top 10 de CWE 79, 83 ou 86, selon la situation.
l'OWASP, un graphique de correspondance est disponible
sur le site Web du CWE. Il y a également eu divers problèmes liés au code,
notamment 68 % des applications testées qui ont
Les mappages suivants sont liés aux résultats Spring Boot publié des ressources de manière incorrecte avant
obtenus par Veracode : qu'elles ne soient mises à disposition pour réutilisation
(CWE 404), et 50 % qui ont utilisé des algorithmes
CWE 73 : cryptographiques erronés ou risqués (CWE 327).
A5:2017 via l'OWASP
Les mots de passe codés en dur étaient également
un problème dans 47 % des applications Spring
CWE 80 : Boot testées (CWE 259), tout comme la gestion des
A7:2017 via l'OWASP messages d'erreur, où 44 % des applications
incluaient des informations sensibles dans les
CWE 89 : messages d'erreur (CWE 209). Certaines des
applications Spring Boot (41 %) permettaient à
API8:2019 et A1:2017 via l'OWASP
l'utilisateur de contrôler ou d'influencer les chemins
utilisés dans les opérations du système de fichiers
CWE 117 : (CWE 73), offrant ainsi un niveau de contrôle sur
API8:2019 et A1:2017 via l'OWASP l'application qui n'était pas nécessairement prévu.
Enfin, 31 % des applications testées étaient
CWE 209 : vulnérables aux failles d'entités externes XML (XXE).
Les failles XXE peuvent être utilisées pour extraire
API7:2019 / A6:2017 via l'OWASP
des données, exécuter des requêtes à distance
depuis un autre serveur ou déclencher des attaques
CWE 259 : par déni de service.
API2:2019 et A2:2017 via l'OWASP
En dehors des 10 principaux problèmes identifiés
CWE 327 : dans les applications Spring Boot, 21 % étaient
vulnérables au CWE 89, ou SQLi (Veracode signale
A3:2017 via l'OWASP
également SQLi sous CWE 564 et 943). Ce même
pourcentage contenait également des failles
relevant de CWE 601, qui traite des vulnérabilités
de redirection ouvertes.
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 11Pourquoi les vulnérabilités des condition que la vulnérabilité ne soit pas critique et
n'expose pas l'entreprise ou ses clients/utilisateurs.
applications et des API existent-elles ?
Compte tenu des données relatives à mHealth et à Les vulnérabilités à faible risque, telles que celles qui
Spring Boot, ainsi que des autres exemples mentionnés nécessitent une série complexe d'étapes, un certain
précédemment, il est compréhensible de se demander niveau d'accès ou un ensemble spécifique de
comment les API peuvent avoir les mêmes problèmes circonstances pour être exploitées, peuvent être
que les applications Web avaient dans le passé. Il reportées à plus tard afin que le produit puisse
s'avère que certaines de ces applications ont été respecter le calendrier de lancement. Il s'agit d'une
sciemment laissées vulnérables. L'année dernière, décision risquée que les entreprises du monde
l'Enterprise Strategy Group (ESG) a mené une enquête entier doivent prendre quotidiennement.
pour le compte de Veracode, qui a révélé que les
organisations diffusent sciemment du code vulnérable. Pour autant, donner la priorité au lancement pour
appliquer des correctifs plus tard ne signifie pas que
Plus précisément, 48 % des organisations ayant la sécurité est complètement ignorée. Elle est
participé à l'enquête ont admis qu'elles diffusaient simplement découpée de manière à éviter qu'elle
régulièrement du code vulnérable. Parmi ce groupe, n'interfère avec l'activité ou l'expérience utilisateur.
54 % ont déclaré que le code vulnérable est diffusé C'est pourquoi il est important que la sécurité fasse
afin de « respecter une échéance critique » avec un partie du cycle de développement.
plan pour remédier aux failles connues dans une
version ultérieure. La décision de déployer le code Collectivement, une majorité des personnes
est souvent prise par une équipe (responsable du interrogées dans le cadre de l'enquête d'ESG (78 %)
développement/analyste de sécurité — 28 %), un ont déclaré que les analystes de sécurité étaient
responsable du développement individuel (24 %), directement en contact avec leurs développeurs. Ce
un analyste de sécurité (21 %) ou des développeurs contact s'effectue en travaillant avec les
individuels qui évaluent la priorité de chaque développeurs pour examiner les fonctionnalités et le
problème découvert (15 %). code (31 %), en modélisant les menaces (28 %) ou
en participant à des réunions de développement
Les autres raisons invoquées pour justifier la quotidiennes (19 %).
diffusion d'un code vulnérable sont le sentiment que
les vulnérabilités présentent un risque faible (49 %) Un autre aspect des problèmes de sécurité
et le fait que les vulnérabilités ont été découvertes rencontrés dans les API et le développement
trop tard dans le cycle de développement pour être d'applications est la dépendance à l'égard du code
résolues avant la date butoir (45 %). open-source. Le rapport d'ESG indique que si les
bases de code actuelles dépendent fortement du
Chacune des raisons énumérées est un exemple code open-source, moins de la moitié des
classique de compromis en matière de sécurité. Le personnes interrogées (48 %) ont déclaré utiliser des
risque d'exploitation a été accepté pour répondre outils pour surveiller le bon fonctionnement de ces
aux besoins de l'entreprise. Ce n'est peut-être pas projets open-source.
très agréable à entendre, mais c'est la réalité.
Enfin, les développeurs eux-mêmes, qui sont amenés
La sécurité est déjà très compliquée, mais la sécurité à produire du code dans les délais impartis, quitte à
du développement est un ensemble complexe de apporter des correctifs après coup, manquent de
décisions qui privilégient généralement l'aspect savoir-faire. ESG a indiqué que 29 % des personnes
commercial de l'entreprise avant tout. Si une interrogées ont déclaré que les développeurs ne
entreprise doit commercialiser un produit et que l'on disposent pas des connaissances nécessaires pour
découvre qu'une bibliothèque de code utilisée lors atténuer les failles identifiées dans leur code. En fait,
du développement est vulnérable juste au moment 53 % des personnes interrogées ont déclaré que la
où le produit doit être lancé, de nombreux chefs formation n'est effectuée que lorsqu'un nouveau
d'entreprise peuvent raisonnablement demander à développeur rejoint l'équipe, dans le cadre d'un
ce que le produit soit lancé maintenant et à ce qu'un programme de formation annuel ou lorsque leurs
correctif soit mis en place dès que possible, à développeurs sont censés se former eux-mêmes.
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 12Dans les règles de l'art 3,3 milliards d'attaques et enfin XSS, avec plus d'un
milliard d'attaques.
avec Akamai
Étant donné que la majorité du trafic en ligne de nos
jours est basé sur des API, les attaques Web
Comme nous l'avons mentionné, les statistiques sur observées par Akamai ciblent presque à coup sûr
les attaques du présent rapport couvrent 18 mois, les entreprises dotées d'applications et de services
de janvier 2020 à juin 2021. orientés vers le public.
Attaques Web En fait, lorsqu'Akamai a examiné les données
Akamai a observé 113,8 millions d'attaques en une partagées par Veracode, bon nombre des
seule journée en juin 2021, soit plus de trois fois le applications Spring Boot testées étaient vulnérables
nombre d'attaques observé en juin 2020 (figure 2). aux SQLi et XSS. Les attaques visant les applications
Web et les API sont très similaires et, comme l'a
SQLi se distingue, à la figure 3, comme le profil souligné notre invité, les problèmes d'autrefois
d'attaque numéro un au cours des 18 derniers mois, commencent à réapparaître dans les cycles de
avec 6,2 milliards de tentatives enregistrées. développement actuels.
Viennent ensuite, assez loin derrière, LFI, avec
Attaques quotidiennes contre les applications Web
Du 1er janvier 2020 au 30 juin 2021
23 juin 2021
120 M
113 875 654
11 mars 2021
Attaques (en millions)
80 M
71 670 235
28 sept. 2020
53 635 511
40 M
0M
1er janv. 1er févr. 1er mars 1er avr. 1er mai 1er juin 1er juil. 1er août 1er sept. 1er oct. 1er nov. 1er déc. 1er janv. 1er févr. 1er mars 1er avr. 1er mai 1er juin 1er juil.
2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2021 2021 2021 2021 2021 2021 2021
Attaques quotidiennes Moyenne de 7 jours
Fig. 2 : Les attaques Web ont connu un pic en juin 2021, avec 113,8 millions d'attaques en une seule
journée
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 13Les principaux vecteurs d'attaques Web
Du 1er janvier 2020 au 30 juin 2021
8 md
55,88 %
6 md
Attaques (milliards)
4 md
29,84 %
2 md
9,17 %
2,14 % 1,08 % 1,89 %
0 md
SQLi LFI XSS PHPi RFI Autres
Vecteur d'attaque
Fig. 3 : SQLi reste le principal vecteur d'attaque Web, car les criminels cherchent à exploiter les
applications et les API pour accéder à des informations sensibles ou protégées
Vol d'identifiants Certains de ces services sont des arnaques, mais
leurs opérations ne durent pas longtemps, car les
Au cours des 18 derniers mois, les attaques de marchés ont tendance à s'autoréguler et à évincer
credential stuffing sont restées stables, avec des les escrocs. Le vendeur mentionné à la figure 4
creux et des pics au cours des deux premiers vendait un accès à plus de 200 Go d'identifiants au
trimestres, suivis de deux attaques notables en moment de l'offre initiale. Le service offre aux
janvier et mai 2021. À ces dates, le trafic d'attaques acheteurs un mélange de combinaisons de base ou
de credential stuffing a dépassé le milliard plus ciblées, y compris des enregistrements
d'attaques pour la journée (figure 5). user:pass axés sur le commerce de détail, les jeux,
les marchés de cryptomonnaies, les pays, etc.
La cause principale de ces pics d'attaques est
inconnue, mais il est possible qu'ils soient en lien avec De plus, cette personne met à jour sa collection
un certain nombre de services liés aux identifiants assez régulièrement. Par exemple, selon ses
apparus sur plusieurs marchés en 2020 et qui publications, plus de 430 millions de combinaisons
continuent de fonctionner à ce jour. L'un de ces auraient été ajoutées entre février et avril, et
services, qui a commencé à offrir un accès en février 144 millions en mai 2021.
2020, promet de fournir des mises à jour constantes et
des identifiants déhachés utilisables dans un format
« user:pass », ce qui est exactement ce que les
criminels recherchent lorsqu'ils achètent ou échangent
des listes de combinaisons d'identifiants.
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 14Fig. 4 : Un service sur un forum populaire offre un flux régulier d'identifiants qui peuvent être utilisés
dans les attaques de credential stuffing
Tentatives quotidiennes de vols d'identifiants
Du 1er janvier 2020 au 30 juin 2021
1,25 md
2 mai 2021
2 jan. 2021
Tentatives de connexions malveillantes (en milliards)
1 039 724 398
1 016 035 177
1 md
0,75 md
0,50 md
0,25 md
0 md
1er janv. 1er févr. 1er mars 1er avr. 1er mai 1er juin 1er juil. 1er août 1er sept. 1er oct. 1er nov. 1er déc. 1er janv. 1er févr. 1er mars 1er avr. 1er mai 1er juin 1er juil.
2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2021 2021 2021 2021 2021 2021 2021
Connexions totales Moyenne de 7 jours
Fig. 5 : Les attaques de credential stuffing sont restées stables au cours des 18 derniers mois, mais deux
jours au premier et au deuxième trimestre 2021 ont atteint des pics de plus d'un milliard d'attaques
quotidiennes
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 15Il pourrait s'agir d'une simple coïncidence, mais les six fois plus élevé que celui du Royaume-Uni, qui se
deux pics de notre ensemble de données ont été classe deuxième (figure 6). L'Inde, l'Autriche et le
enregistrés le deuxième jour de chaque mois Canada complètent la liste. Étant donné que les
(janvier et mai 2021), respectivement. Rien ne États-Unis abritent la plupart des grandes cibles sur
permet d'expliquer pourquoi les criminels ont Internet, leur place en tant que première cible ne
frappé plus fort le deuxième jour plutôt qu'un autre. nous surprend pas.
Cibles et sources Les États-Unis sont également en tête de liste des
Les États-Unis occupent la première place en tant sources d'attaques, se trouvant en première place
que cible des attaques d'applications Web au cours loin devant la Russie, avec un trafic presque quatre
de la période considérée, avec un trafic d'attaques fois plus élevé que cette dernière (figure 7).
Les principales zones cibles d'attaques d'applications Web
Du 1er janvier 2020 au 30 juin 2021
ZONE CIBLE TOTAL DES ATTAQUES CLASSEMENT MONDIAL
États-Unis 5 998 188 041 1
Royaume-Uni 1 021 638 223 2
Inde 825 061 439 3
Autriche 309 373 274 4
Canada 282 846 738 5
Fig. 6 : Les États-Unis ont une fois de plus été la cible principale des attaques Web, suivis par le
Royaume-Uni
Les principales zones à l'origine d'attaques d'applications Web
Du 1er janvier 2020 au 30 juin 2021
ZONE SOURCE TOTAL DES ATTAQUES CLASSEMENT MONDIAL
États-Unis 4 019 434 857 1
Russie 1 146 258 871 2
Inde 910 264 770 3
Pays-Bas 642 859 781 4
Allemagne 640 368 111 5
Fig. 7 : Les États-Unis ont été la principale source de trafic des attaques, avec un trafic sortant presque
quatre fois supérieur à celui de la Russie
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 16La source des attaques est une mesure intéressante DDoS
à suivre, car Akamai ne peut voir que le dernier
Le trafic DDoS est resté constant, avec des pics
maillon de la chaîne d'attaque, c'est-à-dire l'endroit
enregistrés plus tôt au premier trimestre 2021. En
où le hacker parvient enfin à établir une connexion
janvier, Akamai a enregistré 190 événements DDoS en
avec la cible. Si les États-Unis sont en tête, cela ne
une seule journée, puis 183 en mars. Nous pensons
signifie pas que l'attaque provient de ce pays. En
qu'au fur et à mesure que l'année avance, nous
réalité, les criminels relaient le trafic d'attaque à
verrons d'autres pics, car les criminels ont tendance à
partir d'un certain nombre de sources, dans le but
privilégier les DDoS aux côtés d'autres attaques.
de dissimuler leur identité et leur localisation.
Événements hebdomadaires liés à des attaques DDoS
Du 1er janvier 2020 au 30 juin 2021
200
3 août 2020 18 jan. 2021
189 190
29 mars 2021
183
175
Événements d'attaque DDoS
150
125
100
1er janv. 1er févr. 1er mars 1er avr. 1er mai 1er juin 1er juil. 1er août 1er sept. 1er oct. 1er nov. 1er déc. 1er janv. 1er févr. 1er mars 1er avr. 1er mai 1er juin 1er juil.
2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2021 2021 2021 2021 2021 2021 2021
Total hebdomadaire Moyenne de 7 jours
Fig. 8 : Les attaques DDoS sont restées constantes au cours des 18 mois observés, avec des pics au
premier trimestre 2021
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 17Conclusion également associées à ce problème. Elles doivent
elles aussi être identifiées et sécurisées, ou au
minimum enregistrées comme risques potentiels et
évaluées en conséquence.
La sécurité des applications, du côté des API ou du
côté du développement d'applications Web, est un 2. Une fois que vous savez où se trouvent toutes vos
ensemble complexe de fonctionnalités, de API, testez-les et déterminez quelles sont leurs
fonctions et d'exigences des entreprises. Trouver un vulnérabilités. Cela nécessitera des outils de test et
équilibre dans ce domaine n'est pas aussi facile une solide formation des développeurs, ainsi qu'un
qu'il n'y paraît. partenariat avec les équipes de sécurité existantes.
Comme le montrent nos données, les hackers sont Il faudra discuter de la tolérance au risque et
de toute évidence à l'affût de nouvelles techniques élaborer des plans pour corriger les vulnérabilités
et méthodes d'attaque, et les fonctionnalités API le plus tôt possible. Commencez par vérifier les clés
comptent parmi leurs principales cibles. Bien sûr les codées en dur, les appels logiques et si le trafic des
équipes s'orientent vers la mise en place de la API peut être compromis par une attaque par
sécurité dans le cycle de vie du développement, usurpation d'identité. Il est également judicieux
mais le processus est lent. Cela laisse les d'analyser les espaces de stockage et les
organisations dans l'expectative et les oblige dans référentiels à la recherche de clés qui pourraient
certains cas à lancer dans la nature un code être utilisées pour compromettre l'API ou tout ce
vulnérable connu, parce que l'utilisation de ce code qui lui est associé.
par l'entreprise est indispensable.
3. Exploitez l'infrastructure WAF existante, ainsi que
Outre certaines pratiques recommandées à toute solution de gestion des identités et de
l'annexe A, il est clair qu'une formation plus protection des données, parallèlement à tout outil
continue est nécessaire pour le développement spécialisé dans la sécurité des API, que ce soit
d'applications et la mise en œuvre d'API, et ce n'est pendant le développement ou lors du lancement. En
qu'alors que les équipes de développement outre, assurez-vous que la sécurité des API est un
pourront répondre aux exigences attendues en processus continu et non une exigence ponctuelle
matière de sécurité. en cours de développement. De nouvelles
vulnérabilités et attaques sont découvertes en
Annexe A — Meilleures permanence, et les vérifications d'une seule instance
laisseront la surface d'attaque exposée.
pratiques : sécurité des API 4. En ce qui concerne les règles d'API, essayez
d'éviter l'utilisation de règles uniques par API, en
privilégiant plutôt un ensemble de règles générales
Pour ce rapport, nous avons parlé à un certain pouvant être réutilisées. En outre, ne codez pas de
nombre d'experts, et nous avons examiné plusieurs règle directement dans les API qui doivent être
sources d'informations relatives à la sécurité des API protégées. En faisant cela, vous allez à l'encontre
et des applications, notamment Veracode, OWASP, des mécanismes de séparation des tâches, vous
MITRE et 42Crunch. ajoutez une complexité inutile, vous donnez
davantage de travail à ceux qui gèrent le code et
1. Identifiez vos API et effectuez-en un suivi comme vous privez les équipes de sécurité de toute
vous le feriez pour un inventaire. De nombreuses visibilité. Une bonne règle de base consiste à
entreprises ont été victimes d'un incident rendre le niveau d'accès par défaut à toute
impliquant une API dont elles ne connaissaient ressource nul ou refusé. Cela permet d'appliquer le
même pas l'existence. Il est donc essentiel de savoir principe du moindre privilège et de faire de
où se trouvent les API et à quoi elles servent. Les l'authentification une exigence constante.
API externes utilisées par l'entreprise sont
API : la surface d'attaque qui nous connecte tous : Volume 7, numéro 4 SOTI 18Vous pouvez aussi lire
