Si je vous demandais combien coûterait la modification d'une seule ligne de code informatique dans un appareil déjà en service, quel chiffre vous viendrait à l'esprit ? Quelques centaines de dollars ? Peut-être des milliers ?

Selon Aviation Today, la mise à jour d'une ligne de code dans les avions d'une compagnie aérienne coûte un million de dollars. Pour un coût aussi important, il faudrait sans doute une raison impérieuse pour prendre les mesures nécessaires à la mise à jour des systèmes de l'avion, ce qui m'a fait réfléchir à un certain nombre de facteurs.

Ventiler les coûts

Bien que l'article ne précise pas ce qui compose le coût d'un million de dollars, je pense qu'il s'agit d'un chiffre viable. Je ne suis pas un spécialiste des mises à jour des logiciels des compagnies aériennes, mais je peux supposer certaines des mesures que la compagnie aérienne est obligée de prendre dans cette situation.

Tout d'abord, la compagnie aérienne doit découvrir une faille ou une vulnérabilité qui nécessite la mise à jour. L'exemple cité est celui d'une recherche effectuée par le ministère américain de la sécurité intérieure (DHS) sur un Boeing 757. Les résultats - un piratage à distance après seulement deux jours de travail - sont suffisamment convaincants pour qu'une compagnie aérienne en prenne note.

À partir de là, les développeurs de logiciels doivent analyser les résultats, écrire un nouveau code et le tester dans un environnement sûr pour s'assurer que le problème est résolu. C'est maintenant que vient la partie la plus délicate. La compagnie aérienne doit clouer au sol chaque avion vulnérable ou défectueux, appliquer le nouveau code, le tester pour s'assurer qu'il fonctionne avec cet avion spécifique, puis recertifier l'avion pour les vols commerciaux.

Selon airfleets.net, la flotte de Southwest Airlines compte actuellement 499 Boeing 737-700. Pensez à l'investissement en temps et en argent qu'impliquerait l'apparition d'une faille de sécurité dans ce modèle d'avion particulier.

Pas seulement un défi pour les compagnies aériennes

Il est clair que les compagnies aériennes devraient avoir tout intérêt à utiliser des principes de codage sécurisés dès le départ. Après y avoir réfléchi quelques instants, je me suis rendu compte qu'il existait de nombreuses industries et situations où un coût similaire pouvait s'appliquer. Au lieu de s'inquiéter des avions qui tombent du ciel à cause d'une vulnérabilité piratée, qu'en est-il des appareils médicaux tels que les stimulateurs cardiaques? Combien coûte le rappel et la mise à jour d'un demi-million de pièces électroniques qui sauvent des vies ?

Dans l'industrie automobile, nous continuons d'entendre parler des voitures autonomes et des problèmes de sécurité qu'elles posent. Pourtant, même nos véhicules "typiques" dépendent plus que jamais de la connectivité à l'internet, ce qui soulève directement des questions de sécurité troublantes - bien que divertissantes.

C'est un fait simple qu'il est beaucoup plus coûteux et qu'il faut plus d'efforts et de temps pour mettre à jour des appareils ou des systèmes après qu'ils ont été mis en production, ou avant qu'ils aient été produits en masse, que d'intégrer la sécurité dans votre processus de développement initial. Pourtant, nous continuons à voir chaque jour de nouvelles failles logicielles évitables et des vulnérabilités en matière de cybersécurité, ce qui souligne la nécessité pour les entreprises de chercher des moyens d'intégrer le développement de logiciels sécurisés dans leur culture de développement.

La modification d'une ligne de code sur un équipement avionique coûte un million de dollars et sa mise en œuvre prend un an. Pour Southwest Airlines, dont la flotte est basée sur le 737 de Boeing, une vulnérabilité cybernétique spécifique aux systèmes embarqués à bord des 737 les mettrait en "faillite".

‍

La plupart des discussions sur la cybersécurité portent sur la protection de l'argent, de la réputation et de l'information. Au sein des institutions financières, il s'agit souvent d'une menace pour les finances personnelles ou celles de l'entreprise. Dans le secteur des télécommunications, il s'agit plutôt d'informations sur l'identité des personnes ou de vol de propriété intellectuelle. Au niveau gouvernemental, le cyber-espionnage est un moyen relativement facile et peu coûteux d'acquérir des renseignements de grande valeur.

Cependant, les dangers des cyberattaques contre les infrastructures physiques, notamment les systèmes SCADA (Supervisory Control and Data Acquisition) et ICS (Industrial Control Systems), sont bien réels, croissants et effrayants, comme l'explique un récent article du New York Times sur une attaque contre une société pétrochimique possédant une usine en Arabie saoudite.

Dans le secteur du pétrole et du gaz, les attaques de cybersécurité peuvent provoquer des explosions. Pendant longtemps, ces usines n'étaient pas connectées à des réseaux, mais aujourd'hui, pour simplifier la gestion, elles sont toutes dangereusement connectées. La probabilité que ces systèmes soient attaqués - et qu'ils le soient avec succès - est désormais beaucoup plus élevée. Ces applications ne sont PAS conçues dans un souci de sécurité, car il n'était pas prévu qu'elles soient connectées à l'internet.

L'article du NYT décrit une attaque qui ne visait pas seulement à détruire des données ou à fermer l'usine, mais aussi à saboter les opérations de l'entreprise et à déclencher une explosion susceptible de blesser d'autres personnes. Les enquêteurs ont déclaré que la seule chose qui a empêché l'explosion était "une erreur dans le code informatique des attaquants", une erreur que les pirates ont, selon eux, "probablement corrigée à ce jour". Les enquêteurs pensent que ce n'est qu'une "question de temps" avant qu'ils ne déploient avec succès la même technique contre une autre entreprise.

Les développeurs de logiciels sont en train de devenir des architectes clés qui sous-tendent le succès et la sécurité de nombreuses organisations publiques et privées. L'industrie du pétrole et du gaz en est le meilleur exemple. Il est plus important que jamais qu'ils aient une meilleure connaissance des implications de leur travail en matière de sécurité et qu'ils apprennent à coder de manière sécurisée, quel que soit le langage ou le cadre qu'ils utilisent.

Si vous voulez voir comment les développeurs peuvent s'informer sur la sécurité pour contribuer à la protection des infrastructures critiques, relevez le défi suivant :

https://portal.securecodewarrior.com/#/simple-flow/web/injection/oscmd/cpp/vanilla

La seule chose qui a empêché l'explosion est une erreur dans le code informatique des attaquants, ont indiqué les enquêteurs.

https://www.nytimes.com/2018/03/15/technology/saudi-arabia-hacks-cyberattacks.html

Selon les enquêteurs, la cyberattaque n'avait pas pour but de simplement détruire des données ou d'arrêter l'usine. Elle visait à déclencher une explosion. https://t.co/kQqcAhoW01

" Le New York Times (@nytimes) 15 mars 2018

