Si un développeur écrit une erreur de script intersite alors qu'il code en JavaScript, et qu'il est capable de la détecter dans les minutes qui suivent la création de cette faille, il ne faudra probablement que quelques minutes ou quelques secondes pour la corriger.

En revanche, si cette faille est découverte deux semaines plus tard par un testeur manuel, elle sera saisie dans un système de suivi des défauts. Il sera trié. Il sera placé dans la file d'attente des bogues de quelqu'un.

Avec le retard dans l'identification, il faudra faire des recherches dans le contexte original et cela ralentira le développement. Maintenant, vous parlez potentiellement d'heures de temps pour corriger le même défaut. Le temps nécessaire peut être multiplié par 10 ou 100.

Je suis tout à fait d'accord avec Chris Wysopal (CTO, Veracode) dans son récent podcast avec O'Reilly Security Podcast où il explique pourquoi le déplacement de la sécurité vers la gauche (vers les développeurs au début du cycle de vie du développement) est essentiel dans un environnement agile pour maintenir le rythme et la vitesse.

La sécurité devrait être facilitée pour les développeurs en utilisant des plugins IDE, des scanners et en les éduquant pour qu'ils aient les compétences de base en matière de sécurité (hygiène). Les organisations ne devraient pas s'en remettre uniquement à des experts en sécurité ou à une équipe de sécurité centralisée qui valide tous les changements.

Notre modus operandi habituel en matière de sécurité ne fonctionne plus (faites appel à un expert !) et nous devons intégrer la sécurité dans les équipes de développement afin de garantir le maintien de la qualité tout en restant agile.

https://www.oreilly.com/ideas/chris-wysopal-on-a-shared-responsibility-model-for-developers-and-defenders

Je suis heureux de constater que Secure Code Warrior n'est pas le seul à réfléchir à la manière de modifier les comportements au sein d'une entreprise en utilisant le renforcement positif et des éléments basés sur le jeu.

Cet article du WSJ souligne que la sensibilisation à la cybersécurité est plus efficace et a plus d'impact sur les employés lorsque la formation n'est pas épouvantable, ennuyeuse, répétitive ou tout simplement inutile. Dans le passé, les formations à la cybersécurité étaient généralement dispensées par des experts en sécurité qui étaient des techniciens et fournissaient un matériel approfondi, mais sans vraiment réfléchir à la manière de transmettre des messages clés qui retiennent l'attention des employés.

Cependant, je constate de plus en plus, en tout cas chez les clients avec lesquels nous travaillons, que les organisations impliquent désormais les équipes de marketing et de communication et les gestionnaires du changement, qu'elles utilisent l'animation numérique dans leur contenu et qu'elles organisent des événements et des défis pour rendre la formation à la cybersécurité plus ludique et plus attrayante. Les menaces de cybersécurité augmentant d'année en année, la sensibilisation à la sécurité et la formation des employés constituent l'investissement le plus important que votre organisation puisse faire.

Les campagnes de renforcement positif sont souvent l'un des meilleurs moyens de modifier les comportements à risque, mais elles sont "tout à fait exceptionnelles" dans le monde de l'entreprise, déclare Mme Sedova.

https://www.wsj.com/articles/a-better-way-to-teach-cybersecurity-to-workers-1505700120

Il y a une question que doit se poser tout développeur, qu'il soit diplômé ou vétéran. Et la réponse est importante. Elle est devenue encore plus importante dans un monde agile, car elle aura un impact direct sur votre réussite dans le domaine du génie logiciel et sur la valeur que vous apporterez à votre prochain employeur.

C'est la question à un million de dollars. En fait, c'est la question à plusieurs millions de dollars !

Vous engagez-vous à m'aider à coder en toute sécurité ?

Le coût moyen d'une violation de données s'élève aujourd'hui à 3,6 millions de dollars. La probabilité que votre entreprise soit victime d'une violation de données cette année est d'une sur quatre. Compte tenu de ces faits, je partage les frustrations de nombreuses personnes qui constatent que les développeurs ne sortent pas de l'université avec des compétences en matière de codage sécurisé et que la sécurité est inscrite dans leur ADN.  

