Les bases de données NoSQL sont de plus en plus populaires. Il est difficile de nier leur rapidité et leur facilité à traiter les données non structurées, en particulier pour les équipes de développement qui travaillent selon des méthodologies de plus en plus agiles.

Il faut du temps aux développeurs pour éliminer les vulnérabilités et autres difficultés des technologies émergentes. Ce n'est qu'après avoir été utilisée pendant un certain temps dans des applications de production que les problèmes commencent à remonter à la surface.

Les bases de données NoSQL sont similaires. Les développeurs doivent être conscients de certains risques clés afin de garantir la sécurité de leurs applications. L'un de ces risques est l'injection NoSQL.

Voyons ce qu'est une injection NoSQL, quels sont les dommages qu'elle peut causer et comment y remédier :

Comprendre l'injection NoSQL

L'injection NoSQL est causée par un grand nombre des mêmes vulnérabilités d'injection telles que l'injection XML ou SQL.

L'injection NoSQL permet aux attaquants de placer des commandes arbitraires dans une requête NoSQL. Cela leur permet de voler des données et même d'apporter des modifications à la base de données si leurs privilèges sont suffisamment élevés.

Lorsqu'une application place des données contrôlées par l'utilisateur directement dans une expression de requête NoSQL, ces expressions prennent souvent des fonctions ou ont des opérateurs intégrés qui peuvent être manipulés pour voler ou modifier des données. Et lorsqu'une telle chose est exécutée avec une intention malveillante, les conséquences peuvent être désastreuses.

Les bases de données MongoDB sont l'un des terrains de jeu les plus populaires pour exploiter cette vulnérabilité. "$ne : """ est l'opérateur équivalent à 1=1 dans le monde SQL. Ainsi, par exemple, un attaquant pourrait placer les caractères "$ne : ""' dans les champs nom d'utilisateur et mot de passe d'une interface utilisateur. Si le code est vulnérable à l'injection NoSQL, la base de données recherchera tous les enregistrements où le nom d'utilisateur et le mot de passe ne sont pas égaux à une chaîne vide. En d'autres termes : tous. Vous avez raison.

Si cette base de données n'est pas cryptée, l'attaquant peut voler les noms d'utilisateur et les mots de passe de chacun des utilisateurs qu'elle contient. Cela inclut les noms d'utilisateur et les mots de passe des administrateurs, ce qui leur donne un accès illimité à l'ensemble de la base de données.

Les attaquants tentent souvent d'introduire des valeurs qui sont toujours vraies. Une autre attaque courante consiste à injecter du code malveillant dans les propriétés définies comme des fonctions.

Par exemple, MongoDB utilise une fonction de recherche qui prend un objet avec une propriété appelée $where. La propriété $where est définie comme une fonction qui doit être évaluée à true ou false. Si cette fonction est modifiée de quelque manière que ce soit par l'utilisateur, il est probable qu'une injection NoSQL s'y cache.

Pour un aperçu détaillé des subtilités de l'injection NoSQL, consultez cet article d'InfoQ.

Pourquoi l'injection NoSQL est-elle dangereuse ?

L'injection NoSQL est dangereuse principalement parce qu'elle n'a pas encore reçu l'attention qu'elle mérite de la part de la communauté de la sécurité.

Les conséquences de l'injection NoSQL sont sensiblement les mêmes que celles de l'injection SQL traditionnelle. Des données peuvent être volées ou modifiées, des comptes peuvent être compromis par le vol de données et, ce qui est peut-être le plus grave, des données peuvent être complètement effacées si une commande d'effacement est lancée avec succès.

En définitive, MongoDB et les autres moteurs de base de données NoSQL sont vulnérables aux attaques. "Pas de SQL" ne signifie pas pas d'injections.
Heureusement, certains membres de la communauté en prennent note et font passer le message. Davantage de développeurs doivent s'informer afin de pouvoir protéger leurs applications contre des dangers peu connus qui peuvent devenir un véritable casse-tête s'ils sont exploités.

Vaincre l'injection NoSQL

L'injection NoSQL peut être difficile à vaincre. Malheureusement, il n'est pas possible d'utiliser des requêtes paramétrées comme dans le cas de l'injection SQL. Cependant, ce n'est pas impossible. Il existe quelques options pour vous aider :

• Les fuzzers peuvent être utilisés comme une méthode pour détecter les vulnérabilités. Cependant, comme c'est le cas pour beaucoup de choses dans la vie, l'approche la plus simple peut être la plus efficace. Dans ce cas, le bon vieil examen du code est votre meilleur allié.
• Lorsque vous révisez le code, recherchez les endroits où l'entrée de l'utilisateur pourrait fixer la valeur d'une expression ou modifier une fonction. Ne permettez pas à l'utilisateur de modifier vos requêtes.
• Veillez à attribuer à l'entrée de l'utilisateur la classe qui lui revient. Si c'est un nombre, transformez-le en nombre, si c'est une chaîne, transformez-la en chaîne et ainsi de suite.
• N'utilisez jamais $where ou d'autres fonctions d'évaluation similaires en même temps que les données saisies par l'utilisateur. Dans la plupart des cas, vous pouvez contourner le problème en modifiant le modèle de données ou le schéma.
• Essayez d'utiliser Mongoose comme pilote MongoDB. Mongoose vous permet de définir un schéma pour votre base de données NoSQL. Si vous indiquez à Mongoose que vos entrées sont des chaînes, elles seront converties en chaînes. Ainsi, tout objet transmis par un attaquant ne sera pas traité comme un objet, mais comme une chaîne de caractères.
• Renforcez votre base de données ! Créez des comptes utilisateurs à faibles privilèges, maximisez le temps d'exécution des requêtes et suivez toujours les meilleures pratiques de sécurité qui s'appliquent à votre organisation.

La facilité d'utilisation des bases de données NoSQL a pour inconvénient que les développeurs ont tendance à les mettre en place et à les utiliser sans se soucier de la sécurité.

Il est essentiel que vous preniez le temps d'apprendre à mettre en place une base de données NoSQL en toute sécurité et à vous protéger contre les injections NoSQL.

Par exemple, MongoDB Enterprise Edition dispose de capacités avancées de contrôle d'accès à vos documents. L'application du principe du "moindre privilège" peut constituer une bonne stratégie de défense en profondeur au cas où quelqu'un découvrirait une vulnérabilité dans votre application.

Pour résumer, voici ce que nous avons :

• Assainissez vos données avant de les utiliser dans une expression de requête NoSQL.
• Utilisez des pilotes qui vous aident, comme Mongoose
• Effectuer des revues de code portant spécifiquement sur la manière dont les données d'entrée sont utilisées dans les requêtes.
• Utilisez des fuzzers et des scanners pour essayer de trouver des vulnérabilités dans votre code.

NoSQL n'est pas No Injections

Les bases de données NoSQL gagnent rapidement en popularité en raison de leurs caractéristiques évolutives et de leur rapidité d'installation. La nouveauté de la technologie peut conduire les développeurs à utiliser les bases de données NoSQL sans penser à la manière de les sécuriser.

Les bases de données NoSQL peuvent être tout aussi vulnérables que les bases de données SQL aux attaques par injection, alors agissez avec prudence et faites attention à vos requêtes. Si vous souhaitez en savoir plus, consultez nos ressources d'apprentissage ou testez vos compétences avec notre démo gratuite.

Préparez-vous à l'avance et vous n'aurez plus à vous soucier des injections NoSQL dans vos applications. Trop facile !

Vous pensez être prêt à localiser, identifier et réparer une injection NoSQL dès maintenant ? Entrez dans l'arène du code sécurisé, guerrier :

Et c'est terminé pour 2018 ! Ce sera notre dernier billet pour l'année, mais nous serons de retour avec le prochain guide Coders Conquer Security le 10 janvier 2019. À bientôt !

Contrairement aux attaques visant directement les opérateurs de sites web ou d'applications, l'objectif de nombreuses attaques de type Cross-Site Request Forgery (CSRF) est de voler de l'argent, des biens ou des informations d'identification directement à un utilisateur. Cela ne signifie pas que les opérateurs de sites doivent ignorer les vulnérabilités du code CSRF, car en fin de compte, le remplacement des fonds volés, dans le cas d'une attaque purement monétaire, peut être de la responsabilité du site d'hébergement dont le code n'est pas sécurisé. Et si l'utilisateur ciblé perd ses informations d'identification ou si son mot de passe est modifié à son insu, un criminel pourrait être en mesure de faire des ravages en utilisant cette identité volée, en particulier si la victime dispose d'un accès privilégié.

Les attaques CSRF sont assez complexes et s'appuient sur plusieurs couches pour réussir. En d'autres termes, de nombreux éléments doivent se briser en faveur de l'attaquant pour que l'attaque fonctionne. Malgré cela, il s'agit d'un vecteur d'attaque extrêmement populaire, car une attaque réussie peut transférer de l'argent directement à un pirate, ou lui permettre de se déplacer sur un site en toute impunité. Si tout se passe bien pour le pirate, l'utilisateur ciblé peut ne jamais savoir qu'il a été victime d'une attaque.

La bonne nouvelle, c'est qu'il y a beaucoup de choses à faire pour qu'une attaque CSRF fonctionne, et qu'il existe un grand nombre de techniques défensives qui peuvent l'arrêter dans son élan.

À cette fin, nous allons examiner trois aspects clés des attaques CSRF :

• Comment ils fonctionnent
• Pourquoi ils sont si dangereux
• Comment vous pouvez mettre en place des défenses pour les stopper net.

Comment fonctionnent les attaques CSRF ?

Parce que les attaques CSRF réussies ont la capacité de voler directement de l'argent, des biens ou des informations d'identification aux utilisateurs ciblés, elles sont populaires en dépit de la quantité de travail nécessaire pour les créer. Et comme elles sont souvent tentées sur différentes plateformes, elles ont pris au fil des ans toute une série de noms et de surnoms. Vous pouvez entendre parler des attaques CSRF comme XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery ou Hostile Linking. Microsoft aime les qualifier d'attaques en un clic dans la plupart de ses documents. Mais il s'agit toujours d'attaques CSRF, et les techniques pour les déjouer sont identiques.

Une attaque CSRF peut se produire si un utilisateur est connecté à un site dans le cadre de ses activités professionnelles ou de son travail. L'essentiel est que l'utilisateur soit connecté et activement authentifié sur un site web ou une application. L'attaque est normalement lancée à partir d'un site web secondaire ou d'un e-mail. Souvent, les attaquants utilisent des techniques d'ingénierie sociale pour inciter les utilisateurs à cliquer sur un lien dans un courrier électronique qui les conduit à un site web compromis contenant le script de l'attaque.