Une cyberattaque en Arabie saoudite avait un objectif mortel. Les experts craignent une nouvelle tentative. https://t.co/q9UdicR7dv

" Colin Wright (@colinismyname) 22 mars 2018

Cette attaque a constitué une dangereuse escalade dans le piratage informatique international, des ennemis anonymes ayant démontré à la fois la volonté et la capacité d'infliger de graves dommages physiques. https://t.co/G8bBCteouZ#CyberSecurity #NetworkMonitoring

" Elitery Indonesia (@eliterydc) 22 mars 2018

Un récent #cyberassault raté contre une entreprise pétrochimique d'Arabie saoudite avait un objectif mortel. Cet article du @NYTimes en dit plus : https://t.co/3g8oDuPijm pic.twitter.com/MfSqrXSd9u

" Symantec EMEA (@SymantecEMEA) 21 mars 2018

Lors d'un récent vol long-courrier, j'ai profité de l'occasion pour dévorer un volume, franchement insensé, d'épisodes de podcasts. En me tenant au courant de tant de séries différentes, je ne suis jamais à court de quelque chose à écouter, avec des conversations passionnantes - bien qu'unilatérales - à portée de main de l'écran de mon téléphone.

Finalement, je suis arrivé à un épisode du podcast sur les crimes réels, Casefile. Cette série dramatique et sans tabou (avec un animateur à la voix inquiétante et sans nom) se penche sur un sujet qui fascine même les technologues les plus avertis : le web profond et l'ascension cataclysmique du site web de commerce de contrebande Silk Road. Séparé en deux parties, ceux qui connaissent l'ascension et la chute de Silk Road auront sans doute suivi l'actualité de l'affaire, mais le podcast divulgue chaque petit détail, dans une narration délicieuse et captivante.

La route de la soie : Les leçons du donjon du web profond

Si vous ne connaissez pas les tenants et les aboutissants de Silk Road, sachez qu'un homme a créé un site web commercial sur le web profond, à l'abri des regards indiscrets du grand public et impossible à consulter sans l'utilisation d'un logiciel spécial - le navigateur Tor, pour être exact. Au départ, le site ne proposait que ses champignons magiques, mais, pratiquement du jour au lendemain, il a explosé avec des vendeurs proposant de tout, des drogues dures aux armes illégales, en passant par les détails de cartes de crédit volées. Vous pouvez vous informer ici. Le créateur et administrateur du site portait le pseudonyme de Dread Pirate Roberts, inspiré de Princess Bride. Il était tout le monde, il n'était personne. Tous les utilisateurs échangeaient une véritable quantité de marchandises illégales, et ce de manière totalement anonyme (ce qui a valu à Bitcoin la réputation de monnaie de prédilection des trafiquants de drogue, une réputation dont il commence à peine à se défaire).

Cependant, l'expérience anti-establishment de Dread Pirate Roberts était une bête à part entière. Bientôt, des tueurs à gages proposaient leurs services. Les mauvaises personnes faisaient de mauvaises choses... et il était enivré par sa nouvelle richesse insondable. Il a même essayé d'utiliser les services d'un tueur à gages pour se débarrasser d'un ancien employé. Pour faire court, ce fut l'une des nombreuses décisions stupides qui l'ont mené à sa perte. Il a été démasqué sous le nom de Ross Ulbricht et croupit actuellement dans une cellule d'une prison américaine, où il purge une double peine de prison à perpétuité plus quarante ans sans possibilité de libération conditionnelle.

Mais comment s'est-il fait prendre si tout était totalement privé et anonyme ?

Pour parler franchement, c'était un codeur assez médiocre. Le site de la Route de la Soie lui-même était comme une vieille barge qui fuit et qui est abandonnée dans l'océan. Étant donné qu'il s'agissait d'une plaque tournante de l'activité illégale (et de toutes les données liées à cette activité), il n'était pas du tout sécurisé ; c'était une cible facile qui n'attendait que d'être exploitée par un pirate informatique opportuniste. Pour être honnête, lorsque vous êtes le cerveau d'une énorme entreprise de trafic de drogue, il n'est probablement pas facile de trouver des employés compétents qui souhaitent s'impliquer dans votre opération. Il n'a pas non plus caché son manque de compétences - il a même posté sous son vrai nom sur Stack Overflow (oui, c'est son compte d'utilisateur), demandant de l'aide pour configurer correctement le code de son site afin de se connecter à Tor à l'aide de Curl en PHP. Il a changé son vrai nom en "frosty" moins d'une minute après avoir posté, mais cela n'a manifestement pas aidé... en fait, cela a probablement causé plus de dégâts : la clé de cryptage du serveur de Silk Road se terminait par la sous-chaîne "frosty@frosty", ce qui l'a encore plus impliqué une fois que le FBI a eu vent de son odeur.

Malgré un tel effort de protection de la vie privée, avec une messagerie cryptée, des devises et des instructions explicites sur la sécurisation de la contrebande elle-même lors du transport et de la livraison, le site n'était pas la forteresse impénétrable de la fantaisie libertaire qu'Ulbricht avait peut-être imaginée. Les personnes compétentes (à savoir les programmeurs employés par le FBI) l'ont lentement, mais sûrement, démantelé pour tout révéler... y compris l'identité des milliers de personnes qui ont effectué des transactions sur le site. Il est possible que ceux qui ont acheté des produits coquins il y a de nombreuses années se fassent encore frapper à la porte par le bras long de la loi à un moment donné, comme ce type en Allemagne. Ayez l'obligeance de le dire.

Le FBI a publié des documents expliquant comment il a pu pénétrer dans Silk Road, l'explication générale étant l'utilisation d'une fuite d'adresse IP. Une mauvaise configuration de la page de connexion de Silk Road a révélé l'adresse IP et donc l'emplacement physique de ses serveurs, sans qu'aucun piratage sournois ne soit nécessaire. Une erreur de débutant, certes, mais qui a finalement conduit le FBI directement à Ross Ulbricht.

Il semblerait que cette faille - si elle existait - aurait été repérée bien avant ce moment par l'un des nombreux professionnels de la sécurité qui surveillent le site. Nik Cubrilovic, un consultant australien en sécurité, affirme qu'elle n'existait tout simplement pas dans une interview accordée à WIRED:

"Il est impossible de se connecter à un site Tor et de voir l'adresse d'un serveur qui n'est pas un nœud Tor. La façon dont ils essaient de faire croire à un jury ou à un juge que cela s'est produit n'a aucun sens technique."

M. Cubrilovic poursuit en laissant entendre que les informations ont pu être obtenues par des pratiques de piratage illégales. Cette pratique semble être l'injection SQL, une rumeur non prouvée qui a été discutée comme une méthode d'extraction plausible sur de nombreux sites depuis lors.

Les aspects juridiques de la tactique du FBI sont une question tout à fait distincte. Le fait que ces informations aient pu être obtenues est révélateur des mauvaises pratiques de Silk Road en matière de sécurité, même si les utilisateurs considèrent généralement que le site est "privé". Lorsque la vie privée est confondue avec la sécurité, la possibilité d'exposition à des vulnérabilités est très certainement accrue.

