Les fuites d'API menacent d'entacher la réputation des entreprises.
Dans la vie, en général, la communication est une excellente chose. Il n'y a pas de moyen plus rapide de parvenir à une compréhension, d'apprendre quelque chose de nouveau ou de construire une relation. Dans l'espace logiciel, les API ont une fonction de communication qui permet aux applications de communiquer entre elles, ce qui améliore les fonctionnalités et la convivialité. Cette connectivité crée souvent une expérience plus riche que les utilisateurs finaux apprécient et, de plus en plus, attendent des logiciels dans leur vie quotidienne.
Cependant, comme dans la vie réelle, il y a un gros problème lorsqu'ils parlent trop. Experian l'a récemment appris à ses dépens, lorsque l'une de ses interfaces de programmation (API), utilisée par un partenaire tiers, a potentiellement divulgué les scores de crédit de... eh bien, d'à peu près tous les citoyens américains.
Le problème a été corrigé rapidement, mais des questions subsistent quant à savoir si cette vulnérabilité a vraiment été stoppée dans son élan. Si un fournisseur a été touché, il y a de fortes chances que d'autres le soient également, et il est possible qu'il s'agisse d'un bogue systémique, affectant tous ceux qui utilisent cette API non sécurisée.
La sécurité des API est une question qui n'est pas loin de préoccuper la plupart des experts en sécurité, et c'est une chose que nous devons nous équiper des connaissances nécessaires pour la combattre.
N'importe quel geek peut contourner une mauvaise authentification de l'API.
L'une des caractéristiques de nombreuses fuites de données, violations et incidents de sécurité est qu'il faut rarement un génie pour les réaliser. Les attaques complexes, insidieuses et préjudiciables comme celle de SolarWinds nécessitent des équipes de génies cybercriminels pour être menées à bien, et elles sont l'exception plutôt que la règle.
Lorsqu'une API est construite avec une authentification faible, il est assez facile de l'exploiter. Bill Demirkapi, le chercheur en sécurité qui a découvert le bogue de l'API d'Experian, a déterminé qu'il était possible d'y accéder sans aucune authentification. En saisissant 00/00/0000 dans le champ de la date de naissance, il a pu accéder à la cote de crédit d'une personne, en utilisant uniquement des informations accessibles au public telles que le nom et l'adresse postale associée. Bien que cela n'ait pas été rapporté, il est tout à fait possible que ces enregistrements soient récupérés et contextualisés en tant que données de crédit (et donc utiles).
Des processus d'authentification propres et fonctionnels doivent être mis en place, quelle que soit la taille du cas d'utilisation ; une API bavarde qui n'est pas correctement sécurisée, et qui ouvre potentiellement l'accès à de multiples systèmes, est une responsabilité.
L'authentification brisée est le numéro deux de la liste des 10 principales vulnérabilités des API de l'OWASP. Pour en savoir plus sur la manière d'éviter ce bogue, cliquez ici et testez vos compétences sur notre plateforme une fois que vous aurez fini d'alimenter votre cerveau.
La faiblesse des contrôles de sécurité des API est un problème généralisé qui nécessite un changement de culture
Il n'est pas juste de pointer du doigt uniquement des organisations comme Experian, mais le manque de nuance et de diligence en matière de contrôle de la sécurité dont témoigne cette exposition particulière à l'API n'augure rien de bon pour les nombreuses entreprises qui utilisent des API dans le cadre de leurs systèmes informatiques et de leurs points de terminaison.
En général, nous avons encore beaucoup de travail à faire, non seulement pour trouver et corriger les vulnérabilités des API, mais aussi pour les comprendre comme faisant partie de la surface d'attaque que nous sommes censés protéger. La visibilité sur les API - et la manière dont elles ont été construites - est une préoccupation majeure, et c'est quelque chose qui devrait être exigé dans le cadre des meilleures pratiques de sécurité. Même une organisation dotée des mesures de sécurité les plus strictes peut se retrouver à la merci d'une API publiée et fonctionnant en dehors des contrôles de sécurité de l'entreprise. Il est plus important que jamais de se demander d'où vient une API, qui la maintient (est-ce un fournisseur tiers ? Quelle est sa rigueur en matière de sécurité ?) et quelles sont les informations auxquelles elle accède.
Les vulnérabilités liées aux injections restent un problème pour tous les RSSI.
La sécurité des API peut sembler être un module relativement nouveau à inclure dans un programme de sécurité, mais elle peut être exploitée par des astuces (très) anciennes que nous avons l'habitude de voir dans les logiciels web ordinaires.
Une attaque récemment divulguée contre Accellion a révélé que l'enchaînement d'attaques par injection SQL et par exécution de commandes du système d'exploitation a permis aux auteurs de la menace de manipuler les API et d'extraire un grand nombre de données sensibles, y compris des numéros de sécurité sociale. Les auteurs de l'attaque ont déterminé que les attaquants devaient avoir une connaissance approfondie du logiciel FTA d'Accellion pour réaliser le hold-up, ce qui aurait été possible grâce à une rétro-ingénierie importante.
La violation s'étant produite entre décembre 2020 et janvier 2021, les voleurs ont eu tout le temps de causer des dégâts. D'autres découvertes en février 2021 ont mis au jour une vulnérabilité XSS stockée, l'analyse médico-légale ayant révélé qu'un seul point d'extrémité de l'API dont l'entrée utilisateur n'était pas correctement assainie permettait d'injecter un argument lors de l'appel du script admin.pl.
Avec plus de 3 000 clients, dont de nombreux établissements d'enseignement prestigieux, cette violation pourrait avoir une grande portée. Malheureusement, ces exploits ont été rendus possibles par l'exploitation de vulnérabilités courantes, dont beaucoup auraient pu être corrigées au niveau du code, avant la production, par un développeur sensibilisé à la sécurité. Comme nous le constatons sans cesse, il suffit d'une petite fenêtre laissée ouverte pour créer de gros problèmes. Et une culture de la cyberdéfense dirigée par l'homme doit faire partie de la stratégie de résolution d'un problème très humain.
Vous voulez tester vos compétences en matière de sécurité des API ? Java Spring API, Kotlin Spring API, C# (.NET) Web API et bien d'autres encore ? Relevez quelques défis API sur notre site Plateforme D'apprentissage (consultez tous les langages:frameworks via le menu déroulant) :
La sécurité des API est une question qui n'est pas loin de préoccuper la plupart des experts en sécurité, et c'est une chose que nous devons nous équiper des connaissances nécessaires pour la combattre.
Directeur général, président et cofondateur
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationDirecteur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Dans la vie, en général, la communication est une excellente chose. Il n'y a pas de moyen plus rapide de parvenir à une compréhension, d'apprendre quelque chose de nouveau ou de construire une relation. Dans l'espace logiciel, les API ont une fonction de communication qui permet aux applications de communiquer entre elles, ce qui améliore les fonctionnalités et la convivialité. Cette connectivité crée souvent une expérience plus riche que les utilisateurs finaux apprécient et, de plus en plus, attendent des logiciels dans leur vie quotidienne.
Cependant, comme dans la vie réelle, il y a un gros problème lorsqu'ils parlent trop. Experian l'a récemment appris à ses dépens, lorsque l'une de ses interfaces de programmation (API), utilisée par un partenaire tiers, a potentiellement divulgué les scores de crédit de... eh bien, d'à peu près tous les citoyens américains.
Le problème a été corrigé rapidement, mais des questions subsistent quant à savoir si cette vulnérabilité a vraiment été stoppée dans son élan. Si un fournisseur a été touché, il y a de fortes chances que d'autres le soient également, et il est possible qu'il s'agisse d'un bogue systémique, affectant tous ceux qui utilisent cette API non sécurisée.
La sécurité des API est une question qui n'est pas loin de préoccuper la plupart des experts en sécurité, et c'est une chose que nous devons nous équiper des connaissances nécessaires pour la combattre.
N'importe quel geek peut contourner une mauvaise authentification de l'API.
L'une des caractéristiques de nombreuses fuites de données, violations et incidents de sécurité est qu'il faut rarement un génie pour les réaliser. Les attaques complexes, insidieuses et préjudiciables comme celle de SolarWinds nécessitent des équipes de génies cybercriminels pour être menées à bien, et elles sont l'exception plutôt que la règle.
Lorsqu'une API est construite avec une authentification faible, il est assez facile de l'exploiter. Bill Demirkapi, le chercheur en sécurité qui a découvert le bogue de l'API d'Experian, a déterminé qu'il était possible d'y accéder sans aucune authentification. En saisissant 00/00/0000 dans le champ de la date de naissance, il a pu accéder à la cote de crédit d'une personne, en utilisant uniquement des informations accessibles au public telles que le nom et l'adresse postale associée. Bien que cela n'ait pas été rapporté, il est tout à fait possible que ces enregistrements soient récupérés et contextualisés en tant que données de crédit (et donc utiles).
Des processus d'authentification propres et fonctionnels doivent être mis en place, quelle que soit la taille du cas d'utilisation ; une API bavarde qui n'est pas correctement sécurisée, et qui ouvre potentiellement l'accès à de multiples systèmes, est une responsabilité.
L'authentification brisée est le numéro deux de la liste des 10 principales vulnérabilités des API de l'OWASP. Pour en savoir plus sur la manière d'éviter ce bogue, cliquez ici et testez vos compétences sur notre plateforme une fois que vous aurez fini d'alimenter votre cerveau.
La faiblesse des contrôles de sécurité des API est un problème généralisé qui nécessite un changement de culture
Il n'est pas juste de pointer du doigt uniquement des organisations comme Experian, mais le manque de nuance et de diligence en matière de contrôle de la sécurité dont témoigne cette exposition particulière à l'API n'augure rien de bon pour les nombreuses entreprises qui utilisent des API dans le cadre de leurs systèmes informatiques et de leurs points de terminaison.
En général, nous avons encore beaucoup de travail à faire, non seulement pour trouver et corriger les vulnérabilités des API, mais aussi pour les comprendre comme faisant partie de la surface d'attaque que nous sommes censés protéger. La visibilité sur les API - et la manière dont elles ont été construites - est une préoccupation majeure, et c'est quelque chose qui devrait être exigé dans le cadre des meilleures pratiques de sécurité. Même une organisation dotée des mesures de sécurité les plus strictes peut se retrouver à la merci d'une API publiée et fonctionnant en dehors des contrôles de sécurité de l'entreprise. Il est plus important que jamais de se demander d'où vient une API, qui la maintient (est-ce un fournisseur tiers ? Quelle est sa rigueur en matière de sécurité ?) et quelles sont les informations auxquelles elle accède.
Les vulnérabilités liées aux injections restent un problème pour tous les RSSI.
La sécurité des API peut sembler être un module relativement nouveau à inclure dans un programme de sécurité, mais elle peut être exploitée par des astuces (très) anciennes que nous avons l'habitude de voir dans les logiciels web ordinaires.
Une attaque récemment divulguée contre Accellion a révélé que l'enchaînement d'attaques par injection SQL et par exécution de commandes du système d'exploitation a permis aux auteurs de la menace de manipuler les API et d'extraire un grand nombre de données sensibles, y compris des numéros de sécurité sociale. Les auteurs de l'attaque ont déterminé que les attaquants devaient avoir une connaissance approfondie du logiciel FTA d'Accellion pour réaliser le hold-up, ce qui aurait été possible grâce à une rétro-ingénierie importante.
La violation s'étant produite entre décembre 2020 et janvier 2021, les voleurs ont eu tout le temps de causer des dégâts. D'autres découvertes en février 2021 ont mis au jour une vulnérabilité XSS stockée, l'analyse médico-légale ayant révélé qu'un seul point d'extrémité de l'API dont l'entrée utilisateur n'était pas correctement assainie permettait d'injecter un argument lors de l'appel du script admin.pl.
Avec plus de 3 000 clients, dont de nombreux établissements d'enseignement prestigieux, cette violation pourrait avoir une grande portée. Malheureusement, ces exploits ont été rendus possibles par l'exploitation de vulnérabilités courantes, dont beaucoup auraient pu être corrigées au niveau du code, avant la production, par un développeur sensibilisé à la sécurité. Comme nous le constatons sans cesse, il suffit d'une petite fenêtre laissée ouverte pour créer de gros problèmes. Et une culture de la cyberdéfense dirigée par l'homme doit faire partie de la stratégie de résolution d'un problème très humain.
Vous voulez tester vos compétences en matière de sécurité des API ? Java Spring API, Kotlin Spring API, C# (.NET) Web API et bien d'autres encore ? Relevez quelques défis API sur notre site Plateforme D'apprentissage (consultez tous les langages:frameworks via le menu déroulant) :
Dans la vie, en général, la communication est une excellente chose. Il n'y a pas de moyen plus rapide de parvenir à une compréhension, d'apprendre quelque chose de nouveau ou de construire une relation. Dans l'espace logiciel, les API ont une fonction de communication qui permet aux applications de communiquer entre elles, ce qui améliore les fonctionnalités et la convivialité. Cette connectivité crée souvent une expérience plus riche que les utilisateurs finaux apprécient et, de plus en plus, attendent des logiciels dans leur vie quotidienne.
Cependant, comme dans la vie réelle, il y a un gros problème lorsqu'ils parlent trop. Experian l'a récemment appris à ses dépens, lorsque l'une de ses interfaces de programmation (API), utilisée par un partenaire tiers, a potentiellement divulgué les scores de crédit de... eh bien, d'à peu près tous les citoyens américains.
Le problème a été corrigé rapidement, mais des questions subsistent quant à savoir si cette vulnérabilité a vraiment été stoppée dans son élan. Si un fournisseur a été touché, il y a de fortes chances que d'autres le soient également, et il est possible qu'il s'agisse d'un bogue systémique, affectant tous ceux qui utilisent cette API non sécurisée.
La sécurité des API est une question qui n'est pas loin de préoccuper la plupart des experts en sécurité, et c'est une chose que nous devons nous équiper des connaissances nécessaires pour la combattre.
N'importe quel geek peut contourner une mauvaise authentification de l'API.
L'une des caractéristiques de nombreuses fuites de données, violations et incidents de sécurité est qu'il faut rarement un génie pour les réaliser. Les attaques complexes, insidieuses et préjudiciables comme celle de SolarWinds nécessitent des équipes de génies cybercriminels pour être menées à bien, et elles sont l'exception plutôt que la règle.
Lorsqu'une API est construite avec une authentification faible, il est assez facile de l'exploiter. Bill Demirkapi, le chercheur en sécurité qui a découvert le bogue de l'API d'Experian, a déterminé qu'il était possible d'y accéder sans aucune authentification. En saisissant 00/00/0000 dans le champ de la date de naissance, il a pu accéder à la cote de crédit d'une personne, en utilisant uniquement des informations accessibles au public telles que le nom et l'adresse postale associée. Bien que cela n'ait pas été rapporté, il est tout à fait possible que ces enregistrements soient récupérés et contextualisés en tant que données de crédit (et donc utiles).
Des processus d'authentification propres et fonctionnels doivent être mis en place, quelle que soit la taille du cas d'utilisation ; une API bavarde qui n'est pas correctement sécurisée, et qui ouvre potentiellement l'accès à de multiples systèmes, est une responsabilité.
L'authentification brisée est le numéro deux de la liste des 10 principales vulnérabilités des API de l'OWASP. Pour en savoir plus sur la manière d'éviter ce bogue, cliquez ici et testez vos compétences sur notre plateforme une fois que vous aurez fini d'alimenter votre cerveau.
La faiblesse des contrôles de sécurité des API est un problème généralisé qui nécessite un changement de culture
Il n'est pas juste de pointer du doigt uniquement des organisations comme Experian, mais le manque de nuance et de diligence en matière de contrôle de la sécurité dont témoigne cette exposition particulière à l'API n'augure rien de bon pour les nombreuses entreprises qui utilisent des API dans le cadre de leurs systèmes informatiques et de leurs points de terminaison.
En général, nous avons encore beaucoup de travail à faire, non seulement pour trouver et corriger les vulnérabilités des API, mais aussi pour les comprendre comme faisant partie de la surface d'attaque que nous sommes censés protéger. La visibilité sur les API - et la manière dont elles ont été construites - est une préoccupation majeure, et c'est quelque chose qui devrait être exigé dans le cadre des meilleures pratiques de sécurité. Même une organisation dotée des mesures de sécurité les plus strictes peut se retrouver à la merci d'une API publiée et fonctionnant en dehors des contrôles de sécurité de l'entreprise. Il est plus important que jamais de se demander d'où vient une API, qui la maintient (est-ce un fournisseur tiers ? Quelle est sa rigueur en matière de sécurité ?) et quelles sont les informations auxquelles elle accède.
Les vulnérabilités liées aux injections restent un problème pour tous les RSSI.
La sécurité des API peut sembler être un module relativement nouveau à inclure dans un programme de sécurité, mais elle peut être exploitée par des astuces (très) anciennes que nous avons l'habitude de voir dans les logiciels web ordinaires.
Une attaque récemment divulguée contre Accellion a révélé que l'enchaînement d'attaques par injection SQL et par exécution de commandes du système d'exploitation a permis aux auteurs de la menace de manipuler les API et d'extraire un grand nombre de données sensibles, y compris des numéros de sécurité sociale. Les auteurs de l'attaque ont déterminé que les attaquants devaient avoir une connaissance approfondie du logiciel FTA d'Accellion pour réaliser le hold-up, ce qui aurait été possible grâce à une rétro-ingénierie importante.
La violation s'étant produite entre décembre 2020 et janvier 2021, les voleurs ont eu tout le temps de causer des dégâts. D'autres découvertes en février 2021 ont mis au jour une vulnérabilité XSS stockée, l'analyse médico-légale ayant révélé qu'un seul point d'extrémité de l'API dont l'entrée utilisateur n'était pas correctement assainie permettait d'injecter un argument lors de l'appel du script admin.pl.
Avec plus de 3 000 clients, dont de nombreux établissements d'enseignement prestigieux, cette violation pourrait avoir une grande portée. Malheureusement, ces exploits ont été rendus possibles par l'exploitation de vulnérabilités courantes, dont beaucoup auraient pu être corrigées au niveau du code, avant la production, par un développeur sensibilisé à la sécurité. Comme nous le constatons sans cesse, il suffit d'une petite fenêtre laissée ouverte pour créer de gros problèmes. Et une culture de la cyberdéfense dirigée par l'homme doit faire partie de la stratégie de résolution d'un problème très humain.
Vous voulez tester vos compétences en matière de sécurité des API ? Java Spring API, Kotlin Spring API, C# (.NET) Web API et bien d'autres encore ? Relevez quelques défis API sur notre site Plateforme D'apprentissage (consultez tous les langages:frameworks via le menu déroulant) :
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstrationDirecteur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Dans la vie, en général, la communication est une excellente chose. Il n'y a pas de moyen plus rapide de parvenir à une compréhension, d'apprendre quelque chose de nouveau ou de construire une relation. Dans l'espace logiciel, les API ont une fonction de communication qui permet aux applications de communiquer entre elles, ce qui améliore les fonctionnalités et la convivialité. Cette connectivité crée souvent une expérience plus riche que les utilisateurs finaux apprécient et, de plus en plus, attendent des logiciels dans leur vie quotidienne.
Cependant, comme dans la vie réelle, il y a un gros problème lorsqu'ils parlent trop. Experian l'a récemment appris à ses dépens, lorsque l'une de ses interfaces de programmation (API), utilisée par un partenaire tiers, a potentiellement divulgué les scores de crédit de... eh bien, d'à peu près tous les citoyens américains.
Le problème a été corrigé rapidement, mais des questions subsistent quant à savoir si cette vulnérabilité a vraiment été stoppée dans son élan. Si un fournisseur a été touché, il y a de fortes chances que d'autres le soient également, et il est possible qu'il s'agisse d'un bogue systémique, affectant tous ceux qui utilisent cette API non sécurisée.
La sécurité des API est une question qui n'est pas loin de préoccuper la plupart des experts en sécurité, et c'est une chose que nous devons nous équiper des connaissances nécessaires pour la combattre.
N'importe quel geek peut contourner une mauvaise authentification de l'API.
L'une des caractéristiques de nombreuses fuites de données, violations et incidents de sécurité est qu'il faut rarement un génie pour les réaliser. Les attaques complexes, insidieuses et préjudiciables comme celle de SolarWinds nécessitent des équipes de génies cybercriminels pour être menées à bien, et elles sont l'exception plutôt que la règle.
Lorsqu'une API est construite avec une authentification faible, il est assez facile de l'exploiter. Bill Demirkapi, le chercheur en sécurité qui a découvert le bogue de l'API d'Experian, a déterminé qu'il était possible d'y accéder sans aucune authentification. En saisissant 00/00/0000 dans le champ de la date de naissance, il a pu accéder à la cote de crédit d'une personne, en utilisant uniquement des informations accessibles au public telles que le nom et l'adresse postale associée. Bien que cela n'ait pas été rapporté, il est tout à fait possible que ces enregistrements soient récupérés et contextualisés en tant que données de crédit (et donc utiles).
Des processus d'authentification propres et fonctionnels doivent être mis en place, quelle que soit la taille du cas d'utilisation ; une API bavarde qui n'est pas correctement sécurisée, et qui ouvre potentiellement l'accès à de multiples systèmes, est une responsabilité.
L'authentification brisée est le numéro deux de la liste des 10 principales vulnérabilités des API de l'OWASP. Pour en savoir plus sur la manière d'éviter ce bogue, cliquez ici et testez vos compétences sur notre plateforme une fois que vous aurez fini d'alimenter votre cerveau.
La faiblesse des contrôles de sécurité des API est un problème généralisé qui nécessite un changement de culture
Il n'est pas juste de pointer du doigt uniquement des organisations comme Experian, mais le manque de nuance et de diligence en matière de contrôle de la sécurité dont témoigne cette exposition particulière à l'API n'augure rien de bon pour les nombreuses entreprises qui utilisent des API dans le cadre de leurs systèmes informatiques et de leurs points de terminaison.
En général, nous avons encore beaucoup de travail à faire, non seulement pour trouver et corriger les vulnérabilités des API, mais aussi pour les comprendre comme faisant partie de la surface d'attaque que nous sommes censés protéger. La visibilité sur les API - et la manière dont elles ont été construites - est une préoccupation majeure, et c'est quelque chose qui devrait être exigé dans le cadre des meilleures pratiques de sécurité. Même une organisation dotée des mesures de sécurité les plus strictes peut se retrouver à la merci d'une API publiée et fonctionnant en dehors des contrôles de sécurité de l'entreprise. Il est plus important que jamais de se demander d'où vient une API, qui la maintient (est-ce un fournisseur tiers ? Quelle est sa rigueur en matière de sécurité ?) et quelles sont les informations auxquelles elle accède.
Les vulnérabilités liées aux injections restent un problème pour tous les RSSI.
La sécurité des API peut sembler être un module relativement nouveau à inclure dans un programme de sécurité, mais elle peut être exploitée par des astuces (très) anciennes que nous avons l'habitude de voir dans les logiciels web ordinaires.
Une attaque récemment divulguée contre Accellion a révélé que l'enchaînement d'attaques par injection SQL et par exécution de commandes du système d'exploitation a permis aux auteurs de la menace de manipuler les API et d'extraire un grand nombre de données sensibles, y compris des numéros de sécurité sociale. Les auteurs de l'attaque ont déterminé que les attaquants devaient avoir une connaissance approfondie du logiciel FTA d'Accellion pour réaliser le hold-up, ce qui aurait été possible grâce à une rétro-ingénierie importante.
La violation s'étant produite entre décembre 2020 et janvier 2021, les voleurs ont eu tout le temps de causer des dégâts. D'autres découvertes en février 2021 ont mis au jour une vulnérabilité XSS stockée, l'analyse médico-légale ayant révélé qu'un seul point d'extrémité de l'API dont l'entrée utilisateur n'était pas correctement assainie permettait d'injecter un argument lors de l'appel du script admin.pl.
Avec plus de 3 000 clients, dont de nombreux établissements d'enseignement prestigieux, cette violation pourrait avoir une grande portée. Malheureusement, ces exploits ont été rendus possibles par l'exploitation de vulnérabilités courantes, dont beaucoup auraient pu être corrigées au niveau du code, avant la production, par un développeur sensibilisé à la sécurité. Comme nous le constatons sans cesse, il suffit d'une petite fenêtre laissée ouverte pour créer de gros problèmes. Et une culture de la cyberdéfense dirigée par l'homme doit faire partie de la stratégie de résolution d'un problème très humain.
Vous voulez tester vos compétences en matière de sécurité des API ? Java Spring API, Kotlin Spring API, C# (.NET) Web API et bien d'autres encore ? Relevez quelques défis API sur notre site Plateforme D'apprentissage (consultez tous les langages:frameworks via le menu déroulant) :
Table des matières
Directeur général, président et cofondateur
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
La note de confiance révèle la valeur des initiatives d'amélioration de la sécurité par la conception
Nos recherches ont montré que la formation au code sécurisé fonctionne. Le Trust Score, qui utilise un algorithme s'appuyant sur plus de 20 millions de points de données d'apprentissage issus du travail de plus de 250 000 apprenants dans plus de 600 organisations, révèle son efficacité à réduire les vulnérabilités et la manière de rendre l'initiative encore plus efficace.
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.