Le site web compromis contient un script qui ordonne au navigateur actif d'exécuter des commandes, généralement quelque chose de malveillant comme la modification du mot de passe d'un utilisateur ou le transfert d'argent sur un compte contrôlé par l'attaquant. Tant que l'utilisateur est authentifié, le site pense que les commandes sont émises par l'utilisateur autorisé. Pourquoi ne le ferait-il pas ? L'utilisateur s'est déjà authentifié et a fourni tous les mots de passe nécessaires pour accéder au site. Il peut même se trouver à l'intérieur d'un périmètre géographique, correctement assis à son terminal de bureau. S'il souhaite modifier son mot de passe ou transférer des fonds, il n'y a aucune raison de ne pas croire que c'est lui qui fait la demande.

En décomposant les éléments de l'attaque, on comprend pourquoi celle-ci est si difficile à réaliser pour l'attaquant. Tout d'abord, l'utilisateur doit être activement authentifié sur le site où l'attaque a lieu. Si un courriel contenant un script d'attaque arrive après que l'utilisateur a terminé sa session de navigation ou s'est déconnecté, l'attaque échoue.

L'attaquant est également obligé de faire beaucoup de reconnaissance sur le site ciblé afin de savoir quels scripts ce site acceptera. Les attaquants ne peuvent pas voir l'écran de la victime et tout retour d'information de la part du site web ira à la victime, pas à l'attaquant. À moins que l'attaquant ne soit en mesure de voir la preuve que son attaque a fonctionné, comme de l'argent apparaissant soudainement sur son compte, il ne saura même pas immédiatement si son attaque a réussi.

Si l'on tient compte des paramètres difficiles, mais pas impossibles, selon lesquels l'utilisateur doit être connecté au moment de l'attaque et savoir quels scripts le site ciblé accepte, le code permettant d'exécuter une attaque CSRF peut être extrêmement simple, bien qu'il varie en fonction du site lui-même.

Supposons qu'une banque ou une application financière utilise des requêtes GET pour transférer de l'argent, comme ceci :

GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

Ce code enverrait une demande de transfert de 100 dollars à un utilisateur nommé NancySmith12.

Mais si l'utilisateur ciblé reçoit un courrier électronique, peut-être déguisé comme provenant d'un collègue, un script d'attaque CSRF pourrait être intégré dans l'action de clic :

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>

Si l'utilisateur ciblé se laisse séduire par le lien d'ingénierie sociale et clique dessus alors que la session de navigation avec l'application financière est toujours ouverte, son navigateur demande à l'application d'envoyer 100 000 dollars sur le compte de ShadyLady15.

Le script pourrait même être caché dans une image invisible que l'utilisateur ne verrait pas, mais qui pourrait tout de même inciter le navigateur à faire la demande, comme ceci :

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

Le résultat est le même. ShadyLady15 obtient 100 000 $ sans que personne ne détecte l'attaque.

Pourquoi le CSRF est-il si dangereux ?

Les attaques CSRF sont aujourd'hui populaires pour la même raison que les attaques par ransomware. Il y a très peu d'étapes entre les attaquants et l'argent de la victime. Dans une attaque par ransomware, les systèmes sont cryptés et les utilisateurs sont extorqués pour obtenir de l'argent afin de décrypter les données. Avec une attaque CSRF, il y a encore moins d'étapes. Lorsqu'elles fonctionnent, les victimes envoient simplement de l'argent aux attaquants sans le savoir.

Au-delà des attaques directes contre l'argent d'une victime ou les finances d'une entreprise, les attaques CSRF réussies peuvent être utilisées pour compromettre un réseau utilisant des utilisateurs valides. Imaginez qu'un attaquant puisse utiliser un exploit CSRF pour changer le mot de passe d'un administrateur. Il pourrait immédiatement utiliser ce mot de passe pour commencer à voler des données, ouvrir des brèches dans les défenses du réseau ou installer des portes dérobées.

Bien que cela demande beaucoup de travail, et dans une certaine mesure de la chance, une attaque CSRF réussie peut être comme gagner à la loterie pour les pirates, quel que soit leur objectif final. Lors de l'attaque d'un réseau, presque tout autre type d'attaque nécessiterait des mois de reconnaissance lente, en essayant de rester sous le radar du SIEM et du personnel de cybersécurité. En revanche, une seule attaque CSRF permet de sauter un certain nombre d'étapes de la chaîne de la mort cybernétique, ce qui permet aux pirates de commencer très près de leur objectif final.

Comment arrêter les attaques CSRF ?

Contrairement à la plupart des vulnérabilités, dans le cas des attaques CSRF, ce n'est pas vraiment le code qui est en cause, mais un exploit que les attaquants ont créé pour forcer un navigateur à effectuer des requêtes que l'utilisateur ne souhaite pas, et dont il n'est peut-être même pas au courant. Mais il est possible de les déjouer.

L'une des meilleures méthodes consiste à demander aux développeurs d'ajouter un jeton CSRF à l'identité de l'utilisateur chaque fois qu'une nouvelle session est générée. Ce jeton doit consister en une chaîne de caractères uniques et aléatoires et être invisible pour les utilisateurs. Ensuite, ajoutez la demande de jeton CSRF en tant que champ caché dans les formulaires qui sont vérifiés par le serveur chaque fois qu'une nouvelle demande est soumise. Les attaquants qui soumettent des requêtes par l'intermédiaire du navigateur d'un utilisateur ne seront même pas au courant de l'existence du champ de jeton caché, et seront encore moins en mesure de le découvrir, de sorte que toutes leurs requêtes échoueront.

Une méthode encore plus simple, et qui ne nécessite pas beaucoup de programmation, consiste à ajouter un défi Captcha à tout ce qui est sensible, comme les demandes de changement de mot de passe ou les ordres de transfert d'argent. Il peut s'agir simplement de demander à l'utilisateur de cliquer sur un bouton confirmant que le demandeur n'est pas un robot ou, dans le cas présent, un script CSRF. Les attaquants ne seront pas en mesure de rédiger une réponse au défi, et les utilisateurs qui reçoivent soudainement un défi CAPTCHA sans d'abord faire quelque chose comme une demande de transfert d'argent sauront qu'il y a quelque chose d'anormal. Une autre solution consiste à générer un mot de passe à usage unique à l'aide d'un jeton tiers, comme un smartphone, en fonction de la volonté de l'organisation de ralentir le travail au nom de la sécurité.

Enfin, bien qu'il ne s'agisse pas d'une garantie absolue, de nombreux navigateurs tels que Microsoft Edge ou Google Chrome ont désormais mis en place des restrictions de politique d'origine identique afin de bloquer les requêtes provenant de toute personne autre que l'utilisateur local. En obligeant les utilisateurs à interagir avec votre site en utilisant les versions les plus récentes de ces navigateurs, vous pouvez intégrer une couche supplémentaire de sécurité CSRF sans solliciter les équipes de développement.

Fermer la porte au CSRF

Avec un tel potentiel de gain, les attaques CSRF ne disparaîtront probablement jamais complètement, mais nous espérons que vous avez appris pourquoi elles sont si persistantes et comment les bloquer de votre réseau pour de bon.

Pour en savoir plus, vous pouvez consulter l'OWASP Cross-Site Request Forgery Prevention Cheat Sheet, qui constitue un document évolutif décrivant cette vulnérabilité au fur et à mesure de son évolution. Si vous souhaitez vraiment renforcer vos connaissances en matière de sécurité, vous pouvez apprendre à déjouer cette menace et bien d'autres encore en visitant le Secure Code Warrior blog.

Vous pensez être prêt à mettre à l'épreuve vos nouvelles connaissances en matière de défense ? Essayez dès aujourd'hui la démo gratuite de la plateforme Secure Code Warrior .

Les scripts intersites (XSS) sont un fléau pour les professionnels de la sécurité depuis le début des années 2000 et, malheureusement, des décennies plus tard, ils constituent toujours l'une des menaces les plus courantes au niveau du code. Cette catégorie de vulnérabilité logicielle nous tourmente depuis bien trop longtemps, et une alerte récente de la CISA - dans le cadre de son mouvement "Secure-by-Design" - cherche à la contrecarrer une fois pour toutes. La CISA s'est donné pour mission d'éliminer les classes de vulnérabilités à l'échelle mondiale, et ce coup de projecteur sur la sécurité pilotée par les développeurs peut vraiment faire bouger les choses, mais il faudra pour cela que les entreprises intelligentes s'engagent à mettre leurs développeurs sur la voie de la réussite en matière de sécurité.

Alors, qu'est-ce que XSS exactement ?

Les navigateurs web sont peut-être notre porte d'entrée vers toutes ces choses géniales en ligne, mais malheureusement, il n'y a pas que des bonnes nouvelles. Le comportement inhérent des navigateurs web peut être un catalyseur de vulnérabilités en matière de sécurité. Les navigateurs ont commencé par faire confiance aux balises qu'ils voyaient et les exécutaient sans poser de questions. Tout va bien jusqu'à ce que cette fonctionnalité soit exploitée à des fins peu recommandables... et naturellement, les attaquants ont fini par trouver des moyens d'exploiter cette tendance à des fins malveillantes.

Le cross-site scripting utilise la confiance des navigateurs et l'ignorance des utilisateurs pour voler des données, s'emparer de comptes et défigurer des sites web ; il s'agit d'une vulnérabilité qui peut devenir très moche, très rapidement.

Voyons comment fonctionne le XSS, quels sont les dommages qu'il peut causer et comment s'en prémunir :

Comment fonctionne un XSS ?

Un XSS se produit lorsqu'une entrée non fiable (souvent des données) est affichée sur une page, mais interprétée à tort comme un code exécutable. Un attaquant peut placer un code exécutable malveillant (balises HTML, JavaScript, etc.) dans un paramètre d'entrée, qui - lorsqu'il est renvoyé au navigateur - est alors exécuté au lieu d'être affiché comme des données.

Comme indiqué ci-dessus, la vulnérabilité est apparue en raison du fonctionnement de base des navigateurs, où il est difficile de faire la distinction entre les données et le code exécutable. Le modèle de fonctionnement du web est le suivant :

1. L'utilisateur visite une page web
2. La page indique au navigateur les fichiers à charger et à exécuter
3. Le navigateur exécute ce qui se trouve sur la page, sans poser de questions.

Cette fonctionnalité est à l'origine de certaines des expériences interactives les plus impressionnantes dont nous bénéficions sur le web. Le revers de la médaille est qu'elle a également donné lieu à des exploits et à des vulnérabilités coûteux.

Lorsque les attaquants ajoutent leur script malveillant à un site vulnérable, celui-ci est exécuté sans poser de questions. Il n'y a pas d'enquête plus approfondie, ni de mesures de détection en place.

Il existe trois types de XSS :

• XSS stocké
• XSS réfléchi
• DOM XSS