Il est également possible que le site soit toujours en activité (dans sa forme originale, en tout cas ; il a été ressuscité à plusieurs reprises et il existe des sites encore plus importants qui lui ressemblent) si Ross Ulbricht avait fait la distinction entre vie privée et sécurité, en s'efforçant activement de garantir les deux avant que le site ne devienne une gigantesque lampe chauffante, attirant tous les escrocs peu recommandables ayant des connaissances technologiques légèrement supérieures à la moyenne sur la planète. Au lieu de cela, le club privé et tous ses secrets ont été révélés dès que quelqu'un a trouvé le moyen d'ouvrir la porte.

Vous n'êtes pas un baron de la drogue, alors pourquoi vous en préoccuper ?

La perte de Silk Road et l'emprisonnement de son fondateur n'est pas une histoire triste et sympathique, mais c'est une étude de cas fascinante sur les différences nuancées entre la protection de la vie privée et la sécurité réelle et robuste d'un site. De nombreuses opérations légitimes exigent que les transactions et les informations soient privées - pensez aux dossiers médicaux numérisés, ou même aux millions de numéros de cartes de crédit détenus par une grande banque - mais si elles ne sont pas également sécurisées par un développement logiciel à toute épreuve, ces informations pourraient être récupérées par un attaquant (et, ironiquement, se retrouver sur un site comme Silk Road). La vie privée n'existe pas sans sécurité.

Les bons élèves, comme vous, pourraient avoir des logiciels vulnérables aux attaques par injection SQL et à d'autres vulnérabilités figurant dans le Top 10 de l'OWASP; il est donc vital de se préparer à ces vulnérabilités et de les atténuer efficacement. Si les développeurs sont formés à coder de manière sécurisée dès le début du processus, ces failles ne verront pas le jour. Il est impératif que les organisations adoptent un état d'esprit axé sur la sécurité et qu'elles donnent à leurs équipes de développeurs les moyens de coder de manière sécurisée. Nous pouvons vous montrer comment le faire de manière amusante, mesurable et ludique. Êtes-vous prêt ?

Partout dans le monde, les entreprises se transforment. L'accent étant mis sur les activités numériques, il est juste de dire que la plupart des organisations sont, en fait, des entreprises de logiciels. Les grandes entreprises comptent parmi leur personnel d'énormes équipes de développement, chargées de développer et de déployer en permanence des fonctionnalités dans un environnement DevOps agile. Cette livraison de fonctionnalités doit suivre le rythme de l'innovation et des attentes des clients, de sorte que trop souvent, la sécurité est considérée comme un obstacle plutôt que comme une nécessité. Cependant, notre dépendance à l'égard des logiciels n'ayant jamais été aussi forte (et par conséquent notre exposition à des violations et à des risques potentiels de cybersécurité), ce scénario ne peut plus durer.

Les équipes de sécurité ne s'agrandissent pas, et même si elles le pouvaient, l'expertise est rare. Des ratios de plus de 1:100 ne sont tout simplement pas suffisants ; les experts en sécurité propriétaires ne peuvent pas être considérés comme la seule solution pour contrer le problème des cybermenaces.

Notre webinaire, présenté par Stephen Allor, directeur (Amériques) de Secure Code Warrior, et Russ Wolfe, doyen de la cybersécurité chez Capital One, va en profondeur sur les problèmes actuels auxquels est confronté DevOps, et ce que les institutions financières comme Capital One font pour engager et améliorer les compétences de leurs équipes de développement sur le codage sécurisé, en encourageant efficacement une culture de sécurité positive et en réussissant à "passer à gauche".

Vous découvrirez :

• Si vous êtes victime du "trou noir" de la connaissance en matière de sécurité
• Pourquoi la sécurité était-elle plus solide il y a quelques décennies qu'aujourd'hui ?
• L'attitude traditionnelle à l'égard de l'AppSec en tant que "case à cocher" de la conformité, et les raisons pour lesquelles cette attitude est au mieux superficielle
• La raison pour laquelle les évaluations de la qualité des applications doivent inclure la sécurité comme élément de référence ; une application non sécurisée ne peut pas être considérée comme de haute qualité, quelle que soit sa conception ou ses caractéristiques.
• Pourquoi l'industrie n'a pas intégré la sécurité des logiciels dans l'état d'esprit et la culture du développeur moyen (et pourquoi cela doit changer).
• Comment l'absence de compétences partagées en matière de codage sécurisé permet aux mêmes vulnérabilités de réapparaître sans cesse.
• Pourquoi les outils d'analyse d'applications ne trouvent pas toutes les vulnérabilités et pourquoi la tactique la plus viable consiste à les éviter en faisant appel à des ingénieurs/développeurs sécurisés suffisamment formés.
• La question des vulnérabilités croissantes dans les logiciels et leurs causes profondes
• Pourquoi c'est l'approche, et non l'élève, qui doit changer pour que les risques soient réellement atténués.
• Pourquoi la plupart des formations à la sécurité n'exploitent pas les points forts des développeurs et quel type de formation leur est nécessaire pour exceller.
• Les raisons pour lesquelles la conformité de l'ingénierie logicielle et les attentes en matière de construction sont en retard par rapport à d'autres branches de l'ingénierie, et comment nous sommes pionniers dans la recherche d'une solution à ce problème.
• Russ Wolfe et son équipe chez Capital One ont conçu un programme de certification autour d'une formation ludique et gamifiée qui permet aux développeurs de s'impliquer, d'apprendre avec du code source réel et d'atteindre des niveaux de référence en matière de meilleures pratiques de sécurité.
• Comment ce programme de certification favorise la participation, la rétention d'informations et la formation continue ?
• Comment les incitations aident les développeurs à franchir les étapes de la formation, à se perfectionner rapidement et à s'aligner sur la politique de sécurité clé ?
• Comment les évaluations permettent d'identifier les champions de la sécurité et de stimuler l'engagement dans la formation.

Regardez notre webinaire maintenant, à la demande, et découvrez les avantages de passer à la gauche et de donner aux développeurs les outils et les connaissances nécessaires pour coder en toute sécurité dès le départ, en mettant l'accent sur des pratiques de sécurité positives.

Découvrez ce que des institutions financières comme Capital One font pour impliquer et perfectionner leurs équipes de développement en matière de codage sécurisé, en encourageant efficacement une culture positive de la sécurité et en réussissant à "passer à gauche".

Nous sommes peut-être un peu partiaux, mais ici, à Secure Code Warrior, nous pensons qu'une carrière dans le développement et l'ingénierie de logiciels est une voie passionnante et gratifiante pour n'importe qui (et elle s'élargit de jour en jour !).