Pourquoi ? Le génie logiciel est une profession encore relativement jeune. L'accent a été mis sur l'enseignement de la construction rapide de codes, de leur élégance et de leur fonctionnalité, mais l'attention portée à la sécurisation des codes a été très limitée. Le rythme d'évolution des méthodologies, des technologies, des langages et des opportunités ne fait qu'exacerber ces lacunes en matière de compétences.

Nous n'allons pas changer le système académique rapidement, donc les développeurs et les entreprises devraient s'attendre à ce que les développeurs aient besoin d'apprendre des compétences de codage sécurisées sur le terrain. Dans certaines professions, vous pouvez apprendre en faisant des erreurs, mais pour d'autres, ce n'est pas une option. Il en va de même pour la cybersécurité.

Les faits montrent que nous n'avons pas non plus été très performants en matière de formation à la sécurité des développeurs en cours d'emploi. La plupart des grandes failles de sécurité dans le monde sont dues à des erreurs de codage qui permettent aux pirates d'obtenir des privilèges sur les réseaux informatiques, ce qui leur permet d'accéder à des données précieuses et de les récolter. Le rapport Verizon Data Breach Investigation Report (DBIR) 2017 montre que 30 % de toutes les violations sont directement causées par des faiblesses dans la sécurité des applications web et cette conclusion est constante dans le rapport DBIR depuis 2013.

L'enquête mondiale 2017 sur les compétences DevSecOps, publiée en août 2017, a confirmé ce que nous savions déjà : si 65 % des professionnels DevOps estiment qu'il est très important d'avoir des connaissances en DevSecOps lorsqu'on entre dans l'informatique, 70 % d'entre eux pensent qu'ils ne reçoivent pas la formation nécessaire par le biais de l'enseignement formel pour réussir dans le monde DevSecOps d'aujourd'hui.

Près de 40 % des responsables du recrutement interrogés ont déclaré que les employés les plus difficiles à trouver sont les développeurs haut de gamme polyvalents ayant des connaissances suffisantes en matière de tests de sécurité. 70 % des personnes interrogées ont déclaré que la formation en matière de sécurité qu'elles avaient reçue n'était pas adaptée à leur poste actuel. En fait, moins de 4 % des personnes interrogées ont déclaré qu'elles avaient eu l'occasion de se former.

J'ai pu le constater de mes propres yeux lorsque j'ai travaillé pendant près de dix ans avec plusieurs équipes de pirates informatiques professionnels. Avec une régularité tragique, nous nous sommes introduits dans de grandes entreprises, des start-ups et des services gouvernementaux, en trouvant toujours les mêmes faiblesses.

C'est pourquoi les développeurs doivent s'exprimer lorsqu'ils sont embauchés. Si votre futur employeur ne prend pas au sérieux votre formation à la sécurité des développeurs, vous devriez réfléchir au type d'entreprise que vous envisagez de rejoindre.

La deuxième question que vous devez vous poser est de savoir comment ils prévoient de dispenser la formation. Sera-t-elle pratique et interactive ? Une formation à la sécurité des développeurs sur les vulnérabilités qui utilise des diapositives, des vidéos, des animations cliquables ou des discussions abstraites a peu de chances de vous aider directement dans votre codage. Ces formations vous permettront-elles de vous tenir continuellement au courant des dernières vulnérabilités ? Existe-t-il une guilde ou une communauté de sécurité auprès de laquelle vous pouvez apprendre ? Existe-t-il des experts en sécurité auxquels vous pouvez faire appel si vous avez besoin d'aide ?

Un engagement envers vos compétences en matière de codage sécurisé nécessite un apprentissage continu par le biais de défis pratiques dans des cadres de codage spécifiques et en vous confrontant à différentes vulnérabilités dans de multiples scénarios. Vous ne pouvez tout simplement pas apprendre les injections SQL à partir d'un seul exemple. Vous devez être exposé à de multiples exemples de différents types afin d'apprendre à reconnaître ces modèles de codage dangereux.