On parle de XSS stocké lorsqu'un attaquant peut stocker de manière persistante le script malveillant dans un champ de données de l'application (par exemple, dans un champ qui stocke le numéro de téléphone mobile de l'utilisateur). Ce script est ensuite envoyé au navigateur de l'utilisateur chaque fois que ce champ de données est affiché dans l'application.

Ce type d'attaque est souvent observé sur les sites de forums ou les moteurs de commentaires. Un attaquant saisit le script malveillant dans un commentaire, et bam - chaque utilisateur qui consulte ce commentaire exécute le script à son insu.

LeXSS réfléchi se produit lorsque l'entrée de l'utilisateur est renvoyée telle quelle au navigateur de l'utilisateur. Un exemple est une boîte de recherche qui affiche "Vous avez cherché ..." à l'utilisateur pendant qu'il récupère les résultats de la recherche.

Imaginez maintenant que la recherche fonctionne en plaçant le terme recherché dans l'URL en tant que paramètres de requête. Un attaquant malveillant pourrait envoyer à la victime un lien contenant le script malveillant intégré dans ces mêmes paramètres et, à vrai dire, la plupart des utilisateurs du web le remarqueraient à peine.

La victime clique sur le lien et est redirigée vers un site d'hameçonnage où elle saisit involontairement son mot de passe pour le site. Elle est loin de se douter qu'un pirate vient de lui voler la clé de son compte.

DOM XSS est une variante relativement récente de cette vulnérabilité. Elle tire parti des structures de template complexes que l'on trouve dans de nombreux frameworks d'interface utilisateur tels qu'Angular et React.

Ces templates permettent d'obtenir un contenu dynamique et des applications d'interface utilisateur riches. S'ils sont mal utilisés, ils peuvent être utilisés pour exécuter des attaques XSS.

Voilà, vous l'avez. Vous avez une vue d'ensemble de la portée des XSS. Voyons maintenant comment il peut être utilisé de manière destructive.

Pourquoi les XSS sont-ils si dangereux ?

Les attaques XSS peuvent être utilisées pour rediriger les utilisateurs vers des sites malveillants, voler des cookies et rechercher des données de session. En fait, tout ce que JavaScript peut faire, les attaques XSS en sont également capables.

Voici trois exemples d'attaques XSS :

1. En 2015, les utilisateurs de Yahoo ont vu leurs cookies de session dérobés au moyen d'un XSS.
2. Le ver Samy a été distribué via une vulnérabilité XSS dans MySpace. Il reste le logiciel malveillant qui s'est propagé le plus rapidement de tous les temps, affectant un million d'utilisateurs en seulement 20 heures.
3. eBay a autorisé l'insertion de scripts malveillants dans les descriptions de produits. Cela a conduit à des attaques XSS contre les utilisateurs d'eBay.

Les attaques XSS sont faussement simples et très sérieuses. Elles peuvent conduire au vol de sessions, d'identifiants d'utilisateurs ou de données sensibles. L'atteinte à la réputation et la baisse des revenus sont les principaux écueils de ces attaques. Le simple fait de défigurer un site web peut avoir des conséquences fâcheuses pour une entreprise.

Cependant, un guerrier de la sécurité avisé comme vous peut déjouer les attaques XSS. La solution n'est pas compliquée et l'industrie a parcouru un long, très long chemin depuis que XSS est devenu un exploit couramment utilisé.

Vous pouvez vaincre les XSS.

La clé pour vaincre les XSS est de comprendre le contexte. Plus précisément, le contexte dans lequel votre entrée utilisateur sera restituée au client et l'endroit où elle sera restituée. Dans le code HTML ou dans un extrait de JavaScript.

Si la saisie de l'utilisateur n'a pas besoin d'être renvoyée au navigateur, tant mieux. Mais si c'est le cas, elle doit souvent être codée en HTML. Le codage HTML de la sortie indiquera au navigateur de rendre le contenu tel quel et de ne pas l'exécuter.

La validation des entrées est également importante. Cependant, la validation et la liste blanche ne sont pas des solutions infaillibles. Le codage va un peu plus loin et empêche les navigateurs d'exécuter un script malveillant. Tout ce qui n'est pas pris en compte par les stratégies de validation et de liste blanche sera encodé.

De nombreux frameworks encodent désormais automatiquement la sortie HTML.
Angular, ASP.NET MVC et React.js sont des frameworks dans lesquels l'encodage HTML par défaut est utilisé. Vous devez spécifiquement indiquer à ces frameworks de ne pas encoder en appelant une méthode spéciale.

La plupart des autres frameworks, (i.e. Django et Spring) ont des bibliothèques standard pour la prévention XSS que vous pouvez facilement incorporer dans votre code.

Le plus grand défi est d'apprendre à analyser toutes les façons dont l'entrée utilisateur peut pénétrer dans un système afin que vous puissiez rester à l'affût de ces entrées. Les paramètres de requête peuvent être à l'origine d'attaques, tout comme les paramètres d'affichage. Suivez le flux de données à travers votre application et ne faites confiance à aucune donnée provenant de l'extérieur.

Pensez comme une patrouille frontalière. Arrêtez chaque donnée, inspectez-la et ne l'autorisez pas à entrer si elle semble malveillante. Encodez ensuite les données lors du rendu pour vous assurer que les éléments malveillants qui ont été manqués ne causeront pas de problèmes.

Mettez en œuvre ces stratégies et vos utilisateurs seront à l'abri d'une attaque par XSS. Consultez l'aide-mémoire de l'OWASP pour obtenir d'autres conseils afin de garder vos données sous contrôle.

Déjouez les XSS et améliorez vos compétences en matière de sécurité.

Le XSS occupe la septième place dans le Top 10 2017 de l'OWASP des risques de sécurité sur le web. Il existe depuis un certain temps, mais il peut toujours apparaître et causer des problèmes avec votre application si vous ne faites pas attention.

La formation est très importante pour les développeurs, car elle leur permet d'acquérir un état d'esprit axé sur la sécurité lorsqu'ils créent du code. Et cette formation est toujours plus efficace lorsqu'elle simule des applications réelles, dans les langages que les développeurs utilisent activement. Dans cette optique, pourquoi ne pas consulter nos ressources pédagogiques pour en savoir plus sur les XSS ? Ensuite, vous pourrez commencer la formation et la pratique qui vous mèneront à la maîtrise.

Vous pensez être prêt à trouver et à corriger les vulnérabilités XSS dès maintenant ? Lancez-vous un défi sur la plateforme Secure Code Warrior .

En termes simples, SQL (ou Structured Query Language) est le langage utilisé pour communiquer avec les bases de données relationnelles ; c'est le langage de requête utilisé par les développeurs, les administrateurs de bases de données et les applications pour gérer les quantités massives de données générées chaque jour.

Nos données deviennent rapidement l'une des marchandises les plus précieuses au monde... et lorsque quelque chose a de la valeur, les malfaiteurs veulent mettre la main dessus pour en tirer profit.

Les attaquants utilisent l'injection SQL, l'une des vulnérabilités les plus anciennes(depuis 1998!) et les plus ennuyeuses, pour voler et modifier les informations sensibles disponibles dans des millions de bases de données à travers le monde. C'est insidieux, et les développeurs doivent comprendre l'injection SQL (ainsi que la manière de s'en défendre) si nous voulons garder nos données en sécurité.

À cette fin, nous allons aborder trois aspects clés de l'injection SQL :

• Comment cela fonctionne-t-il ?
• Pourquoi c'est si dangereux
• Comment s'en défendre ?

Comprendre l'injection SQL

L'injection SQL peut être comprise à l'aide d'un seul mot : le contexte.

Au sein d'une application, il existe deux contextes : l'un pour les données, l'autre pour le code. Le contexte du code indique à l'ordinateur ce qu'il doit exécuter et le sépare des données à traiter.

L'injection SQL se produit lorsqu'un attaquant saisit des données qui sont traitées par erreur comme du code par l'interpréteur SQL.

Un exemple est un champ de saisie sur un site web, où un pirate saisit "'' OR 1=1" et qui est ajouté à la fin d'une requête SQL. Lorsque cette requête est exécutée, elle renvoie "true" pour chaque ligne de la base de données. Cela signifie que tous les enregistrements de la table interrogée seront renvoyés.

Les conséquences d'une injection SQL peuvent être catastrophiques. Si elle se produit sur une page de connexion, elle peut renvoyer tous les enregistrements des utilisateurs, y compris éventuellement les noms d'utilisateur et les mots de passe. Si une simple requête visant à extraire des données est couronnée de succès, les requêtes visant à modifier les données le seront également.

Jetons un coup d'œil à un code vulnérable afin que vous puissiez voir à quoi ressemble une vulnérabilité par injection de code SQL en chair et en os.

Consultez ce code :

String query = "SELECT account balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");
try {
   Statement statement = connection.createStatement( ... );
   ResultSet results = statement.executeQuery( query );
}

Le code ici ajoute simplement les informations des paramètres du client à la fin de la requête SQL sans aucune validation. Dans ce cas, un attaquant peut saisir du code dans un champ de saisie ou dans les paramètres d'une URL et l'exécuter.

L'essentiel n'est pas que les attaquants puissent seulement ajouter ''' OR 1=1" à chaque requête SELECT, mais qu'ils puissent manipuler n'importe quel type de requête SQL (INSERT, UPDATE, DELETE, DROP, etc.) et l'étendre à tout ce que la base de données supporte. Il existe d'excellentes ressources et des outils disponibles dans le domaine public qui montrent ce qu'il est possible de faire.

Nous verrons bientôt comment remédier à ce problème. Tout d'abord, il convient de comprendre l'ampleur des dégâts.

Pourquoi l'injection SQL est-elle si dangereuse ?

Voici trois exemples de failles causées par une injection SQL :

• Le site web de la commission électorale de l'Illinois a fait l'objet d'une violation en raison de vulnérabilités liées à une injection SQL. Les attaquants ont volé les données personnelles de 200 000 citoyens américains. En raison de la nature de la vulnérabilité découverte, les attaquants auraient pu également modifier les données, mais ils ne l'ont pas fait.
• Hetzner, une société sud-africaine d'hébergement de sites web, a été victime d'une violation de 40 000 enregistrements de clients. Une faille d'injection SQL a permis le vol de tous les enregistrements de clients dans leur base de données.
• Un prestataire de services financiers catholiques du Minnesota, aux États-Unis, a été victime d'une intrusion par injection SQL. Les informations relatives aux comptes, y compris les numéros de compte, de près de 130 000 clients ont été dérobées.

Les données sensibles peuvent être utilisées pour prendre le contrôle de comptes, réinitialiser des mots de passe, voler de l'argent ou commettre des fraudes.

Même les informations qui ne sont pas considérées comme sensibles ou personnellement identifiables peuvent être utilisées pour d'autres attaques. L'adresse ou les quatre derniers chiffres de votre numéro d'identification gouvernemental peuvent être utilisés pour usurper votre identité auprès d'entreprises ou pour réinitialiser votre mot de passe.

Lorsqu'une attaque réussit, les clients peuvent perdre confiance en l'entreprise. La réparation des dommages causés aux systèmes ou des amendes réglementaires peut coûter des millions de dollars.

Mais il n'est pas nécessaire que cela se termine ainsi pour vous.

Vaincre l'injection SQL

L'injection SQL peut être évitée en étiquetant clairement les parties de votre application, de sorte que l'ordinateur sache si une partie donnée est une donnée ou un code à exécuter. Pour ce faire, vous pouvez utiliser des requêtes paramétrées.

Lorsque les requêtes SQL utilisent des paramètres, l'interpréteur SQL utilise le paramètre uniquement en tant que données. Il ne l'exécute pas en tant que code.

Par exemple, une attaque telle que "'' OR 1=1" ne fonctionnera pas. La base de données recherchera la chaîne "OR 1=1" et ne la trouvera pas dans la base de données. Elle se contentera de hausser les épaules et de dire : "Désolé, je ne peux pas trouver ça pour vous".

Voici un exemple de requête paramétrée en Java :

La plupart des cadres de développement fournissent des défenses intégrées contre l'injection SQL.

Les ORM (Object Relational Mappers), tels qu'Entity Framework dans la famille .NET, paramétrent les requêtes par défaut. Cela permet de se prémunir contre les injections SQL sans aucun effort de votre part.

Cependant, vous devez savoir comment fonctionne votre ORM spécifique. Par exemple, Hibernate, un ORM populaire dans le monde Java, peut toujours être vulnérable à l'injection SQL s'il est utilisé de manière incorrecte.

Le paramétrage des requêtes est la première et la meilleure défense, mais il en existe d'autres. Les procédures stockées prennent également en charge les paramètres SQL et peuvent être utilisées pour prévenir les injections SQL. Gardez à l'esprit que les procédures stockées doivent également être construites correctement pour que cela fonctionne.

// This should REALLY be validated too
String custname = request.getParameter("customerName");
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";

PreparedStatement pstmt = connection.preparedStatement( query );
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery( );

Validez et assainissez toujours vos entrées. Étant donné que certains caractères, tels que "OR 1=1", ne seront pas saisis par un utilisateur légitime de votre application, il n'est pas nécessaire de les autoriser. Vous pouvez afficher un message d'erreur à l'utilisateur ou les supprimer de vos entrées avant de les traiter.

Cela dit, ne comptez pas uniquement sur la validation et l'assainissement pour vous protéger. Des êtres humains astucieux ont trouvé des moyens de les contourner. Ce sont de bonnes stratégies de défense en profondeur (DiD), mais le paramétrage est le moyen le plus sûr de couvrir toutes les bases.

Une autre bonne stratégie DiD consiste à utiliser le "moindre privilège" au sein de la base de données et à établir une liste blanche des entrées. L'application du principe du moindre privilège signifie que votre application ne dispose pas d'un pouvoir illimité au sein de la base de données. Si un attaquant parvient à accéder à la base de données, les dommages qu'il peut causer sont limités.

L'OWASP dispose d'une excellente feuille de contrôle sur l'injection SQL qui montre comment gérer cette vulnérabilité dans plusieurs langues et plateformes... mais si vous voulez aller plus loin, vous pouvez dès maintenant jouer à un défi d'injection SQL dans votre langue préférée sur notre plateforme ; voici quelques-unes des plus populaires pour commencer :

Injection SQL en C#

Injection SQL dans Node.js

Injection SQL dans Python Django

Injection SQL en Java Spring

Le voyage commence

Vous avez fait de grands progrès dans la compréhension de l'injection SQL et des étapes nécessaires pour la corriger. C'est génial !

Nous avons vu comment se produit l'injection SQL, généralement lorsqu'un pirate utilise des données d'entrée pour contrôler les requêtes de votre base de données à des fins malveillantes.

Nous avons également constaté les dégâts causés par l'exploitation des failles d'injection SQL : Des comptes peuvent être compromis et des millions de dollars perdus... un cauchemar, qui plus est coûteux.

Nous avons vu comment prévenir les injections SQL :

• Paramétrage des requêtes
• Utilisation de mappeurs objet-relationnel et de procédures stockées
• Validation et inscription sur liste blanche des données saisies par les utilisateurs

Maintenant, c'est à vous de jouer. La pratique est le meilleur moyen de continuer à apprendre et d'acquérir de la maîtrise, alors pourquoi ne pas jeter un coup d'œil à nos Ressources pédagogiques sur l'injection SQL, puis essayez notre démo gratuite de la plateforme ? Vous serez sur la bonne voie pour devenir un Secure Code Warrior.

Avec l'explosion du travail à distance en 2020, la poursuite des violations de données à grande échelle et l'attention croissante portée aux conséquences d'une atteinte à la vie privée en ligne, la cybersécurité n'a jamais fait l'objet d'autant d'attention de la part du public. En conséquence, les gouvernements du monde entier sont intervenus pour remodeler et mettre à jour leurs plans et infrastructures de cybersécurité, y compris les stratégies et réglementations que les entreprises sont tenues de respecter lorsqu'elles manipulent nos ressources numériques les plus précieuses.

Les lignes directrices en matière de protection stratégique de la cybersécurité ne sont pas un concept nouveau, et des organisations telles que le NIST alimentent les politiques des ministères mondiaux depuis de nombreuses années. Le progrès numérique s'étant accéléré, il est devenu difficile pour beaucoup de suivre le rythme des menaces, des vecteurs d'attaque possibles et des exigences de conformité qui font partie d'un paysage en constante évolution.

La récente violation de 54 000 permis de conduire de la Nouvelle-Galles du Sud, due à un cache S3 mal configuré et facilement accessible sur un serveur tiers, a compromis des milliers de personnes, et le chercheur en sécurité qui l'a signalée a admis que les données avaient peut-être déjà été vendues sur le dark web. Ce qui est triste, c'est qu'il s'agit d'un problème facile à résoudre et qu'il aurait été peu probable qu'il se produise si les personnes chargées de configurer le cache avaient eu la sécurité à l'esprit.

Le gouvernement australien a récemment publié l'Australian Cyber Security Strategy 2020, qui met en avant de nouvelles initiatives et un financement de 1,67 milliard de dollars à utiliser au cours de la prochaine décennie, afin de réaliser sa "vision de la création d'un monde en ligne plus sûr pour les Australiens, leurs entreprises et les services essentiels dont nous dépendons tous". Il s'agit clairement d'une révision et d'un plan actualisé très bienvenus, d'autant plus que l'un des principaux objectifs est le suivant :

"Action des entreprises pour sécuriser leurs produits et services et protéger leurs clients des cyber-vulnérabilités connues".

Alors que les organismes gouvernementaux ont tendance à se concentrer (comme il se doit) sur les mesures de sécurité concernant les infrastructures critiques d'un pays - des domaines qui sont mûrs pour une attaque organisée catastrophique - ce qui manquait dans le passé, c'était des lignes directrices pour les entreprises qui collectent et utilisent nos données tous les jours.

Lorsqu'il s'agit d'une stratégie officielle comme celle-ci, ce n'est pas toujours de la bière et des Skittles. Elle peut être un peu difficile à interpréter et vague dans ses détails, laissant à l'équipe de sécurité d'une organisation le soin de mettre au point un plan basé sur des directives non spécifiques. Ce problème n'est pas propre au gouvernement australien, mais analysons sa toute nouvelle version.

L'accent est mis sur la réaction et non sur la prévention.

La stratégie australienne de cybersécurité mise à jour est plus pertinente que la dernière version de 2016, avec des plans assez complets pour les entreprises, en particulier les PME. La stratégie présente les grandes lignes :

"Le gouvernement et les grandes entreprises aideront les petites et moyennes entreprises (PME) à se développer et à accroître leur sensibilisation et leurs capacités en matière de cybersécurité. Le gouvernement australien collaborera avec les grandes entreprises et les prestataires de services pour fournir aux PME des informations et des outils de cybersécurité dans le cadre de "paquets" de services sécurisés (tels que le blocage des menaces, les antivirus et la formation à la sensibilisation à la cybersécurité)".

Les PME disposeront ainsi d'une base décente pour protéger leur entreprise contre les cybermenaces, mais il s 'agit essentiellement d'une approche réactive et l'accent est mis sur les outils de détection, qui ne représentent qu'une partie relativement modeste du paysage de la cybersécurité.

Il y a aussi étonnamment peu d'informations sur la façon dont les grandes entreprises peuvent se protéger et réduire leurs vecteurs d'attaque. Si beaucoup d'entre elles peuvent faire partie des plans de protection des infrastructures critiques (telles que les télécommunications et les transports), les services financiers, le commerce de détail et bien d'autres secteurs verticaux ont beaucoup à perdre en cas de cyberattaque réussie. Peut-être cela fera-t-il partie de la législation à venir, mais quoi qu'il en soit, il est essentiel de souligner l'importance de pratiques exemplaires méticuleuses en matière de cybersécurité au niveau de l'entreprise pour voir des changements significatifs et une baisse des données compromises et de la cybercriminalité.

D'une manière générale, si l'on considère la stratégie dans son ensemble, elle s'articule autour d'une approche réactive. Contrer les cyberattaques, perturber les cybercriminels actifs et veiller à ce qu'ils soient poursuivis, ainsi que l'échange de renseignements avec les alliés internationaux, sont tous des facteurs importants, mais imaginez si la norme de protection à l'échelle nationale était axée sur la prévention. Outre les mesures de protection des infrastructures critiques, si la sécurité était au cœur des préoccupations de chaque entreprise et si chaque personne touchant au code qui crée notre monde numérique était correctement équipée pour bloquer les attaques avant qu'elles ne se produisent, les économies de temps, d'argent et de chagrin d'amour pour les victimes seraient incommensurables.

La résilience est possible, mais elle doit être planifiée.

Les efforts déployés par le gouvernement australien pour s'attaquer sérieusement à la cybersécurité montrent clairement qu'il s'agit d'un domaine de risque clé au niveau national. Comme pour toute autre attaque malveillante susceptible de perturber notre mode de vie, la résilience est absolument cruciale, non seulement pour résister à une telle tentative, mais aussi pour la dissuader de se produire. En fin de compte, même les acteurs de la menace peuvent être paresseux, et ils se déplaceront vers une cible plus facile pour atteindre leur objectif si trop d'obstacles se dressent sur leur chemin.

À l'heure actuelle, nous sommes confrontés à une pénurie mondiale de compétences en cybersécurité, ce qui empêche les RSSI du monde entier de dormir. Des milliards de lignes de code, des violations constantes de données à grande échelle et plus de risques de sanctions (Marriott a reçu à lui seul une amende de 123 millions de dollars US au titre du GDPR pour sa violation de données en 2018... et il y a eu une autre violation cette année) que jamais auparavant ont créé un gouffre pour les spécialistes de la sécurité qui, de manière réaliste, n'est pas près d'être comblé. Il y a tout simplement trop de code et trop peu de ressources pour s'assurer qu'il est fortifié sous tous les angles.

Devons-nous donc renoncer à l'idée que nous pourrons un jour nous affirmer face aux cybermenaces ? Il n'en est rien. La résilience exige d'utiliser toutes les ressources disponibles et d'avoir une longueur d'avance. Et pour de nombreuses entreprises, leurs développeurs peuvent débloquer une puissante méthode de fortification dès l'écriture du code. Associée à une culture de la sécurité visible et positive dans l'ensemble de l'entreprise, cette méthode constitue une base de sécurité difficile à ébranler et à briser pour de nombreux attaquants. Toutefois, cette méthode nécessite de prendre les suggestions de la stratégie australienne de cybersécurité, à titre d'exemple, et d'approfondir la façon dont elles peuvent être personnalisées pour soutenir un changement efficace et pertinent pour l'entreprise.

À cette fin, il est important de détailler quelques conseils :

• Formation à la sensibilisation à la sécurité : Cette formation est spécifiquement destinée aux PME et, dans le contexte de l'ensemble du rapport, elle vise principalement à enseigner à l'ensemble du personnel les règles d'hygiène de base en matière de sécurité (par exemple, repérer les courriels d'hameçonnage, ne pas cliquer sur des liens inconnus, etc.) ). En réalité, la formation doit aller beaucoup plus loin et devenir spécifique à chaque rôle, en particulier pour ceux qui touchent au code, comme les développeurs. Il est impératif que la formation à la sensibilisation à la sécurité fasse partie intégrante des mesures préventives et du renforcement de la résilience.
• L'éducation : Dans un changement rafraîchissant, il existe un plan approfondi pour remédier à la pénurie de compétences en cybersécurité au cours de la prochaine décennie, en mettant l'accent sur la formation à la cybersécurité depuis l'école primaire et secondaire jusqu'à l'enseignement supérieur. Cette formation est indispensable si nous voulons former les superstars de la sécurité de demain, mais si l'on veut répondre dès maintenant aux besoins des entreprises, une formation pratique au codage sécurisé pour la cohorte de développement est absolument nécessaire pour commencer à réduire les vulnérabilités courantes et doit faire partie d'un programme de sécurité fonctionnel.

En tant qu'experts en sécurité, nous devons faire davantage pour aider les entreprises du monde entier à comprendre l'importance de la mise en place d'un programme de sécurité interne qui va au-delà des simples mesures de sensibilisation. Consacrer du temps à la formation des développeurs permet de soulager les spécialistes de l'AppSec surchargés de travail, et s'assurer que l'ensemble de l'organisation est aussi sensibilisée à la sécurité que possible dans le contexte de son rôle est essentiel pour réduire la surface d'attaque des logiciels.

Le perfectionnement des développeurs est un temps bien employé, alors pourquoi tant d'entreprises l'ignorent-elles ?

Une récente enquête menée par DDLS a conclu que les organisations australiennes n'accordent que très peu d'importance à la formation à la cybersécurité. En fait, la cybersécurité ne figure même pas parmi les trois premières priorités de formation, bien que 77 % des personnes interrogées considèrent que la sensibilisation à la cybersécurité est "extrêmement" ou "très importante" pour leur entreprise.

Il n'est donc pas étonnant que l'Australie s'efforce de combler le déficit croissant de compétences et qu'elle ait du travail à faire pour créer une infrastructure plus résistante, des services essentiels au commerce de détail, et tout ce qui se trouve entre les deux.

Les gouvernements ont ici une opportunité énorme de créer une certification ou une réglementation de base des compétences en matière de sécurité, et la stratégie y fait allusion comme un moyen de travailler avec des ressources limitées. Cependant, une fois de plus, il semble s'agir d'une proposition d'avenir, et nous disposons des outils nécessaires pour commencer bien plus tôt si nous ciblons d'abord les domaines à fort impact. Pour moi, la lueur d'espoir réside dans les équipes de développement au sein de chaque organisation, et si on leur donne les outils et les connaissances nécessaires pour réussir, elles peuvent couper court aux vulnérabilités courantes et réduire de manière significative le risque d'une violation de données au sein de leur organisation.

En 2019, 24 % de toutes les violations de données ont été causées par une erreur humaine - à savoir des erreurs de configuration de la sécurité - qui sont généralement des corrections relativement simples au niveau du code. Si la formation devient une priorité, en conjonction avec la sensibilisation à la sécurité à l'échelle de l'entreprise, je parie qu'il y aura moins de RSSI qui signeront des notifications de violation de données à des milliers de clients compromis.

Le 23 juin est une date spéciale dans le calendrier des geeks, puisqu'elle marque la Journée internationale des femmes ingénieurs. Bien que nous devions toujours célébrer les réalisations de nos pairs et de nos équipes tout au long de l'année, c'est l'occasion de mettre en lumière non seulement la contribution des femmes au développement de logiciels en général, mais aussi leur impact positif sur Secure Code Warrior. Nous avons la chance d'avoir une quasi-parité entre les hommes et les femmes dans notre organisation et, au sein de celle-ci, quelques femmes talentueuses dans notre équipe d'ingénieurs.

Il ne m'a certainement pas échappé que les carrières dans les STIM sont notoirement dominées par les hommes, et pour les développeuses, je sais de première main que certains environnements technologiques peuvent être difficiles et injustement empilés contre les femmes, principalement en raison de préjugés inconscients. Ce n'est pas suffisant, et il était important pour moi de veiller à ce que tout le monde soit traité équitablement, que la diversité soit défendue et que les équipes se sentent enrichies par des opinions, des expériences et des modes de pensée différents. Après tout, aucune entreprise ne devrait exister dans une chambre d'écho et espérer prospérer. C'est l'amplification des voix les moins entendues qui peut conduire à des choses incroyables.

Cette semaine, j'ai voulu mettre en lumière les contributions des femmes qui apportent tant à nos activités d'ingénierie et qui montrent continuellement l'exemple grâce à leur travail vraiment impressionnant. Poursuivez votre lecture pour découvrir quelques-unes de nos superstars de la technologie :

Julia Semeniuk, Scrum Master

Qu'est-ce qui vous plaît dans le processus de développement de logiciels ?
J'aime les résultats. Je pense qu'il s'agit d'une partie très importante de l'activité : à la fin de la journée, le développement de logiciels rassemble toutes les idées, tous les commentaires et toutes les conceptions et les met à la disposition des autres parties de l'entreprise et de nos clients.

Quels sont les défis auxquels vous êtes confronté dans votre rôle ?
Jepense que le plus grand défi est celui de la communication et de l'alignement. Nous devons nous assurer que nous travaillons sur l'élément le plus important à tout moment. C'est pourquoi il est si important pour nous de travailler avec les équipes de produits, d'assistance et autres.

Qu'est-ce qui vous plaît le plus dans votre fonction ?
J'aime l'esprit et le travail d'équipe. Tout ce que nous faisons est le fruit d'un travail synchronisé et d'une collaboration. Et voir la progression de notre travail et l'épanouissement des personnes me rend heureuse chaque jour.

Quelles initiatives prenez-vous pour soutenir les femmes dans votre équipe ?
Nous avons la chance d'être traitées sur un pied d'égalité sur le site Secure Code Warrior. Je ne pense pas que nous ayons des initiatives destinées exclusivement aux femmes, nous nous soutenons et nous nous respectons mutuellement, quels que soient notre sexe et notre genre. Cela dit, les initiatives de l'entreprise telles que le congé parental et les modalités de travail flexibles font une énorme différence pour chacun d'entre nous.

Noemi Alvarez, développeur logiciel senior

Rôle à l'adresse Secure Code Warrior:
Ingénieur logiciel senior

Langages/frameworks préférés :
Typescript /Javascript - Angular/Node parce que j'ai le plus d'expérience avec eux et je me sens plus à l'aise.

Langages/frameworks les moins appréciés :
Java / PHP car je n'ai pas eu l'occasion de travailler avec eux.

Comment êtes-vous arrivé au développement de logiciels ?
J'ai fait des recherches sur les carrières en vogue et l'informatique en faisait partie. Mon professeur de mathématiques préféré m'a dit que je serais un excellent ingénieur.

Quels sont les défis auxquels vous êtes confronté(e) dans le cadre de vos fonctions ?
Se tenir au courant des nouvelles technologies et tendances.

Qu'est-ce qui vous plaît le plus dans votre fonction ?
En général, construire/créer quelque chose et voir les gens l'utiliser. Au SCW, j'ai le défi de le rendre aussi sûr que possible.

Laura Verheyde, Ingénieur logiciel senior

Rôle à l'adresse Secure Code Warrior:
Développeur dans l'équipe ACE. En gros, je contribue à fournir de nouveaux défis à la plateforme.

Langages/frameworks préférés :
C#, .NET.

Langages/frameworks les moins appréciés :
Probablement PHP, mais c'est surtout par manque d'expérience.

Comment êtes-vous arrivé au développement de logiciels ?
Il y a des années, mes meilleurs amis étudiaient tous l'informatique, ce qui a éveillé mon intérêt.

Quels sont les défis auxquels vous êtes confronté dans votre rôle ?
Naviguer et comprendre le code de quelqu'un d'autre afin d'ajouter le mien peut être une tâche assez exigeante. En outre, l'idée qu'il y a encore tant à apprendre dans le domaine de l'informatique peut parfois être intimidante, mais aussi très gratifiante une fois que vous avez surmonté un certain défi.

Qu'est-ce qui vous plaît le plus dans votre fonction ?
Une partie de mon travail consiste à étudier le code au niveau syntaxique, ce que je trouve très intéressant. Par ailleurs, le fait de voir les applications auxquelles j'ai contribué, produire des résultats et créer de nouveaux contenus pour la plateforme SCW me procure un sentiment très satisfaisant.

Avez-vous des conseils à donner aux jeunes femmes qui envisagent une carrière similaire ?
Oui, ne soyez pas intimidées par l'idée de devoir travailler dans un milieu dominé par les hommes. Mon inquiétude initiale s'est dissipée assez rapidement au cours de mes premiers jours, car j'ai été présentée aux collègues les plus gentils et les plus accueillants que l'on puisse espérer. Je suis presque sûre que c'est le cas dans la plupart des lieux de travail.

Josh Graham, notre vice-président chargé de la technologie, est en train de mettre au point un programme de mentorat pour encourager davantage de femmes à rejoindre notre cohorte d'ingénieurs. Notre objectif est de leur donner des opportunités et des voies pour développer leur carrière, tout en étant guidées par des modèles qui peuvent leur montrer ce qui est possible dans le développement de logiciels, la cybersécurité et la technologie. Il est essentiel pour les jeunes femmes de voir quelqu'un à qui elles peuvent s'identifier dans un rôle ambitieux, afin de se rendre compte que leurs rêves ne sont pas seulement importants, mais qu'ils sont à portée de main.

En tant que secteur et en tant qu'entreprise, nous avons encore du travail à faire pour parvenir à une véritable égalité entre les femmes et les hommes dans les carrières technologiques. Nous travaillons d'arrache-pied pour encourager davantage de femmes à occuper des postes ouverts ; leurs contributions ne feront que nous propulser vers l'avant et nous aideront à montrer l'exemple. Il est temps de reconnaître les préjugés, les privilèges et les plafonds de verre, tout en s'efforçant de changer sérieusement le statu quo.

Nous nous efforçons de créer un environnement sûr et favorable pour les geeks de tous horizons. Nous soutenons les femmes dans la technologie, en offrant une flexibilité de travail et des politiques parentales/familiales généreuses dans un environnement mondial. Vous souhaitez nous rejoindre ? Gardez notre page Carrières et LinkedIn en signet pour votre prochaine opportunité - nous avons toujours des postes d'ingénieurs pour des technologues passionnés qui cherchent à s'épanouir dans un lieu de travail où vous pouvez vous présenter tel que vous êtes.

Une version de cet article a été publiée dans DevOps Digest. Elle a été mise à jour et publiée ici.

À ce stade, je suis sûr que nous sommes tous un peu fatigués de l'expression "en ces temps sans précédent"... mais nous vivons vraiment des temps sans précédent. Qui aurait pensé, à la fin de l'année dernière, que nous serions en train de courir pour vaincre une pandémie destructrice à l'échelle mondiale cette année, et que nous ferions tout ce qui est en notre pouvoir pour y parvenir ? Cela aurait semblé presque risible et relever davantage d'une nouvelle série de science-fiction de Netflix que de notre réalité mondiale. Le COVID-19 a complètement transformé notre vie sociale, notre économie et notre sécurité d'emploi, sans parler des priorités politiques.

L'une des contre-attaques contre le COVID-19 a été la technologie, de nombreux pays ayant mis en place des applications de recherche de contacts. L'Australie dispose de l'application COVIDSafe, inspirée de l'application TraceTogether de Singapour. Hong Kong, Taïwan, la Chine, la Corée du Sud, Israël et l'Allemagne ont tous mis en place une technologie de recherche des contacts ou sont sur le point de le faire. Le Royaume-Uni a été la région la plus durement touchée en Europe, avec des dizaines de milliers de décès liés au virus et un taux d'infection élevé. Le lancement de leur application est imminent. Les États-Unis, également très touchés par la perte tragique de nombreuses personnes, ont également mis en place une technologie, mais leur approche de la recherche des contacts, État par État, rend leur situation assez complexe.

À l'exception des pays les plus contrôlés par l'État, comme la Chine et Taïwan, l'utilisation de ces applications est volontaire, les citoyens devant télécharger et utiliser la technologie de leur propre chef. Certains taux d'adoption sont plus satisfaisants que d'autres ; par exemple, l'application TraceTogether de Singapour a eu un taux d'adoption de 25 %, ce qui l'a rendue tout à fait inefficace par rapport à l'objectif recherché.

L'idée qui sous-tend les applications de recherche de contacts est judicieuse. Cette technologie, lorsqu'elle fonctionne bien, permettrait de révéler rapidement les points chauds et d'effectuer des tests complets, deux éléments essentiels pour lutter contre la propagation d'un virus contagieux. Cependant, les mots "gouvernement" et "traçage" ne sont pas très engageants, et il est naturel que les gens soient prudents quant à ce que le téléchargement d'une telle application signifierait pour eux.

Quelles sont donc les principales préoccupations des utilisateurs ? Si l'on en croit les commentaires en ligne, ces inquiétudes portent notamment sur les points suivants :

• Manque de confiance dans le gouvernement pour utiliser les données collectées de manière responsable
• Appréhension quant à la protection des données personnelles contre les cyberattaques
• Manque de clarté quant aux données réellement collectées, à l'endroit où elles sont stockées et à leurs destinataires.
• ... et pour les développeurs/geeks parmi nous, la solidité des applications.

C'est toujours un peu inquiétant lorsque les applications sont créées rapidement, et ces applications de recherche de contacts doivent être déployées en un temps record. C'est un cauchemar pour les développeurs, les responsables de la sécurité et les agences gouvernementales.

La méfiance est-elle donc une réaction valable ? Et que devrions-nous considérer comme une priorité dans notre assessment des applications de recherche de contacts COVID-19 et de la sécurité de l'utilisateur final ? En tant que spécialiste de la sécurité, mon instinct me pousse bien sûr à me pencher sur les éléments de cybersécurité du programme, à savoir la sécurité de la base de code d'une application que l'on nous pousse tous (avec les meilleures intentions du monde) à installer.

De nombreuses applications sont des copies les unes des autres (et héritent des mêmes problèmes).

L'application australienne COVIDSafe est essentiellement basée sur OpenTrace, tout comme le logiciel TraceTogether de Singapour. Le problème, cependant, est que TraceTogether a connu une série de problèmes signalés et un faible taux d'adoption, avec seulement 25 % de la population qui a choisi d'utiliser le logiciel - bien loin des 75 % requis pour qu'il soit efficace. Des plaintes ont été formulées concernant ses performances générales, en particulier sur iOS, notamment en ce qui concerne l'épuisement très rapide des batteries. COVIDSafe présente une faille potentielle dans sa version iOS: le téléphone doit être déverrouillé et l'application doit tourner au premier plan pour enregistrer correctement toutes les données.

Bien que ces problèmes soient ennuyeux, le problème le plus urgent est que les vulnérabilités Bluetooth sont nombreuses et que ni TraceTogether, ni l'application australienne COVIDSafe ne sont à l'abri de ces vulnérabilités. Le 14 mai, le NIST a signalé que COVIDSafe présentait une vulnérabilité de déni de service, permettant à un attaquant de planter l'application à distance s'il se trouve à distance de la poignée de main Bluetooth. Cela permettrait à une attaque organisée de perturber la recherche de contacts dans les zones densément peuplées, là où elle est la plus utile - ce qu'explique en détail le chercheur en sécurité Richard Nelson. On sait que COVIDSafe, TraceTogether, ProteGO (Pologne) et ABTraceTogether (Canada) sont concernés par ce problème, qui découle de l'appel manuData.subdata défectueux d'OpenTrace.

Il existe également d'autres problèmes de confidentialité et de sécurité liés à la fonctionnalité Bluetooth en général. Le fait que cette technologie soit utilisée pour suivre les mouvements humains au moyen d'un identifiant unique (TempID) et pour collecter des données significatives suscitera inévitablement un regain d'intérêt de la part des attaquants qui testeront les faiblesses de cette technologie, et il faudra alors examiner de près ce qui est collecté, où cela est stocké et pendant combien de temps.

Certaines applications montrent déjà des signes d'erreurs simples qui entraînent des faiblesses complexes.

L'ingénieur logiciel australien Geoffrey Huntley a étudié le code source de COVIDSafe et, malheureusement, il y a des problèmes qui ne sont pas nécessairement mis en évidence pour nous, les utilisateurs finaux.

Un exemple critique était une erreur de logique portant atteinte à la vie privée, qui permettait à un pirate d'effectuer un suivi à long terme des appareils, ce qui représente un risque énorme pour les utilisateurs vulnérables, sans parler du fait que cela contrevient à la politique de protection de la vie privée de l'application elle-même.

Il est important de noter que ces vulnérabilités logiques ont été corrigées le 14 mai, mais le problème le plus urgent est que ces vulnérabilités n'ont pas été corrigées, dans la nature, pendant 17 jours après que M. Huntley les ait signalées. Ce dernier et d'autres membres de la communauté de sécurité awesome suivent les CVEs relatifs à l'application COVIDSafe ici.

Une chose que Huntley souligne, après le correctif, c'est que même le correctif montre des signes d'incompétence. Dans son journal public, il note que le correctif impliquait l'ajout d'une logique plutôt que la simple suppression d'un cache défectueux, cette dernière solution étant beaucoup plus robuste. Les deux fonctionnent, mais la solution en direct manque de finesse, ce qui est préoccupant pour une application aussi importante.

Bien que des membres diligents de la société consacrent leur temps et leur expertise à examiner le code source et à mettre en évidence les problèmes, leur travail est beaucoup plus difficile que si le code était ouvert dès le départ. À l'heure actuelle, 28 applications sont toujours inaccessibles aux chercheurs en sécurité.

Le codage sécurisé continue de nous faire trébucher sur la ligne d'arrivée.

Bien que je puisse certainement compatir avec les développeurs surchargés de travail - ainsi qu'avec la situation très inhabituelle de devoir produire une application vitale au milieu d'une pandémie - ce qui précède devrait souligner que quelques simples vulnérabilités dans ce qui est essentiellement une base de code commune pourraient entraîner des problèmes importants pour des millions d'utilisateurs.

J'aime à penser que la plupart des gens veulent être de bons citoyens, soutenir l'application et donner à chacun les meilleures chances possibles de retrouver les contacts et de contrôler les épidémies de ce terrible virus. Je soutiens moi aussi la technologie qui peut aider à atteindre cet objectif, mais à bien des égards, cette affaire a mis en lumière le manque général de principes de codage sécurisés inhérents aux développeurs du monde entier.

Dans toute situation où un logiciel doit être écrit rapidement, les erreurs ne sont pas vraiment inattendues. Toutefois, les failles de sécurité courantes telles que les défauts de logique, les mauvaises configurations et les erreurs d'injection de code devraient pouvoir être évitées au moment de l'écriture du code, et non après que des "chapeaux blancs" bénévoles ont décortiqué la base de code.

Et ce n'est pas la faute des développeurs, d'ailleurs. Ils sortent de l'enseignement supérieur avec peu de compétences en matière de codage sécurisé et, au cours de leur carrière, leurs indicateurs clés de performance sont presque toujours liés à la fonctionnalité et à la rapidité de livraison - la partie sécurité est réservée à quelqu'un d'autre une fois qu'ils ont terminé. Nous devons parvenir rapidement à un état final de codage sécurisé, et même si ce n'est pas le moment de procéder à des changements culturels radicaux dans les services qui créent ces applications, il est opportun de rappeler que notre zone de risque numérique s'étend, et qu'ils sont en pole position pour faire la différence si on leur donne les outils et les connaissances nécessaires pour partager la responsabilité des meilleures pratiques en matière de sécurité.

Le téléchargement de l'application est-il sûr ?

Voici ce qu'il en est : en tant que spécialiste de la sécurité, je suis arrivé à la conclusion que les avantages de l'application l'emportent sur les problèmes. Il n'est pas idéal que les vulnérabilités susmentionnées soient - ou aient été - présentes dans ce logiciel, mais les implications de leur utilisation à des fins militaires relèvent du pire des scénarios. À l'heure actuelle, la recherche des contacts est un élément essentiel pour aider nos héros médicaux du monde entier à contrôler la propagation, à endiguer le flux des admissions à l'hôpital et à se protéger les uns les autres autant que possible.

Cela montre qu'il reste encore beaucoup à faire pour que les meilleures pratiques en matière de sécurité soient intégrées par défaut dans les logiciels, et il est important que le public dispose des informations nécessaires pour prendre des décisions en connaissance de cause.

Ma famille et moi-même continuerons à l'utiliser, même si nous restons vigilants quant à la mise à jour de nos correctifs Android, comme nous devrions tous le faire.

Une version de cet article a été publiée dans Cyber Defense Magazine. Elle a été mise à jour pour être publiée ici.

Les cyberattaques sont devenues un mode de vie de nos jours. Les gens s'attendent presque à entendre parler d'une nouvelle vulnérabilité ou d'une nouvelle brèche qui affecte tout, des banques à l'aviation, ou des dispositifs aussi divers que les smartphones et les feux de circulation. Même nos maisons ne sont plus totalement sûres. Des villes entières sont attaquées presque quotidiennement par des criminels qui réclament des millions de dollars de rançon pour rétablir les services essentiels compromis.

Mais il y a un endroit où l'on peut espérer se sentir encore en sécurité, c'est le cabinet du médecin ou même l'hôpital. C'est lorsqu'ils s'adressent à un prestataire de soins de santé que les gens sont le plus vulnérables. La décence humaine exigerait presque que les cliniciens locaux soient autorisés à faire leur noble travail en toute tranquillité. Malheureusement, ce n'est pas le cas. Il semble que les cyber-voleurs d'aujourd'hui aient peu d'honneur, ou peut-être même qu'ils soient purement et simplement désespérés. En fait, les soins de santé pourraient être le prochain "grand" champ de bataille de la cybersécurité, les criminels s'attaquant aux machines mêmes qui diagnostiquent les problèmes médicaux, fournissent des traitements et maintiennent la vie. Face à la crise sanitaire mondiale qui se déroule sous nos yeux, il est essentiel de s'attaquer à ce problème à plusieurs niveaux.

Les menaces deviennent plus personnelles que jamais.

Les attaques contre le secteur de la santé ne sont pas nouvelles. Les cybercriminels connaissent déjà la valeur des informations sur les patients, des données personnelles et des dossiers financiers dans le monde interlope et sur le dark web. Ces informations peuvent être utilisées pour voler de l'argent directement aux patients ou comme point de départ d'attaques secondaires telles que le phishing et d'autres escroqueries. Il n'est donc pas étonnant que les attaques les plus dévastatrices aient récemment visé le secteur de la santé. Anthem Healthcare s'est fait voler 80 millions de dossiers de patients. Premera a perdu 11 millions de dossiers personnels. CareFirst a perdu 1,1 million de dossiers, et la liste est encore longue.

À l'heure actuelle, les attaques menées directement contre des dispositifs médicaux semblent rares. Cependant, au moins un rapport suggère que le problème pourrait être beaucoup plus répandu, les hôpitaux ne signalant pas les intrusions, ou les employés non formés à la cybersécurité ne reconnaissant tout simplement pas qu'une attaque est en train de se dérouler sous leurs yeux. Les chercheurs en sécurité ont démontré de manière concluante qu'il était possible de compromettre les dispositifs médicaux de manière effrayante, par exemple en utilisant des logiciels malveillants pour ajouter de fausses tumeurs aux résultats des examens de tomodensitométrie et d'IRM. Il n'est pas très difficile de penser que les attaquants peuvent déjà faire la même chose ou des choses similaires avec des appareils médicaux dans le monde réel.

Les soins de santé sont également particulièrement vulnérables aux cyberattaques en raison de leur dépendance croissante à l'égard des dispositifs de l'internet des objets (IdO), de minuscules capteurs connectés à l'internet et produisant d'incroyables volumes d'informations. La plupart du temps, la sécurisation des informations produites par ces capteurs, des canaux qu'ils utilisent pour communiquer, voire des capteurs eux-mêmes, n'a guère été envisagée qu'après coup. Le nombre de vulnérabilités potentielles qu'un attaquant pourrait exploiter en se cachant dans ces réseaux dominés par l'IdO est probablement presque illimité.

L'IdO dans les soins de santé présente des risques importants.

Les services essentiels aux soins des patients, qui dans certains cas n'étaient même pas imaginés il y a 20 ans, sont des terrains propices aux vulnérabilités liées à l'IdO et à d'autres vulnérabilités plus traditionnelles. Les dossiers médicaux électroniques, la télémédecine et la santé mobile semblaient tous attendre l'afflux d'informations que l'IdO pouvait fournir. Il n'est donc pas étonnant que l'engagement en faveur de l'IdO dans le secteur des soins de santé soit stupéfiant. MarketResearch.com prévoit que d'ici l'année prochaine, le marché de l'IdO dans le secteur des soins de santé atteindra 117 milliards de dollars, et qu'il continuera à se développer à un taux de 15 % chaque année par la suite.

Dans cet environnement, les attaquants compétents peuvent trouver de nombreuses vulnérabilités qui peuvent être utilisées pour exploiter les dispositifs médicaux. Les capteurs IoT intégrés dans les dispositifs médicaux communiquent et produisent généralement leurs données de deux manières. Certains recueillent des données et transmettent ensuite tous leurs résultats directement sur l'internet pour analyse. D'autres utilisent une forme de réseau distribué connue sous le nom de " fog computing ", où les capteurs eux-mêmes forment une sorte de mini-réseau, décidant collectivement des données à partager avec un référentiel ou une plateforme centrale. Ces données peuvent ensuite être traitées ou consultées directement par le personnel soignant.

Les questions de cybersécurité dans le secteur des soins de santé sont d'autant plus compliquées que ce secteur n'a jamais adopté de normes, de méthodes ou de protections en matière de traitement des données, ni ne s'est mis d'accord à ce sujet. Historiquement, le secteur de la santé a été desservi par des fabricants qui proposaient leurs propres technologies propriétaires pour les dispositifs médicaux. Aujourd'hui, cela inclut les capteurs IoT intégrés, les canaux de communication utilisés par les appareils et la plateforme d'analyse des données après leur collecte. Cela fait de la plupart des réseaux hospitaliers un rêve pour les pirates informatiques, ou du moins un excellent terrain d'essai où ils peuvent tout exploiter, des mauvaises configurations de sécurité à une protection insuffisante de la couche de transport. Ils peuvent tout essayer, de la falsification des requêtes intersites aux attaques classiques par injection de XML.

Le contre-pied dont nous avons besoin se trouve juste devant nous.

Malgré les conséquences potentiellement catastrophiques de l'exploitation de ces vulnérabilités, il y a lieu de rester optimiste : ces bogues de sécurité ne sont pas de nouvelles portes dérobées puissantes ouvertes par des cerveaux criminels. Ils sont si courants qu'il est frustrant de les voir apparaître encore et encore. Ils sont en partie dus à l'utilisation d'anciens systèmes qui n'ont pas été corrigés malgré la disponibilité de correctifs, mais l'autre raison est une fois de plus liée au facteur humain. Les développeurs écrivent du code à un rythme effréné et se concentrent sur un produit final lisse et fonctionnel... et non sur les meilleures pratiques en matière de sécurité.

Il y a tout simplement trop de logiciels construits pour que les spécialistes de l'AppSec puissent suivre, et nous ne pouvons pas attendre d'eux qu'ils sauvent constamment la situation avec ces vulnérabilités récurrentes. Il est moins coûteux, plus efficace et clairement plus sûr de ne pas introduire ces vulnérabilités en premier lieu, ce qui signifie que les équipes de sécurité et les développeurs doivent faire un effort supplémentaire pour créer une culture de la sécurité robuste et de bout en bout.

À quoi ressemble exactement une grande culture de la sécurité ? Voici quelques éléments clés :

• Les développeurs disposent des outils et de la formation nécessaires pour éliminer les bogues courants (et comprennent pourquoi il est si important de le faire).
• La formation est complète, facile à assimiler et s'appuie sur les points forts du développeur.
• Les résultats de la formation sont correctement mesurés, à l'aide d'indicateurs et de rapports (il ne s'agit pas simplement de cocher une case et de passer à autre chose).
• L'AppSec et les développeurs commencent à parler le même langage : après tout, dans une culture de sécurité positive, ils travaillent pour atteindre des objectifs similaires.

Le risque de catastrophe reste énorme et va bien au-delà du simple vol du dossier médical d'un patient. L'injection de fausses tumeurs dans un scanner pourrait avoir un effet dévastateur sur une personne qui attend avec impatience de savoir si elle a un cancer. L'échange de médicaments ou la modification des plans de traitement pourrait même entraîner la mort du patient. Mais il suffit qu'un cybercriminel soit prêt à franchir cette limite pour faire du profit, et vous pouvez être sûr que cela se produira. Peut-être que le prochain ransomware ne cryptera pas les données d'un hôpital, mais qu'il ruinera les diagnostics de milliers de patients. Ou peut-être qu'un attaquant menacera de modifier des médicaments s'il n'est pas payé, mettant littéralement des vies en rançon.

Il est clair que nous ne pouvons plus suivre l'approche habituelle en matière de cybersécurité dans les soins de santé. Nous ne pouvons pas compter sur un ou deux spécialistes au sein des organismes de santé pour résoudre tous les problèmes. Au contraire, nous avons besoin de développeurs sensibilisés à la sécurité qui travaillent sur des applications et des dispositifs de santé afin de reconnaître les problèmes potentiels et de les résoudre avant qu'ils ne soient déployés dans les établissements. Et même le personnel de santé pourrait bénéficier d'une formation de base à la cybersécurité.

Il est vrai que rien n'est plus important que votre santé. Dans le secteur des soins de santé, le maintien d'une bonne cybersécurité pour l'avenir dépendra de l'amélioration de la sensibilisation générale à la sécurité dès aujourd'hui. En l'absence de traitement sérieux, ce problème ne fera que s'aggraver.

Une version de cet article a été publiée dans Lecture sombre. Elle a été mise à jour pour être publiée ici.

Dans notre secteur, de nombreux experts en sécurité ont pris l'habitude de prédire les sujets brûlants de l'année à venir (et je ne fais pas exception), mais avec plus de cinq milliards d'enregistrements de données sensibles volés en 2019, j'ai pensé qu'il serait plus précis de prédire ce qui ne se passera pas en matière de cybersécurité en 2020, voire dans un avenir prévisible.

Je me suis assis avec mon cofondateur, Matias Madou, et nous avons bien ri en dressant cette liste. Elle se veut quelque peu légère, mais elle vous fait réfléchir au long chemin qui reste à parcourir pour protéger chaque organisation contre les cyberattaques malveillantes.

Maintenant, regardons dans notre boule de cristal et révélons nos prédictions. Nous ne verrons rien :

Les injections SQL éradiquées de tous les logiciels

Je pense que tous les professionnels de la sécurité de la planète attendent le jour où ils ne seront plus obligés d'identifier des bogues d'injection SQL, ad nauseam.

Malheureusement, nous attendons ce jour depuis plus de vingt ans, et nous continuerons à l'attendre au moins une fois de plus. C'est la vulnérabilité qui, telle une blatte, a survécu à toutes les tactiques mises en œuvre jusqu'à présent pour l'éradiquer définitivement.

C'est pour le moins frustrant, car le remède est connu depuis à peu près le même temps. Cependant, la priorité accordée aux meilleures pratiques de sécurité à chaque étape du développement de logiciels (en particulier dès le début) reste trop faible, et certainement inadéquate à la lumière de l'augmentation considérable de la production de code depuis la découverte de l'injection SQL.

(Vous voulez en savoir plus sur les schémas de codage qui peuvent conduire à une injection SQL ? Relevez le défi ici).

Les développeurs et l'AppSec deviennent les meilleurs amis du monde

Ah, les développeurs et l'équipe AppSec. Parviendront-ils un jour à s'entendre ou sont-ils destinés à une vie de rivalité comme Rocky contre Apollo ? La réponse courte est oui, ils peuvent s'entendre, mais à l'heure actuelle, leurs priorités sont souvent très différentes.

Lorsqu'ils se rencontrent dans le cadre d'un projet, ils sont sur des pages opposées et s'affrontent au moment du dernier obstacle : lorsque les spécialistes de l'AppSec examinent le code d'un développeur. Le développeur a construit de belles fonctionnalités fonctionnelles (ce qui est sa priorité absolue) qui sont mises en pièces si des vulnérabilités de sécurité sont découvertes. Le gourou de la sécurité des logiciels a, en effet, qualifié leur bébé de laid et a forcé le développeur à revenir en arrière et à corriger les bogues, ce qui retarde souvent le déploiement.

Dans l'état actuel des choses, ce problème ne sera pas résolu tant que les développeurs et les équipes AppSec ne travailleront pas à un objectif commun, à savoir la création de logiciels sécurisés. Cela ne se produira pas comme un processus par défaut en 2020 (et pour de nombreuses entreprises, pas mal d'années après), mais avec l'avènement du mouvement DevSecOps et au-delà, les développeurs reconnaissent la nécessité de se perfectionner en matière de sécurité et de travailler selon une norme plus élevée ; une norme qui inclut des objectifs de sécurité dès le début.

Une offre excédentaire de professionnels de la sécurité

En 2020, 2025, 2030... il est presque garanti que nous manquerons de personnel au niveau mondial en ce qui concerne l'expertise en matière de sécurité.

Selon un rapport de l'ISC(2), environ 2,93 millions de postes dans le domaine de la cybersécurité sont actuellement vacants. Il est presque certain que la situation va empirer avant de s'améliorer, et il n'y a pas d'armée cachée de la sécurité qui attende de venir à notre secours dans les prochaines années.

Dans l'immédiat, notre meilleure chance de remédier à cette pénurie de compétences est de faire de la sécurité une priorité organisationnelle et d'améliorer les compétences de notre main-d'œuvre existante, ce qui signifie donner aux développeurs la formation et les outils nécessaires pour coder en toute sécurité, ainsi que créer une culture de la sécurité à l'échelle de l'entreprise. La plupart des équipes AppSec actuelles luttent probablement contre des bogues de sécurité bien connus et anciens (voir le point 1 ci-dessus). Si nous veillons à ce qu'elles n'aient pas à consacrer du temps et des efforts précieux à la résolution de ces problèmes courants, elles auront plus de marge de manœuvre pour se concentrer sur les problèmes de sécurité les plus difficiles (pour l'instant, il s'agit probablement de problèmes liés aux API, ainsi que de la construction d'outils qui peuvent s'adapter aux pipelines de développement).

Moins de code produit

Le monde se numérise à une vitesse stupéfiante et la demande sociétale ne va pas faiblir. Environ 111 milliards de lignes de code sont écrites chaque année, et ce chiffre ne fera qu'augmenter et devenir de plus en plus terrifiant (pour les équipes AppSec déjà à bout de souffle, en tout cas).

L'augmentation du volume de code accroît inévitablement les vulnérabilités potentielles en matière de sécurité, de sorte que toute idée selon laquelle 2020 serait une année plus lente pour la production de logiciels et les violations est à peu près aussi réaliste qu'une course de licornes au Grand National.

Une réduction des vols de données

Comme je l'ai dit, plus de code signifie plus de vulnérabilités, ce qui offre plus de possibilités aux attaquants de trouver un moyen de voler des données.

Au moins 5,3 milliards d'enregistrements ont été volés dans le monde en 2019, et la défense contre les attaquants est toujours un peu une course désespérée et réactive. Ce chiffre ne doublera peut-être pas au cours des douze prochains mois, mais je pense qu'il s'en approchera.

À titre d'exemple, examinons les tendances historiques des données volées signalées aux États-Unis d'une année sur l'autre :

Si l'on considère la période 2005-2010, on constate une augmentation régulière avec un léger flux et reflux entre les années. C'est intéressant, mais il est important de souligner qu'en 2009, le nombre de violations signalées a fortement diminué par rapport à 2008. Toutefois, le nombre d'enregistrements volés a nettement augmenté malgré la diminution du nombre de violations.

Les enregistrements de données sont le nouvel or ; ils ont de la valeur pour un attaquant. Le graphique reflète une tendance générale à la hausse des violations et du nombre d'enregistrements volés, avec un pic énorme en 2017. Le nombre d'attaques a eu tendance à diminuer en 2018, peut-être en raison de mesures de sécurité plus strictes, mais le nombre d'enregistrements obtenus n'a jamais été aussi élevé. Les cyberattaques vont devenir de plus en plus sophistiquées, de plus en plus volumineuses et ne sont pas près de disparaître. À l'échelle mondiale, il est peu probable que nous assistions à un ralentissement en 2020, car les entreprises produisent plus de logiciels que jamais auparavant. Elles sont les gardiennes de nos données et doivent travailler plus intelligemment pour protéger notre vie privée.

Les développeurs demandent des formations à la sécurité par vidéo plus longues et plus fréquentes

S'il est une chose que les développeurs adorent, c'est bien de regarder des heures et des heures de vidéos de formation assistée par ordinateur (CBT). En fait, la demande pour ce contenu captivant est telle que Netflix va annoncer une toute nouvelle sous-catégorie consacrée aux vidéos génériques de formation à la sécurité.

Euh, non. Ni maintenant, ni en 2020, ni jamais.

Pour les développeurs, l'introduction à la sécurité se fait souvent par le biais d'une formation à la conformité sur le lieu de travail. Le codage sécurisé fait rarement partie de leur formation tertiaire, et la formation sur le tas peut être leur tout premier contact avec la sécurité des logiciels. Et, comme on peut s'y attendre, ils n'aiment pas cela.

Pour que les développeurs prennent la sécurité au sérieux - et pour que la formation soit utile - elle doit être pertinente, attrayante et contextuelle par rapport à leur travail. Une formation ponctuelle à la conformité - ou un flot ininterrompu de vidéos ennuyeuses - n'est pas le moyen de gagner le cœur d'un développeur, et cela ne réduira pas les vulnérabilités.

Si vous voulez que la cohorte de développeurs ait une chance de devenir une force défensive sensibilisée à la sécurité contre les vulnérabilités courantes, faites-les travailler avec de vrais exemples de code - ceux qu'ils rencontrent dans leurs tâches quotidiennes. Faites en sorte que l'apprentissage se fasse par petites touches, qu'il soit facile d'en tirer parti et qu'il soit motivé par un sentiment de plaisir. Pour qu'une culture de la sécurité prospère, elle doit être positive, engageante et développer des compétences et des solutions réelles dans l'ensemble de l'organisation.

Qui sait ? Avec la bonne formation, un développeur pourrait reconnaître le champion de la sécurité qui sommeille en lui et diffuser largement les avantages du codage sécurisé.

Aucun décès dû à un incident lié à la cybersécurité

D'accord, il ne s'agit pas d'un sujet de plaisanterie. J'ai dit à plusieurs reprises que le monde ne s'intéresserait pas à la cybersécurité tant que des personnes ne mourraient pas des suites d'un incident lié à une cyberattaque.

Le problème, c'est que cela s'est déjà produit et que cela est passé largement inaperçu.

Des cyberattaques contre des hôpitaux américains ont été liées à une augmentation du nombre de décès par crise cardiaque en 2019. Bien sûr, les attaquants n'ont pas provoqué d'événements cardiaques mortels chez les patients, mais leurs attaques par ransomware sur les systèmes et équipements hospitaliers ont ralenti les délais de traitement pour les soins critiques.

Cette étude de l'université de Floride centrale a analysé 3 000 hôpitaux, dont 311 avaient subi une violation de données. Dans les hôpitaux touchés par un incident de sécurité, il fallait en moyenne 2,7 minutes de plus pour faire passer un ECG aux victimes présumées d'une crise cardiaque, probablement en raison des changements de procédure, des mesures de sécurité nouvellement mises en œuvre et des problèmes d'assistance informatique qui prenaient plus de temps qu'auparavant. L'identification et le traitement d'une crise cardiaque sont une course contre la montre, et ces hôpitaux ont enregistré en moyenne 36 décès supplémentaires pour 10 000 crises cardiaques par an.

C'est choquant et, malheureusement, je pense que la situation va empirer avant de s'améliorer. Cela devrait nous rappeler brutalement que nous devons tous faire davantage pour améliorer la sécurité des logiciels et faire en sorte qu'elle soit au centre des préoccupations de chaque entreprise.

Moins d'images d'archives de "hackers cagoulés"

Si vous tapez "hacker" dans une recherche d'images, vous découvrirez inévitablement des milliers d'images d'un personnage cagoulé, sans visage, tapant sur un ordinateur portable, ou d'un personnage similaire portant un masque de Guy Fawkes.

L'image stéréotypée du pirate informatique est de plus en plus fatiguée et fait passer tout le monde pour un méchant. Il y a beaucoup de bons gars et de bonnes filles dans le domaine de la sécurité, et les connotations négatives autour de l'image du "hacker" ne rendent pas service à tout le monde.
Est-ce que je pense que cela va changer bientôt ? Probablement pas, mais il est agréable de rêver. Pour l'instant, il est important de se rappeler que la sécurité n'a pas à être effrayante.