Le 23 juin est la Journée internationale des femmes ingénieurs. Pour célébrer cette journée, nous avons rencontré Lucy T*, développeuse senior pour l'une des plus grandes entreprises de télécommunications de la région Asie-Pacifique, afin d'en savoir plus sur son expérience, sa carrière et ses projets d'avenir. Enthousiaste et intelligente, Lucy possède une expertise de plus de dix ans, dans plusieurs langues, sur plusieurs plateformes et dans plusieurs projets. Son espace de travail est à l'image de ses prouesses technologiques, avec une plate-forme de jeu haut de gamme et une imprimante 3D qu'elle a elle-même construites et qui constituent la pièce maîtresse de sa salle des machines.

Lorsqu'on lui demande de réfléchir à ses débuts dans le développement de logiciels, elle esquisse un sourire ironique : "Je suis tombée dedans par accident. J'ai commencé par étudier la conception à l'université, puis j'ai découvert que ce n'était pas du tout ce que je pensais, alors j'ai abandonné. J'ai eu du mal à trouver un métier qui me plairait suffisamment et je me suis dit que j'avais toujours aimé les ordinateurs, que mon père travaillait dans ce domaine. Je vais faire des études d'informatique et voir comment je me débrouille. J'ai découvert qu'en fait, j'aimais bien ça. Je pensais que je finirais dans une carrière d'infrastructure ou de soutien aux services, mais j'ai eu une opportunité de développement dans un programme d'études supérieures. Il s'avère que c'est exactement ce dont j'avais besoin". En règle générale, Lucy n'a pas de chance. Très logique et planificatrice méticuleuse, elle réfléchit à cet heureux hasard en étant bien consciente de l'ironie de la situation.

Plus de dix ans plus tard, ses tâches quotidiennes tournent principalement autour de projets spécialisés, soutenant de grands systèmes avec la mise en œuvre de nouvelles fonctionnalités et la correction de défauts. Avec des milliers d'utilisateurs naviguant sur ses plates-formes chaque jour, elle est souvent appelée à déployer rapidement des correctifs et à guider ses collègues vers des solutions viables : "Lorsque nous avons un grand projet impliquant l'introduction d'un ensemble de nouvelles fonctionnalités dans le système, c'est là que les choses peuvent devenir délicates. Il est primordial de maintenir le service existant, mais l'assistance générale, qui consiste à expliquer aux utilisateurs comment exécuter une nouvelle fonction, entre également en ligne de compte."

Son poste et ses compétences l'amènent souvent à passer d'une plate-forme à l'autre et d'un langage à l'autre, ce qui lui permet d'assurer le soutien de plusieurs projets. Son expérience comprend six années de développement .NET en C#, mais elle s'est depuis étendue au JavaScript, au Java et à plusieurs API spécifiques à des plateformes. Lorsqu'on lui demande de faire des choix, elle soupire profondément, posant son menton dans sa main. "Ce que j'apprécie le plus, c'est la flexibilité. C'est ce qui ressort de JavaScript maintenant que je l'utilise au quotidien. Je dirai cependant que je déteste absolument Java, ce qui est amusant parce que les gens me disent que C# est comme Java... ce n'est pas du tout le cas. Java est vraiment nul". Elle éclate de rire, faisant fuir son chat géant du canapé. Son franc-parler est rafraîchissant.

L'ancienneté de Lucy au sein de l'équipe peut également signifier qu'elle défend l'aspect sécurité de son travail, en particulier auprès des jeunes diplômés ou des développeurs juniors qui sont accueillis au sein de l'entreprise : "Dans mon domaine, la sécurité est évidemment une priorité absolue. Personne ne veut se voir infliger une amende très coûteuse pour avoir divulgué des données. Les organisations sont très conscientes des informations sensibles, des informations personnelles identifiables, etc. Dans mon équipe informatique actuelle, il est important que les choses que nous développons soient correctement verrouillées du point de vue de la sécurité. Seules les bonnes personnes doivent regarder ces données, y accéder, et ne pas avoir d'autorisation inappropriée, comme l'édition par rapport à la simple lecture. C'est une priorité pour moi d'insister sur ce point avec tous les nouveaux venus dans l'équipe".

Nous avons présenté à Lucy ladémo de la plateforme Secure Code Warrior , qu'elle a maîtrisée avec une facilité impressionnante : "J'aime le fait que ce soit très spécifique au langage de programmation. Je trouve que la plupart des projets de sécurité courses que j'ai entrepris par le passé se situent au niveau de l'organisation, "Oh, faites attention au type de données que vous exposez", plutôt que de chercher à savoir "Qu'est-ce que je fais dans ma vie de tous les jours, et qu'est-ce que je peux faire de ce point de vue ?" Cela semble être une bonne façon de commencer, du niveau débutant jusqu'aux codeurs plus expérimentés, par ce qu'ils peuvent faire dans leur vie de tous les jours pour rendre les choses plus sûres.

Notre conversation porte sur la Journée internationale des femmes ingénieurs et nous lui demandons de réfléchir aux défis, s'il y en a, auxquels elle a été confrontée en tant que femme dans un domaine aussi dominé par les hommes. Elle est manifestement dans son élément lorsqu'il s'agit de développer des logiciels - et elle est hautement qualifiée - mais elle trouve que certaines tâches lui échappent encore : "Je pense que le principal défi n'est pas tant que les hommes supposent que vous n'êtes pas douée pour la technologie - cela n'a jamais été un problème pour moi. Il s'agit plutôt de l'hypothèse selon laquelle, en tant que femme, vous serez également douée pour la communication ou que vous vous orienterez vers ce type de compétences basées sur la communication. Les compétences non techniques, la documentation, tout ce genre de choses. Il m'est arrivé de me retrouver coincée dans un travail de documentation ou de gestion d'une relation client alors que cela ne faisait pas partie de ma description de poste, simplement parce que mon supérieur supposait que j'étais meilleure dans ce domaine en tant que femme". Son rire contagieux reprend de plus belle. "Je n'aime pas interagir avec les gens autant que tout le monde le suppose !

Nos recherches nous ont permis de constater que de nombreuses développeuses ne disposent pas d'un réseau de soutien au cours de leur carrière, en particulier de la part de mentors féminins. Lucy a le sentiment - du moins actuellement - d'être soutenue par ses supérieurs et ses collègues pour s'épanouir : "Je pense que je fais partie d'une équipe qui me soutient en ce moment. J'ai des managers qui me soutiennent, j'ai des mentors. Si je suis bloquée sur quelque chose, j'ai des gens à qui je peux m'adresser pour obtenir de l'aide immédiate sur un projet ou même de l'aide sur le plan de la carrière, par exemple pour savoir où je peux aller à l'avenir. Où quelqu'un dans ma position pourrait aspirer à être dans quelques années, les objectifs de carrière, ce genre de choses".

Aurait-elle eu la même réponse plus tôt dans sa carrière ? "Je ne dirais certainement pas que cela est représentatif de mon expérience, disons, il y a sept ans. En y réfléchissant, je me suis parfois sentie un peu seule".