L'un de nos clients a demandé à ses développeurs de relever un seul défi (5 minutes) chaque jour pendant deux mois. Il a testé leurs compétences avant et après la période de formation et a observé une augmentation de 60 % des capacités de codage sécurisé sur un groupe de centaines de développeurs. Cela signifie que moins de ressources sont consacrées à la recherche et à la correction de bogues de sécurité à un stade ultérieur du cycle de vie et que d'importantes économies sont réalisées à long terme. Cela signifie que les pirates n'utiliseront pas votre code pour compromettre les données de votre entreprise.

Il y avait 11 millions de développeurs professionnels dans le monde en 2014, selon une étude d'IDC. En 2015, Burning Glass a constaté que pas moins de 7 millions d'emplois nécessitaient des compétences en codage et que les emplois dans le domaine de la programmation augmentaient en moyenne 12 % plus vite que le marché.

Il existe de nombreux emplois dans le domaine des logiciels. Prenez donc position et choisissez des employeurs qui s'engagent à prendre soin de leur sécurité, de votre sécurité et de celle de leurs clients. Par extension, choisissez des entreprises qui investissent en vous.

Il y a une question que doit se poser tout développeur, qu'il soit diplômé ou vétéran. Et la réponse est importante. Elle est devenue encore plus importante dans un monde agile, car elle aura un impact direct sur votre réussite dans le domaine du génie logiciel et sur la valeur que vous apporterez à votre prochain employeur.

C'est la question à un million de dollars. En fait, c'est la question à plusieurs millions de dollars !

Vous engagez-vous à m'aider à coder en toute sécurité ?

La semaine dernière, j'ai fait des recherches sur les vulnérabilités de Java Spring afin de mettre à jour nos lignes directrices en matière de codage sécurisé. J'ai passé en revue les défis existants sur notre plateforme et j'en ai remarqué quelques-uns concernant les XSS par l'affichage de paramètres d'url dans les pages JSP. L'exemple de code incorrect ressemblerait à ce qui suit :

   <input type="text" name="username" value="${param.username}">

La solution correcte consistait à supprimer complètement le paramètre URL et la description mentionne qu'il est également possible d'échapper le paramètre URL de la bonne manière.

Maintenant, mon travail consiste à formuler la ligne directrice sur le codage sécurisé d'une manière qui soit claire pour les développeurs et qui les restreigne le moins possible tout en continuant à écrire du code sécurisé. Dans ce cas, je préférerais laisser les développeurs conserver la fonctionnalité prévue et leur recommander de le faire de manière sécurisée en échappant le paramètre URL. De cette manière, le code ne contient plus de vulnérabilité XSS. L'exemple ci-dessus peut être sécurisé comme suit :

   <input type="text" name="username" value="${fn:escapeXml(param.username)}">

C'était notre ligne de conduite en matière de codage sécurisé pendant quelques jours, jusqu'à ce que je tombe sur une page de l'OWASP sur l'injection de langage d'expression. Cette page décrit comment le langage d'expression Spring (SpEL) peut être utilisé de manière abusive à des fins d'injection avec un impact sérieux, y compris l'exécution de code à distance. Il m'incombait de déterminer s'il pouvait y avoir des cas où un code adhérant à notre directive de codage sécurisé pouvait encore être affecté par cette vulnérabilité. J'ai donc écrit une application de test rapide pour évaluer les expressions SpEL, et j'ai testé les entrées avec et sans échappement Xml pour voir si je pouvais trouver des scénarios qui ne seraient pas pris en compte. Et c'est ce que j'ai fait, il y a des expressions malveillantes qui ne contiennent aucun caractère pris en compte par XmlEscape. J'ai publié la démo de travail sur notre github, que vous pouvez trouver ici.

Et bien sûr, j'ai mis à jour notre ligne directrice sur le codage sécurisé, qui se lit désormais comme suit : "N'affichez pas et n'évaluez pas les paramètres d'URL en utilisant le langage d'expression Spring (SpEL).