Lucy encourage avec passion les femmes qui envisagent une carrière dans le développement de logiciels. Lorsqu'on lui demande si elle a un conseil particulier à donner, elle s'assoit en avant sur sa chaise, tout à fait sérieuse : "Pour faire simple, ne vous sous-estimez pas. Cherchez à rencontrer d'autres personnes dans votre position, et d'autres femmes dans la même carrière si vous le pouvez. Apprenez à connaître d'autres personnes dans un environnement similaire, sachez que vous n'êtes pas seule et que les choses que vous vivez sont tout à fait normales. De cette manière, vous apprendrez peut-être plus tôt à apprécier vos propres compétences et à réaliser que les personnes qui vous disent "Oui, je suis excellente dans ce domaine" sont en fait au même niveau que vous. Si vous travaillez dur et que vous vous tenez au courant, je vous garantis que vous serez aussi bon qu'eux. Prenez-le et faites-le".

Des initiatives telles que Code First : Girls, qui se sont engagées à aider 20 000 femmes à apprendre à coder d'ici 2020, contribuent à faire connaître le développement de logiciels comme une carrière viable pour les femmes, ce qui ouvre des perspectives qui n'auraient peut-être pas été envisagées autrement.

Secure Code Warrior Matias Madou, cofondateur et directeur de la technologie, est également passionné par le soutien à la croissance des femmes dans l'industrie : "En tant que startup technologique, il n'est pas facile d'attirer un groupe diversifié de talents prêts à travailler dur et à passer beaucoup d'heures à suivre notre mission d'autonomisation des développeurs. Au cours des six derniers mois, nous avons embauché huit femmes incroyables à des postes de direction et de gestion. Notre équipe d'ingénieurs compte environ neuf nationalités différentes et je suis fermement convaincu que la diversité favorise la créativité et l'empathie. Nous nous engageons à faire en sorte que notre équipe soit un lieu où les femmes peuvent s'épanouir".

(Et pendant que nous vous tenons, si vous êtes un développeur à la recherche d'une nouvelle opportunité, nous sommes toujours à la recherche de guerriers du codage talentueux pour rejoindre l'équipe Awesome ! Consultez notre page Carrières).

* Lucy T est un pseudonyme pour protéger son identité en tant que professionnelle du développement sécurisé dans une grande entreprise. Elle a accepté de participer à cet entretien sous couvert d'anonymat.

Je pensais que je finirais dans une carrière d'infrastructure ou de soutien aux services, puis j'ai eu une opportunité de développement dans le cadre d'un programme d'études supérieures. Il s'avère que c'est exactement ce dont j'avais besoin.

En fonction de l'application, le processus de sérialisation peut se produire en permanence. C'est le terme utilisé pour décrire chaque fois que des structures de données ou des états d'objets sont traduits dans un format qui peut être stocké ou éventuellement envoyé en tant que communication. La désérialisation est l'inverse de ce processus : elle prend les données désormais structurées et les retransforme en l'objet ou la chaîne de données qu'elles étaient avant d'être stockées.

La désérialisation non sécurisée peut se produire lorsqu'une application traite les données désérialisées comme des données de confiance. Si un utilisateur est en mesure de modifier les données nouvellement reconstruites, il peut effectuer toutes sortes d'activités malveillantes telles que des injections de code, des attaques par déni de service ou simplement modifier les données pour se donner un avantage au sein de l'application, par exemple en abaissant le prix d'un objet ou en élevant ses privilèges.

Dans cet épisode, vous apprendrez

• Comment les attaquants peuvent exploiter une désérialisation non sécurisée
• Pourquoi la désérialisation non sécurisée est dangereuse
• Techniques permettant de corriger cette vulnérabilité.

Comment les attaquants exploitent-ils la désérialisation non sécurisée ?

De nos jours, le format de données le plus populaire pour la sérialisation des données est JSON, bien que XML le suive de près. De nombreux langages de programmation proposent également leurs propres méthodes de sérialisation des données, qui contiennent souvent plus de fonctionnalités que JSON ou XML. Dans tous les cas, des problèmes peuvent survenir si les développeurs programment des applications qui traitent les données désérialisées comme des données fiables, au lieu de suivre le vieux mantra des autres blogs de cette série, à savoir : "Ne faites jamais confiance aux données de l'utilisateur !"

L'entrée utilisateur n'est jamais fiable car l'utilisateur peut insérer du code dans ces chaînes, qui pourrait être accidentellement exécuté par le serveur récepteur. Et comme les données brutes désérialisées peuvent parfois être consultées et exploitées, elles doivent être classées dans la même catégorie de non-confiance.

Par exemple, si une application de forum utilise la sérialisation d'objets PHP pour enregistrer un cookie contenant l'identification et le rôle d'un utilisateur, celui-ci peut être manipulé. Un utilisateur malveillant peut changer son rôle "utilisateur" en "administrateur". Il peut également utiliser l'ouverture fournie par la chaîne de données pour injecter du code, qui pourrait être mal interprété et exécuté par le serveur lorsqu'il traite les données "fiables".

Pourquoi la désérialisation non sécurisée est-elle dangereuse ?

Il est vrai que ce type d'attaque nécessite un minimum de compétences de la part d'un pirate, et parfois des essais et des erreurs pendant que l'attaquant apprend quels types de code ou d'exploits le serveur acceptera à partir de ses données manipulées et désérialisées. Cela dit, il s'agit d'une vulnérabilité couramment exploitée en raison de la puissance potentielle qu'elle confère aux pirates suffisamment habiles pour l'utiliser.

Selon la manière dont les données désérialisées sont censées être utilisées, un certain nombre d'attaques, dont beaucoup ont été abordées dans les blogs précédents, peuvent être employées. Une désérialisation non sécurisée peut être une passerelle vers l'injection de code croisé à distance, le scriptage intersite, le déni de service, le détournement de contrôle d'accès et, bien sûr, les attaques par injection SQL et XML. En fait, elle ouvre un point de lancement, déclare que toutes les données désérialisées sont fiables et laisse les attaquants essayer de les exploiter.

Élimination de la désérialisation non sécurisée

La chose la plus sûre que les organisations puissent faire pour empêcher une désérialisation non sécurisée est d'empêcher les applications d'accepter des données désérialisées. Il se peut toutefois que cela ne soit pas possible ou réaliste, mais ne vous inquiétez pas, car il existe d'autres techniques qui peuvent être employées pour se défendre contre ce type d'attaque.

Si possible, les données peuvent être nettoyées et transformées en valeurs numériques. Cela n'empêchera peut-être pas totalement un exploit, mais empêchera les injections de code de se produire. Il est encore mieux d'exiger une forme de contrôle d'intégrité des données désérialisées, telle qu'une signature numérique, qui pourrait garantir que les chaînes de données n'ont pas été manipulées. Tous les processus de désérialisation doivent être isolés et exécutés dans un environnement à faibles privilèges.

Une fois ces protections mises en place, veillez à enregistrer toutes les tentatives de désérialisation qui ont échoué, ainsi que l'activité du réseau provenant des conteneurs ou des serveurs qui désérialisent les données. Si un utilisateur déclenche plus de deux erreurs de désérialisation dans les journaux, c'est une bonne indication qu'il s'agit d'un initié malveillant ou que ses informations d'identification ont été piratées ou volées. Vous pouvez même envisager des mesures telles que le verrouillage automatique des utilisateurs qui déclenchent constamment des erreurs de désérialisation.

Quels que soient les outils que vous utilisez pour lutter contre la désérialisation non sécurisée, n'oubliez pas qu'il s'agit de données qui ont pu être touchées ou manipulées par un utilisateur. Ne vous y fiez jamais.

Plus d'informations sur l'utilisation de composants dont les vulnérabilités sont connues

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos de la désérialisation non sécurisée. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la vitrine gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité pour qu'elles deviennent les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Je suis désolé, je dois vous annoncer une mauvaise nouvelle.

La formation traditionnelle est morte.

Bon, d'accord, ce n'est pas le cas... mais ça devrait l'être. À maintes reprises, des études ont montré que le fait d'enfermer un groupe de personnes dans une salle de classe pour qu'elles apprennent quelque chose de nouveau, accomplissent une tâche de conformité ou suivent un recyclage est l'un des moyens les plus inefficaces de dispenser une formation. Et lorsqu'il s'agit de formation en entreprise, les statistiques ne s'améliorent pas. La Harvard Business Review a publié une étude sur l'efficacité de la formation en classe pour les nouveaux employés des grandes entreprises, qui a révélé que cette méthode d'apprentissage prenait en moyenne entre huit et douze mois pour que les nouveaux employés soient à la hauteur et productifs. C'est un délai très long pour utiliser pleinement les compétences d'une personne (et un long délai pour se sentir à l'aise, si vous êtes le nouvel employé). De nos jours, la plupart des entreprises ne disposent pas d'un tel délai ; inévitablement, les coins sont coupés, les gens ne reçoivent pas la formation dont ils ont besoin et l'entreprise perd une grande partie de la valeur qu'elle aurait pu obtenir beaucoup plus tôt.

Il est tout à fait étonnant que de nombreuses entreprises s'appuient encore sur des salles de classe, des manuels arides et des formations vidéo abrutissantes pour faire adhérer leurs meilleurs éléments aux meilleures pratiques ou aux nouvelles initiatives de l'entreprise, alors qu'il existe une méthode d'apprentissage bien meilleure, plus engageante et plus précieuse : la formation contextuelle. Il s'avère que nous, les humains, retenons beaucoup mieux les informations lorsque nous mettons la main à la pâte avec de nouvelles idées et de nouveaux processus.

En ce qui concerne les développeurs, nous sommes un groupe spécial. D'après ma propre expérience en tant que développeur, la formation traditionnelle ne m'emballe pas vraiment. Les développeurs ont tendance à être des personnes créatives et ingénieuses qui préfèrent utiliser les outils plutôt que de se faire sermonner dans une salle de classe ou d'être assis devant des vidéos interminables d'une tête parlante lorsqu'ils essaient d'apprendre de nouvelles informations. Si vous regardez la formation à la sécurité en particulier, il semble y avoir une déconnexion claire dans le paysage actuel : les développeurs ne traitent pas les vulnérabilités courantes dans leur code, ce qui conduit les professionnels de l'AppSec à s'arracher les cheveux lorsqu'ils sont confrontés aux mêmes problèmes facilement corrigés, encore et encore. Les relations entre ces équipes sont tendues, et les développeurs ne disposent pas des outils et de la formation nécessaires pour respecter les meilleures pratiques en matière de développement sécurisé. Leur principal objectif est de créer des fonctionnalités, mais avec l'augmentation rapide du risque cybernétique pour chaque entreprise, nous ne pouvons tout simplement plus nous permettre d'ignorer et de déprioriser les connaissances en matière de sécurité.

Et le meilleur ? Si les développeurs sont sensibilisés à la sécurité, ces vulnérabilités courantes commencent à disparaître. Le risque est réduit, de même que les coûts de correction des bogues à un stade avancé (et les responsables de la sécurité des applications cessent de perdre leurs cheveux par poignées).

Alors, à quoi ressemble exactement l'engagement des développeurs dans une formation contextuelle ?

Les exemples du monde réel sont ridiculement puissants.

Imaginez que nous devions tous apprendre à conduire en regardant des vidéos sur YouTube. Bien que vous puissiez vous faire une idée générale du fonctionnement d'une voiture, ainsi que de la séquence d'événements qui est initiée pour vous faire avancer sur la route, il serait pratiquement impossible d'apprendre à bien conduire avant de monter dans une voiture et de l'essayer en personne.

La formation contextuelle est si précieuse qu'elle place l'étudiant aux commandes de ce qui lui est enseigné. Lorsque vous disposez d'un contexte réel pour quelque chose, l'apprentissage est beaucoup plus intéressant et significatif.

En ce qui concerne le codage sécurisé, n'importe qui peut regarder une vidéo et comprendre les bases de l'injection SQL, mais les détails pratiques de la résolution du problème sont facilement oubliés lorsque les délais approchent et que la priorité est donnée à la livraison des fonctionnalités. Toutefois, s'il était possible d'examiner des exemples de code réels, d'identifier l'injection et de la corriger dans le cadre d'un exercice de formation, cela serait bien plus applicable au travail quotidien d'un développeur que d'essayer de retenir des informations à sens unique. C'est également plus facile à comprendre pour un développeur, s'il voit un code similaire à ce qu'il écrit habituellement, il se lèvera et prêtera attention.

Sur la plateforme Secure Code Warrior nous avons gamifié la formation au code sécurisé, en proposant une grande variété de défis dans plusieurs langages et frameworks. Le système encourage la répétition des jeux et, surtout, il est instantanément personnalisable pour offrir un environnement propice à un véritable apprentissage contextuel.

Fournir des connaissances au moment où elles sont le plus utiles

Selon la théorie de l'apprentissage contextuel, l'apprentissage n'est efficace que lorsque les étudiants traitent les nouvelles informations ou connaissances de manière à ce qu'elles aient un sens pour eux, dans leur propre cadre de référence.

Imaginez qu'un développeur reçoive une liste de vulnérabilités de sécurité provenant de programmes de récompense des bogues, d'outils SAST ou de logiciels de suivi des bogues. Il peut être perplexe, voire accablé, s'il n'a jamais rencontré ces vulnérabilités auparavant. Pire encore, la plupart des rapports sont conçus pour les experts en sécurité des applications et non pour les développeurs. Les informations contenues dans les rapports sont difficiles à analyser et contiennent souvent des conseils génériques qui ne s'appliquent pas directement à un développeur.

Récemment, nous avons ajouté la possibilité d'établir des liens directs avec des formations pratiques sur les vulnérabilités provenant de programmes de recherche de bogues, d'outils SAST, de logiciels de suivi des bogues et de rapports de tests de pénétration. Les développeurs peuvent immédiatement comprendre les bases et apprendre les bonnes recettes de codage pour leur cadre particulier.