L'impact global de ce problème est élevé, pour les raisons suivantes : - Un attaquant pourrait modifier et invoquer des fonctionnalités sur le serveur d'application. - Accès non autorisé aux données et aux fonctionnalités, ainsi que détournement de compte et exécution de code à distance. - Problèmes de confidentialité et d'intégrité en cas d'attaque réussie.

https://www.owasp.org/index.php/Expression_Language_Injection

Les problèmes de sécurité identifiés en 2016 sur le site web d'Equifax n'ont toujours pas été résolus. Identifier le problème est une étape, mais le résoudre est un défi encore plus grand. Il faut du temps et des compétences pour retourner dans le code, comprendre le contexte et résoudre les problèmes.

Il est clair que les développeurs d'Equifax étaient très stressés et que de nombreuses vulnérabilités connues n'ont pas été corrigées. Malheureusement, ce manque d'action a eu la pire réponse possible.

La sécurité doit être intégrée dès le départ et les développeurs doivent disposer des compétences, de la formation et des outils in-IDE pour minimiser l'écriture des vulnérabilités connues. La résolution des problèmes identifiés nécessite des connaissances spécifiques en matière de langage et de framework. Le principe général de la correction d'un problème XSS reste le même, mais la mise en œuvre réelle dépend des cadres en place.

Si vous souhaitez suivre une formation interactive sur la manière de résoudre les problèmes XSS dans Struts, consultez le site : https://portal.securecodewarrior.com/#/simple-flow/web/xss/reflected/java/struts

En 2016, un chercheur en sécurité a découvert une vulnérabilité courante connue sous le nom de cross-site scripting (XSS) sur le site web principal d'Equifax, selon un tweet d'un chercheur répondant au nom de x0rz. Ces bogues XSS permettent aux attaquants d'envoyer des liens spécialement conçus aux clients d'Equifax et, si la cible clique dessus et se connecte au site, son nom d'utilisateur et son mot de passe peuvent être révélés au pirate.

https://www.forbes.com/sites/thomasbrewster/2017/09/08/equifax-data-breach-history/#552ab1c9677c

La semaine dernière, il a été rapporté que la violation des données d'Equifax pouvait être due à une vulnérabilité dans le plugin REST d'Apache Struts. L'ancienne version du plugin est vulnérable aux attaques par exécution de code à distance lorsqu'elle est utilisée avec le gestionnaire XStream pour traiter les charges utiles XML. La cause est la désérialisation de données non fiables, qui est un type de vulnérabilité bien connu. La vulnérabilité, officiellement reconnue comme CVE-2017-9805, a été corrigée par Apache le 5 septembre dans la version 2.5.13 de Struts. Elle a ensuite été annoncée et clairement documentée dans la documentation d'Apache Struts.

Une simple mise à jour vers la version la plus récente de Struts peut protéger l'application contre cette attaque, alors pourquoi les entreprises ne procèdent-elles pas immédiatement à cette mise à jour ? Le problème des vulnérabilités liées à la désérialisation est que les routines exploitées sont souvent celles sur lesquelles repose le code de l'application. Dans ce cas, l'application du nouveau correctif Struts pourrait avoir des effets secondaires, comme le mentionne la documentation sur la vulnérabilité : "Il est possible que certaines actions REST cessent de fonctionner en raison des restrictions par défaut appliquées aux classes disponibles." Il est très probable que s'assurer que l'application continue à fonctionner sur des versions plus récentes de Struts prenne un certain temps.

Les pirates n'ont cependant pas besoin d'autant de temps pour commencer à abuser des vulnérabilités publiées, et nous pouvons déjà voir certains exploits publiés. Un module Metasploit a été ajouté le 8 septembre, soit trois jours après qu'Apache a corrigé la vulnérabilité. Reporter votre correctif n'est manifestement pas une bonne idée !

La solution consiste à mettre en œuvre une solution de contournement proposée par Apache, ce qui pourrait être fait dans un délai plus court. Un outil de sécurité avec des règles de codage configurables pour appliquer cette solution de contournement ou même l'appliquer automatiquement accélérerait grandement ce processus.