En apprenant de cette manière, les développeurs reçoivent des connaissances et une formation sur des concepts au moment où ils sont les plus pertinents, et ils sont beaucoup plus susceptibles de retenir ces informations à long terme.

Des résultats plus rapides, moins de perturbations, des campeurs plus heureux.

Quelle que soit la formation, une mise en contexte immédiate avec vos activités quotidiennes sera bien plus efficace que d'essayer d'appliquer quelque chose de générique à votre travail. Vous passerez moins de temps en "mode étude" ou, pire encore, vous devrez revenir sur ce que vous avez déjà "appris" lorsque vous aurez besoin d'une réponse à une question.

L'un des principes de la formation contextuelle est la capacité à construire sur la base des connaissances, de sorte que chaque composante de la formation s'ajoute à la précédente, ce qui permet un processus par étapes qui donne aux participants un chemin vers la maîtrise. Là encore, c'est quelque chose que nous soutenons sur notre plateforme, avec un système de ceintures similaire à celui que l'on peut trouver dans un dojo de karaté. Tout le monde commence par une ceinture blanche, avant de progresser jusqu'à la ceinture noire convoitée, ou le niveau de "champion de la sécurité", après avoir effectué les heures d'entraînement nécessaires et participé au site tournament . Il s'agit d'une approche amusante avec une valeur réelle et une application pratique.

Vous voulez retenir les meilleurs talents et les sensibiliser à la sécurité ? Donnez-leur les outils pour réussir.

Il est malheureux de constater qu'à l'heure actuelle, les développeurs sensibilisés à la sécurité et les spécialistes de l'AppSec sont une ressource rare (et pourtant vitale). Ils sont aussi notoirement difficiles à retenir.

Cybrary a mené une enquête auprès de 3100 professionnels de l'informatique et de la sécurité en 2018, révélant qu'un élément clé pour retenir les employés de valeur était d'investir dans leur formation. Leurs conclusions montrent que les entreprises qui fournissent les outils et la formation nécessaires pour développer leurs compétences internes en matière de sécurité ont été en mesure de retenir les professionnels de la sécurité 60 % de plus que celles qui ne le font pas, et un énorme 65 % des répondants préféraient que cette formation soit pratique. Pas mal, hein ?

Cependant, les résultats de l'enquête ont également fourni une révélation plutôt alarmante : 80 % des personnes interrogées ne se sentent pas suffisamment préparées pour défendre leur organisation contre les cybermenaces. Ces menaces ne sont pas près de disparaître, et il est plus que jamais nécessaire de mettre en place une formation adéquate pour lutter contre le risque croissant de violations de données et d'attaques coûteuses. Je suis peut-être partial, mais la plateforme Secure Code Warrior pourrait être l'outil dont vous avez besoin pour instaurer une culture de la sécurité positive, renforcer les compétences et soutenir les développeurs grâce à la formation contextuelle qu'ils apprécient et protéger votre organisation contre les malfaiteurs. Demandez une démonstration et nous vous en dirons plus.

L'exposition de données sensibles est à l'origine de certaines des violations de données les plus médiatisées et les plus importantes de ces dernières années, comme la violation catastrophique de Marriott, où plus de 300 millions de dossiers de clients ont été volés, et 150 millions d'autres lors de l'attaque d'Equifax. Un niveau moyen de sophistication est requis, et parfois un équipement spécial de la part de l'attaquant, mais il n'est pas trop difficile pour un pirate de réussir dans de nombreux cas, et il existe des outils pour automatiser certaines des fonctions d'attaque.

L'exposition de données sensibles se produit lorsque des informations qui ne sont destinées qu'à un usage autorisé sont exposées à une personne non autorisée dans un état non crypté, non protégé ou faiblement protégé. La plupart du temps, il s'agit de données que les pirates veulent voler, telles que des numéros de cartes de crédit, des identifiants d'utilisateurs, des secrets d'affaires et des informations personnelles qui pourraient être protégées par des lois et des réglementations sectorielles.

Les pirates peuvent voler des informations sensibles si elles sont stockées sans chiffrement ou en attaquant indirectement le système de chiffrement. Au lieu d'essayer de décrypter directement un chiffrement fort, ils volent les clés de chiffrement ou attaquent les données lorsqu'elles passent à un état non chiffré, par exemple lorsqu'elles sont préparées pour le transport.

Dans cet épisode, vous apprendrez

• Comment les attaquants peuvent-ils déclencher l'exposition de données sensibles ?
• Pourquoi l'exposition aux données sensibles est-elle si dangereuse ?
• Techniques permettant de corriger cette vulnérabilité.

Comment les attaquants exploitent-ils l'exposition aux données sensibles ?

L'exposition de données sensibles se produit généralement lorsque les sites n'utilisent pas un cryptage solide de bout en bout pour protéger les données, ou lorsqu'il y a des failles exploitables dans le système de protection. Elle peut également se produire lorsque le chiffrement utilisé est particulièrement faible ou obsolète.

Les pirates essaieront souvent de trouver des moyens de contourner le chiffrement s'il n'est pas généralisé. Par exemple, si une base de données d'identité d'utilisateur stocke des informations dans un état crypté, mais les décrypte automatiquement lorsqu'elles sont récupérées, un pirate pourrait être en mesure d'utiliser l'une des attaques que nous avons couvertes précédemment dans ces blogs, telles que l'injection SQL ou XML, pour ordonner à la base de données d'effectuer le processus de décryptage. Les données seraient alors décryptées pour le pirate, sans effort supplémentaire. Pourquoi essayer d'enfoncer une porte en acier quand vous pouvez simplement voler la clé ?

La faiblesse du cryptage est également un problème. Par exemple, si les cartes de crédit sont stockées à l'aide d'un système de cryptage obsolète, cela peut poser un problème si un pirate informatique est en mesure d'utiliser une vulnérabilité telle que l'inclusion d'un fichier local pour transférer l'ensemble de la base de données sur son ordinateur. Si les données capturées sont protégées à l'aide d'un système de cryptage puissant, tel que le cryptage AES-256 bits, il sera beaucoup plus difficile de les pirater si elles tombent entre les mains d'un hacker. Mais si un cryptage plus faible ou obsolète est utilisé, comme l'ancienne norme DES, un pirate disposant d'un équipement spécial tel qu'un rack d'unités de traitement graphique (GPU) peut s'atteler à casser le cryptage en un temps relativement court.

Pourquoi l'exposition aux données sensibles est-elle dangereuse ?

L'exposition des données sensibles est dangereuse car elle permet à des utilisateurs non autorisés de voir des informations protégées. Si les données n'étaient pas importantes, elles ne seraient pas protégées, de sorte que toute violation de cette protection entraînera des problèmes. Ce n'est jamais une situation à laquelle une organisation souhaite être confrontée.