Vous voulez en savoir plus sur la manière d'identifier et de sécuriser le code qui contient la désérialisation de données non fiables ? Visitez le portail Secure Code Warrior pour une explication claire et un défi de formation.

La vulnérabilité concerne la manière dont Struts analyse ce type de données et les convertit en informations pouvant être interprétées par le langage de programmation Java. Lorsque la vulnérabilité est exploitée avec succès, un code malveillant peut être caché à l'intérieur de ces données et exécuté lorsque Struts tente de les convertir.

https://qz.com/1073221/the-hackers-who-broke-into-equifax-exploited-a-nine-year-old-security-flaw/

L'une des difficultés liées à l'apprentissage d'une nouvelle bibliothèque ou au partage de pratiques communes au sein de notre équipe réside dans la documentation et la création d'exemples.

Très souvent, nous créons de petits projets d'exemple, mais nous ne les ouvrons pas lorsque nous travaillons avec le code réel.

J'ai souvent pensé qu'il serait formidable de pouvoir créer un lien vers nos exemples ou vers des exemples en ligne et de pouvoir accéder à une URL pour plus d'explications lorsque cela est nécessaire.

Avec Java, nous avons des commentaires JavaDoc, qui peuvent avoir une annotation see :

/**
 * @see <a href="https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations">Junit 5 Annotation docs</a>
 */

Les JavaDocs de ce type dans les bibliothèques tierces sont d'une grande aide car nous pouvons utiliser la fonctionnalité de documentation rapide dans IntelliJ pour avoir accès à des exemples plus détaillés.

Mais nous savons tous que les commentaires ne sont pas mis à jour aussi souvent que le code, et que la maintenance de la présence sur le web est souvent déconnectée de la maintenance de la bibliothèque et parfois réalisée par une équipe complètement différente.

Comment Sensei vous aide

Sensei permet de faire correspondre les annotations de la bibliothèque et les méthodes pour fournir des liens vers une documentation longue sur un wiki ou un site de tutorat tiers.

A titre d'exemple, j'utilise l'annotation @Test de JUnit.

La JavaDoc est très détaillée et la vue Documentation rapide explique comment utiliser l'annotation.

Mais la documentation officielle sur le site web est souvent plus facile à lire et contient plus d'exemples.

Lorsqu'une équipe commence à apprendre une bibliothèque, il peut être très utile de disposer d'un ensemble de tutoriels recommandés.

Sensei possède une action goto que nous pouvons utiliser pour ouvrir une URL, ce qui nous permet de créer des liens vers des sites externes et des exemples de documentation que nous, en tant qu'équipe, trouvons utiles.

Mise en œuvre de l'URL Goto

Pour mettre cela en œuvre, je créerais une recherche qui correspondrait à l'annotation @Test de Junit.

search:
   annotation:
    owner:
      method: {}
    type: "org.junit.jupiter.api.Test"

Ensuite, j'ajouterais des actions "goto" pour chacune des URL que je trouve utiles.

par exemple

• https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations
• https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods

L'exemple ci-dessous crée une seule action JUnit Annotations (learn) qui ouvre les deux URL dans un navigateur en même temps.

availableFixes :
- name : "Learn about JUnit Annotations"
actions :
- goto :
type : "URL"
value : "https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations"=
- goto :
type : "URL"
value : "https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods"

Et lorsque je l'active dans IntelliJ avec Alt+Enter , je vois le menu contextuel que je peux sélectionner pour accéder à la documentation.

Actions multiples

Je pourrais choisir d'avoir plusieurs actions afin que chaque URL ou tutoriel ait sa propre option dans le menu contextuel de la correction rapide alt+enter.

Par exemple, pour l'annotation @Parameterized, je pourrais vouloir créer un lien vers la documentation officielle et un ensemble d'exemples de code en ligne.

• https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests
• https://github.com/eviltester/junitexamples/blob/master/src/test/java/parameterized/junit5/InitialExampleTest.java

Je créerais simplement une recette qui rechercherait l'annotation :

search:
  annotation:
    owner:
      method: {}
    type: "org.junit.jupiter.params.ParameterizedTest"

Et des liens vers les sites que j'ai identifiés comme étant utiles :

availableFixes :
- name : "JUnit Annotations (learn)"
actions :
- goto :
type : "URL"
value : "https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations"
- name : "Qu'est-ce qu'un test JUnit ? (apprendre)"
actions :
- goto :
type : "URL"
valeur : "https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods"

Les deux liens apparaissent alors dans la boîte de dialogue.

Qui en bénéficierait ?

J'aurais trouvé cela utile pour l'utilisation et l'apprentissage des bibliothèques, en particulier lorsque je dirige des équipes et que je les aide à adopter une nouvelle bibliothèque.

Cela pourrait également profiter aux équipes qui créent des bibliothèques, en créant un ensemble standard de recettes de documentation pour aider les gens à adopter la bibliothèque ou de nouvelles fonctionnalités dans la bibliothèque.

Ceci est particulièrement utile si la maintenance du code et la maintenance de la documentation sont effectuées par des équipes différentes.

Vous pouvez installer Sensei depuis IntelliJ en utilisant `preferences > plugins` (recherchez simplement "sensei secure code").

Tout le code de ce billet se trouve sur Github dans le module junitexamples dans https://github.com/SecureCodeWarrior/sensei-blog-examples

Une fois de plus, la cause première du piratage d'Equifax est une vulnérabilité d'application web. Ce type de vulnérabilités existe depuis plus d'une décennie, mais il est toujours d'actualité. Chaque développeur devrait recevoir les outils nécessaires pour éviter d'introduire ces problèmes en premier lieu, grâce à une formation et à des conseils en temps réel lors du développement du code.

Equifax a déclaré avoir découvert la faille le 29 juillet. "Les criminels ont exploité une vulnérabilité de l'application d'un site web américain pour accéder à certains fichiers", a déclaré l'entreprise.

Lire la suite : La société d'évaluation du crédit Equifax déclare que l'incident de cybersécurité pourrait potentiellement affecter 143 millions de consommateurs américains.

Bonjour à tous !

Le mois de septembre étant terminé, nous voulions profiter de l'occasion pour passer en revue les mises à jour les plus intéressantes que nous avons livrées pour Sensei au cours du mois de septembre. Vous pouvez également essayer Sensei en l'installant directement depuis le JetBrains Marketplace. 

Tags

Nous souhaitions offrir la possibilité d'ajouter des métadonnées personnalisées, que vous pouvez utiliser pour classer et regrouper les recettes. Nous۪ avons maintenant ajouté la possibilité d'ajouter des étiquettes aux recettes.
‍

Nos clients nous ont fait part de leur souhait de voir des indicateurs sur la façon dont les recettes sont utilisées, sans nécessairement révéler trop de choses sur les recettes dans les indicateurs. Les balises constituent une étape vers cet objectif, en fournissant aux équipes des mesures pertinentes pour piloter leurs programmes de qualité. 

‍

Navigateur variable

Lorsque vous créez une recette, il est très utile de comprendre comment sont structurés les éléments du code que vous faites correspondre, afin de faciliter la recherche. À cette fin, nous avons ajouté notre navigateur de variables dans l'éditeur de recettes à plusieurs endroits. Les variables affichées sont relatives à la cible sélectionnée. Cela vous aide à comprendre votre code et à élaborer une bonne recette avec moins d'efforts.
‍

Mise à jour du gestionnaire du livre de cuisine

Nous avons déplacé le gestionnaire de livres de cuisine dans un panneau au sein de l'IDE, plutôt que de faire apparaître une nouvelle fenêtre. Cela rend l'expérience de gestion des livres de cuisine beaucoup plus simple et fluide. Au lieu d'avoir à ouvrir la fenêtre, vous pouvez simplement la développer directement depuis votre barre latérale !

Essayez Sensei dès maintenant ! 

Sensei est disponible gratuitement sur le JetBrains Marketplace. Nous le développons et l'améliorons activement et nous attendons avec impatience de savoir comment vous l'intégrez dans votre processus de développement.