L'ampleur des problèmes causés par l'exposition de données sensibles dépend du type de données exposées. Si les données relatives à l'utilisateur ou au mot de passe sont volées, elles peuvent être utilisées pour lancer d'autres attaques contre le système. L'exposition d'informations personnelles peut exposer les utilisateurs à des attaques secondaires telles que l'usurpation d'identité ou l'hameçonnage. Les organisations peuvent même se retrouver exposées à de lourdes amendes et à des actions gouvernementales si les données exposées sont légalement protégées par des lois telles que le Health Insurance Portability and Accountability Act (HIPAA) aux États-Unis ou le Règlement général sur la protection des données (RGPD) en Europe.

Éliminer l'exposition aux données sensibles

Pour mettre fin à l'exposition des données sensibles, il faut d'abord assurer un chiffrement solide, actualisé et de bout en bout des données sensibles dans toute l'entreprise. Cela concerne à la fois les données au repos et en transit. Il ne suffit pas de chiffrer les données sensibles lorsqu'elles sont stockées. Si elles ne sont pas chiffrées avant d'être utilisées ou transportées, elles peuvent être exposées à l'aide d'une attaque secondaire qui incite un serveur à les déchiffrer.

Les données en transit doivent toujours être protégées à l'aide de la technologie Transport Layer Security (TLS) afin d'éviter que l'homme du milieu ou d'autres attaques contre les données en mouvement ne les exposent à des risques. Les données sensibles ne doivent jamais être mises en cache, où que ce soit dans le réseau. Les données sensibles doivent être soit stockées avec un cryptage fort, soit envoyées en utilisant la protection TLS, ce qui ne laisse aux attaquants aucun point faible à exploiter.

Enfin, faites l'inventaire des types de données sensibles qui sont protégées par votre organisation. S'il n'y a aucune raison pour que votre organisation stocke ces données, jetez-les. Pourquoi vous exposer à des problèmes potentiels sans aucun avantage possible ? Les données qui ne sont pas conservées par une organisation ne peuvent pas lui être volées.

Plus d'informations sur l'exposition aux données sensibles

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos de l'exposition des données sensibles. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité pour qu'elles deviennent les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

L'attaque par injection d'entité externe XML, parfois simplement abrégée en injection XXE, est relativement récente par rapport à certaines vulnérabilités classiques qui font encore parler d'elles des années après leur apparition. Mais elle est extrêmement populaire parmi les communautés de pirates informatiques et le devient de plus en plus au fur et à mesure qu'elle accumule les succès.

En fait, l'OWASP classe désormais l'injection XXE parmi les dix principales vulnérabilités que les sites doivent surveiller et contre lesquelles ils doivent se défendre activement. Mais ne vous inquiétez pas, l'injection XXE n'est pas plus puissante que les autres exploits déployés dans les cyberattaques. Elle est simplement un peu plus récente et un peu moins bien comprise. Il est possible de l'éviter et, en fait, de l'arrêter complètement.

Dans cet épisode, vous apprendrez

• Comment les attaquants utilisent les injections XXE
• Pourquoi l'injection XXE est-elle dangereuse ?
• Techniques permettant d'éviter cette vulnérabilité.

Comment les attaquants déclenchent-ils une injection XXE ?

La vulnérabilité de l'injection XXE peut se produire lorsqu'un utilisateur malveillant a la possibilité de soumettre un code XML. Il utilise cette capacité pour créer une référence à une entité externe. La référence externe et le code sont conçus pour contourner un analyseur XML avec des paramètres par défaut ou faiblement configurés.

L'attaquant exploite le fait que la norme XML définit le concept d'entité comme une unité de stockage d'un certain type, mais que ce stockage peut être externe ou interne. Utilisé correctement, il peut permettre aux processeurs XML d'accéder à des ressources distantes. Le plus souvent, les attaquants utilisent cette capacité pour sonder la structure interne d'un site web, lancer une attaque par déni de service en déclenchant de gros processus système essayant d'accéder à des ressources distantes, ou même décharger des données d'un hôte local vers un hôte distant qu'ils contrôlent " ce qui en fait une bonne technique pour exfiltrer des données importantes comme les mots de passe ou les informations personnelles contenues dans la base de données XML.

Le code utilisé pour l'attaque est souvent assez simpliste, se contentant d'exploiter la fonctionnalité de l'entité. Par exemple, cela pourrait permettre à un pirate d'accéder au fichier du mot de passe principal :

<!ENTITY hackwithxxe SYSTEM file:///etc/password>

Pourquoi l'injection XXE est-elle dangereuse ?

Il y a plusieurs raisons pour lesquelles les attaques par injection XXE sont si dangereuses et si répandues. Tout d'abord, il s'agit d'une vulnérabilité moins bien comprise à l'heure actuelle. Et les gains qu'un attaquant peut réaliser en l'exploitant sont considérables. D'une part, elle peut permettre à des attaquants persistants de cartographier lentement tous les chemins d'un réseau interne ou même de scanner les ports. Bien que cela puisse prendre un certain temps, il n'y a pratiquement aucune chance que l'activité d'un pirate soit découverte par des défenses actives sur le réseau cible parce qu'il envoie simplement du code XML dans un serveur qui est nettoyé par l'analyseur XML de confiance.

Une fois qu'ils ont établi leur plan, les attaquants peuvent utiliser les mêmes techniques d'injection XXE pour s'emparer des fichiers dont ils ont besoin, soit en volant directement des informations, soit en compromettant les informations d'identification des utilisateurs valides et en les utilisant pour des attaques secondaires. Enfin, les attaquants qui veulent simplement faire du bruit et être malveillants peuvent par exemple déclencher des attaques par déni de service, en ordonnant à l'application d'essayer d'accéder à des ressources distantes conçues pour bloquer le système.  

Élimination de la vulnérabilité de l'injection XXE

En raison de l'augmentation rapide des attaques par injection XXE, de nombreux analyseurs XML commencent à désactiver complètement par défaut les entités externes, parfois appelées DTD. Pour ceux-là, la clé consiste simplement à ne pas activer cette fonctionnalité.

Mais même les analyseurs qui autorisent les DTD peuvent avoir cette fonctionnalité désactivée. En général, une instruction comme la suivante est nécessaire pour la bloquer complètement, mais vérifiez la documentation de votre framework local pour obtenir le code exact nécessaire.

factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) ;

Conformément aux principes de sécurité, toutes les entrées utilisateur doivent être assainies et validées à l'aide de filtres applicables à l'ensemble de l'application. N'oubliez pas d'inclure les paramètres GET et POST, les en-têtes HTTP et les cookies. Vous pouvez également créer une liste blanche de DTD et de commandes spécifiques que vous souhaitez que l'analyseur traite, et interdire tout le reste.

Bien que la liste blanche et le filtrage fonctionnent, en raison du nombre croissant d'attaques par injection de XXE, il est recommandé de désactiver complètement la prise en charge de la DTD si cette fonctionnalité n'est pas nécessaire.

Plus d'informations sur XXE Injections

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP sur les attaques par injection XXE. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité à devenir les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .