Responsables AppSec, CISO, CIO, experts en cybersécurité - j'ai parlé à beaucoup d'entre eux, travaillant dans toutes sortes d'entreprises à travers le monde - au cours de ma propre carrière dans le développement de logiciels et la sécurité.

Quelle que soit leur situation, l'expérience de leur équipe ou le temps qui passe dans ce monde numérique en constante évolution, un problème reste toujours le même : ils sont rarement en mesure d'impliquer positivement leur équipe de développement dans la sécurité. La sécurité est toujours un gros mot, une source de conflit entre les équipes et une véritable plaie pour l'industrie.

Cependant, la sécurité des logiciels est tout simplement trop importante pour que notre état d'esprit général continue dans cette voie. Nous devons nous efforcer de changer les choses, de faire de la sécurité une partie intégrante de la vie professionnelle de chaque développeur. Et je pense que l'un des meilleurs moyens d'y parvenir est de responsabiliser les développeurs et de les impliquer dans la sécurité par le biais, par exemple, de la gamification.

Le paysage actuel

Les développeurs quittent l'université avec très peu de connaissances pratiques sur la fourniture d'un code sécurisé, ils occupent des emplois où la formation à la sécurité est rarement une priorité (et lorsqu'elle l'est, c'est généralement dans le cadre des vidéos de conformité obligatoires sur la santé et la sécurité, qui sont si ennuyeuses que personne ne s'intéresserait à la sécurité du codage). Très souvent, leur première expérience de la sécurité est un audit ou un rapport de bogue de test qui interrompt soudainement une version future, devenant ainsi une perturbation instantanée et prioritaire de leur esprit créatif. Ils se retrouvent en conflit avec les responsables des rapports de sécurité, si bien que "sécurité" devient synonyme de "critique" dans leur esprit. La honte.

Il est vraiment dommage que cette perception négative de la sécurité des logiciels soit si répandue. Après tout, certains des meilleurs souvenirs que je garde de ma carrière sont liés à l'apprentissage de la sécurité des logiciels. J'ai passé mes premiers jours de piratage à assister à des conférences, où j'ai pu non seulement tester mes compétences (et, pour être honnête, me montrer un peu) face à mes pairs, mais aussi prendre énormément de plaisir à rencontrer des personnes partageant les mêmes idées et qui aimaient casser des logiciels autant que moi.

BruCon, DefCon, BlackHat... ces événements ont permis à des gens comme moi d'exercer leurs talents dans le cadre d'une compétition amicale. Je n'admettrais jamais de participer à des activités aussi antisociales, mais certains montraient même leurs prouesses de piratage en s'introduisant dans les téléphones d'autres participants, affichant leurs informations sur les écrans de présentation pour que tout le monde puisse les voir. C'est devenu un jeu : trouver ces failles, les exploiter et les corriger, afin d'améliorer les logiciels. Il y a quelques années, j'ai eu le privilège de me trouver devant des centaines d'enfants au Moyen-Orient pour leur enseigner la cybersécurité. Je me souviens encore d'une fillette de huit ans parmi mes élèves, qui apprenait à forcer les mots de passe et à coder en base64 tout en jouant à des jeux.

La gamification est également utilisée pour enseigner les techniques de codage. Les établissements d'enseignement du monde entier utilisent cette approche pour enseigner le codage à de très jeunes enfants, même jusqu'à l'âge du lycée. Des enfants de quatre ans seulement participent régulièrement à des initiatives de vacances telles que CodeCamp, et il existe une multitude de programmes en ligne fantastiques qui apprennent aux enfants à coder en Python et dans d'autres langages. J'ai même acheté l'incroyable outil de codage sans écran, Cubetto, pour ma fille de quatre ans.

Cependant, malgré tout ce plaisir et ces progrès, il y a une lacune. Personne n'a pensé à la possibilité d'utiliser la gamification pour former les développeurs à l'écriture de codes sécurisés.

Enfin... presque personne. Il y a quelques années, je me suis rendu compte qu'il fallait redonner de l'inspiration à la sécurité et motiver les développeurs à s'impliquer et à jouer le jeu.

La gamification : La voie simple à suivre.

Il y a en moi une volonté profonde d'aider les développeurs à acquérir des connaissances en matière de sécurité, et c'est cette passion qui m'a conduit à créer Secure Code Warrior. La sécurité des logiciels est tellement importante, et elle peut vraiment être passionnante.

Je ne suis pas le seul à penser ainsi.

La gamification peut rendre les tâches les plus banales plus amusantes et permet aux gens de rester suffisamment engagés pour vouloir continuer à jouer, à gagner et à progresser - il suffit de voir comment Pok̩mon Go ! a permis aux plus paresseux de quitter leur canapé, de sortir et de chercher des créatures imaginaires, ou comment FitBit fait de l'atteinte du nombre de pas un objectif quotidien pour beaucoup... un sentiment très réel de déception s'installe si ces objectifs ne sont pas atteints, si les séries sont terminées et si les badges ne sont pas gagnés.

Revenons donc à la formation à la sécurité. Nous avons prouvé à de nombreux clients que la gamification est essentielle pour transformer la culture de la sécurité au sein de leur organisation, pour établir des ponts entre les équipes AppSec et les équipes de développement, ainsi que pour les aider de manière générale à créer des logiciels d'un niveau plus élevé.

À l'heure actuelle, la sécurité n'est pas la priorité du développeur. En ajoutant un élément amical, compétitif et engageant à vos méthodes de formation, vous les motivez non seulement à "jouer", mais aussi à revenir pour gagner plus de points, battre des scores élevés, devenir plus précis et défier les autres membres de l'équipe.

Nous savons déjà qu'une formation réussie ressemble à ceci :

• Les développeurs peuvent travailler sur du code réel et dans leurs propres langages/frameworks.
• Les défis sont courts et couvrent toutes les vulnérabilités courantes en matière de sécurité.
• Les défis sont constamment élargis et mis à jour afin que les développeurs puissent continuer à développer leurs compétences au fil du temps.
• Les défis varient en complexité, de sorte qu'ils sont intéressants pour les développeurs chevronnés comme pour les moins expérimentés.
• Les développeurs et leurs responsables sont en mesure de visualiser les progrès réalisés, y compris les défis qu'ils ont relevés, leurs forces et leurs faiblesses, le temps consacré à la formation et leur précision globale.

L'un de nos plus gros clients a montré la véritable magie d'une plateforme gamifiée lors de son déploiement, en habillant ses développeurs avec des tenues d'équipe à thème, en offrant des prix incroyables aux gagnants des jeux et en faisant de son site tournament une journée inoubliable. Ils ont depuis proposé des compétitions internationales et toute leur équipe continue aujourd'hui encore à accumuler de nombreuses heures de formation.

Votre propre révolution logicielle commence ici. Le secteur bancaire australien est à la pointe de l'adoption de la formation gamifiée dans la lutte contre le mauvais code, dans le cadre d'une approche véritablement innovante qui bouleverse la formation traditionnelle (ou ennuyeuse) - il suffit de regarder ce que notre client a fait avec son prochain niveau tournament. Êtes-vous prêt à faire évoluer votre équipe avec nous ?

Nous devons nous efforcer de changer le discours, de faire en sorte que la sécurité fasse partie intégrante de la vie professionnelle de chaque développeur. Et je pense que l'un des meilleurs moyens d'y parvenir est de responsabiliser les développeurs et de les impliquer dans la sécurité par le biais, par exemple, de la ludification.

J'ai eu le plaisir de contribuer, avec un certain nombre d'experts, à un article perspicace de Suparna Goswami dans Data Breach Today. Comme elle le souligne, tout le monde s'accorde à dire qu'il est essentiel d'aborder la sécurité dès le début du cycle de développement des logiciels (SDLC) pour prévenir les violations de données, mais c'est plus facile à dire qu'à faire. Les RSSI nous livrent quelques réflexions intéressantes, ainsi que les résultats d'une enquête récente montrant que le plus grand défi en matière de sécurité des applications dans les flux de travail d'intégration continue/de livraison continue (CI/CD) est le suivant :"le manque d'outils de test de sécurité automatisés et intégrés".

À mon avis, DevSecOps devrait commencer lorsque le développeur commence à écrire le code. Pour que DevSecOps fonctionne efficacement, il faut que les développeurs aient la formation, les compétences et les outils nécessaires pour écrire du code en toute sécurité dès le départ. Si les développeurs apprenaient à écrire du code sécurisé en temps réel, ou mieux encore - à éviter de créer de nombreux bogues, les responsables de la sécurité et les outils de test pourraient alors se concentrer sur la recherche et la correction des vulnérabilités vraiment difficiles et complexes en temps opportun.

Il existe de nombreuses solutions pour trouver les vulnérabilités dans le code, mais la sécurité doit mettre davantage l'accent sur l'enseignement aux développeurs des règles de sécurité qui les empêcheront de commettre ces erreurs dès le départ.

Les développeurs devraient être aidés à écrire du code sécurisé et à corriger la grande majorité des erreurs qu'ils commettent en écrivant du code, et je suis fier de dire que la technologie existe maintenant pour y parvenir. Tout comme les outils de correction orthographique et grammaticale aident les écrivains, les développeurs peuvent désormais être aidés en temps réel à écrire de manière sécurisée, conformément à la politique linguistique et de sécurité en vigueur. À mon avis, c'est l'avenir le plus facile et le plus brillant pour DevSecOps.

C'est exactement ce qu'offre notre Secure Code Warrior Sensei Il agit comme un coach de sécurité en temps réel pour les équipes de développement, contrôlé par AppSec, garantissant que les directives de sécurité sont aux côtés du développeur à tout moment. Il les aidera à coder de manière plus cohérente, plus sûre et plus rapide. Dans le cadre de notre programme d'adoption précoce, nous avons pu constater qu'il permettait de réduire le temps nécessaire à la résolution des problèmes de trois heures en moyenne par bogue à dix minutes seulement.

Nous devons utiliser des outils de sécurité capables de travailler selon un calendrier DevSecOps, avec efficacité et, surtout, précision. Il est temps de viser une norme plus élevée en matière de sécurité des logiciels.

Il existe de nombreuses solutions pour trouver les vulnérabilités dans le code, mais la sécurité doit mettre davantage l'accent sur l'enseignement aux développeurs des règles de sécurité qui les empêcheront de commettre ces erreurs dès le départ.

Pour ce billet, j'ai recréé une "mauvaise" approche de codage que j'ai utilisée lorsque j'apprenais JUnit, et je vais démontrer comment convertir le "mauvais" modèle en un modèle de codage convenu, et "meilleur", en utilisant Sensei.

Lorsque j'apprenais JUnit, je n'arrivais pas à garder tout ce que j'avais en tête à un moment donné. J'oubliais constamment comment sauter des tests lorsqu'ils ne fonctionnaient pas.

Si vous travaillez en équipe, vous pouvez utiliser les revues de code sur les demandes d'extraction pour aider à faire respecter les styles de codage. Et nous pouvons raccourcir le cycle de retour d'information en programmant en binôme avec un programmeur plus expérimenté.

Nous pouvons également renforcer notre processus avec des outils et faire en sorte que ces outils nous incitent à faire ce qu'il faut. Thoughtworks a décrit cela comme des "outils plutôt que des règles", dans sa liste Technology Radar pour Sensei, afin de "faciliter les bonnes actions plutôt que d'appliquer des règles et des procédures de gouvernance de type liste de contrôle" : "faciliter l'accomplissement des bonnes actions plutôt que d'appliquer des règles et des procédures de gouvernance de type liste de contrôle".

Désactiver un test JUnit

Idéalement, comme nous le savons tous, j'utiliserais l'annotation @Disabled et j'écrirais :

  @Disabled
  @Test
  void canWeAddTwoNumbers(){
        Assertions.fail("this test was skipped and should not run");
   }

Mais lors de l'apprentissage, j'ai dû m'entraîner à utiliser @Disabled.

Lorsque j'oubliais comment désactiver une méthode de test, je supprimais l'annotation @Test et renommais le test :

class SkipThisTest {
    void SKIPTHIScanWeAddTwoNumbers(){
        Assertions.fail("this test was skipped and should not run");
    }   
}

Ce n'était pas très bon, mais cela a permis de faire le travail. Je ne disposais pas de quelque chose comme Sensei pour m'aider à me souvenir et j'ai donc eu recours à des modèles de codage médiocres.

Les tâches que j'ai prises en charge pour ce poste sont les suivantes :

• Créez une règle qui recherche les méthodes qui ont été "ignorées" ou "désactivées" en renommant la méthode.
• Créez un QuickFix pour renommer la méthode et ajouter une annotation @Test et @Disabled.

Paramètres de la recette

La première étape que je franchis avec Sensei consiste à "ajouter une nouvelle recette" et à rechercher le modèle de codage sur lequel je souhaite que la recette agisse.

Nom : JUnit : Rendre @Disabled @Test à partir de SKIPTHIS

Courte description : Arrêtez de nommer les méthodes SKIPTHIS, utilisez plutôt @Disabled @Test

Et ma recherche est très simple. J'utilise une expression rationnelle de base pour faire correspondre le nom de la méthode.

search :
method :
name :
matches : "SKIPTHIS.*"

Réglages QuickFix

La solution rapide est un peu plus compliquée parce qu'elle réécrit le code, et j'utiliserai plusieurs étapes pour obtenir mon code final.

J'en ai envie :

• ajouter une annotation @Test à la méthode
• ajouter une annotation @Disabled à la méthode
• modifier le nom de la méthode

L'ajout des annotations est assez simple en utilisant le correctif addAnnotation. Si j'utilise un nom pleinement qualifié pour l'annotation, Sensei ajoutera automatiquement les importations pour moi.

availableFixes :
- name : "Ajouter l'annotation @Disabled et @Test"

  actions :
- addAnnotation :
annotation : "@org.junit.jupiter.api.Test"
- addAnnotation :
annotation : "@org.junit.jupiter.api.Disabled"

Le renommage proprement dit semble un peu plus compliqué, mais j'utilise simplement un remplacement de regex, et la façon générique de le faire avec Sensei est d'utiliser sed dans une action de réécriture.

Comme les actions de réécriture sont des modèles Mustache, Sensei dispose de quelques extensions fonctionnelles dans le mécanisme des modèles. Une fonction est représentée par {{#...}} ; ainsi, pour sed, la fonction est {{#sed}}. La fonction prend deux arguments séparés par des virgules.

Le premier argument est l'instruction sed :

• s/(.*) SKIPTHIS(.*)/$1 $2/

Le second argument est la chaîne de caractères à laquelle appliquer la déclaration sed, qui dans ce cas est la méthode elle-même, et qui est représentée dans les variables Mustache comme suit :

• {{{.}}}

Me donner l'action de réécriture de :

 - réécrire :

       to: "{{#sed}}s/(.*) SKIPTHIS(.*)/$1 $2/,{{{.}}}{{/sed}}"

L'implémentation de sed exige que lorsque les arguments eux-mêmes contiennent des virgules, ils soient enveloppés par {{#encodeString}} et {{/encodeString}} - Par exemple, {{#encodeString}}{{{.}}}{{/encodeString}}

Recette inversée

Comme il s'agit d'un exemple et que nous pourrions vouloir l'utiliser dans des démonstrations, j'ai voulu explorer la manière d'annuler la modification ci-dessus en utilisant une recette Sensei .

En y réfléchissant bien, je veux trouver une méthode annotée avec @Disabled mais seulement dans la classe SkipThisTest où je fais la démo :

Nom : JUnit : demo in SkipThisTest remove @Disabled and revert to SKIPTHIS

Courte description : supprimer @Disabled et revenir à SKIPTHIS à des fins de démonstration dans le projet.

Niveau : avertissement

La recherche de paramètres de recettes est très simple : il s'agit de faire correspondre l'annotation à une classe spécifique.

search :
method :
annotation :
type : "Disabled"
in :
class :
name : "SkipThisTest"

Pour éviter de donner l'impression que le code est une erreur, j'ai défini le paramètre général de la recette comme étant un avertissement. Les avertissements sont mis en évidence dans le code et ne donnent pas l'impression que le code a un problème majeur.

Pour la correction rapide, puisque nous avons fait correspondre la méthode, j'utilise l'action de réécriture et je remplis le modèle à l'aide des variables.

availableFixes :
- name : "Remove Disabled and rename to SKIPTHIS..." (Supprimer le handicap et renommer en SKIPTHIS)

  actions:
  - rewrite:
      to: "{{{ returnTypeElement }}} SKIPTHIS{{{ nameIdentifier }}}{{{ parameterList\
        \ }}}{{{ body }}}"

J'ajoute toutes les variables à l'exception du modificateur (puisque je veux me débarrasser des annotations) et j'ajoute le texte SKIPTHIS dans le modèle.

Cette solution présente la faiblesse qu'en supprimant les modificateurs, je supprime également toutes les autres annotations.

Ajouter une autre action

Je peux ajouter un autre correctif nommé, pour me donner un choix lorsque la touche alt+enter est utilisée pour afficher le QuickFix.

availableFixes :
- name : "Remove Disabled and rename to SKIPTHIS..." (Supprimer le handicap et renommer en SKIPTHIS)

  actions:
  - rewrite:
      to: "{{{ returnTypeElement }}} SKIPTHIS{{{ nameIdentifier }}}{{{ parameterList\
        \ }}}{{{ body }}}"
      target: "self"
- name: "Remove Disabled, keep other annotations, and rename to SKIPTHIS..."

  actions:
  - rewrite:
      to: "{{#sed}}s/(@Disabled\n.*@Test)//,{{{ modifierList }}}{{/sed}}\n\
        {{{ returnTypeElement }}} SKIPTHIS{{{ nameIdentifier }}}{{{ parameterList\
        \ }}}{{{ body }}}"
      target: "self"

Ici, j'ai ajouté une ligne supplémentaire dans le nouveau Quick Fix.

{{#sed}}s/(@Disabled\n.*@Test)//,{{ modifierListe }}}{/sed}}

Elle prend la liste des modificateurs, l'encode sous forme de chaîne, puis utilise sed pour supprimer la ligne avec @Disabled de la chaîne, mais laisse toutes les autres lignes dans le modificateur, c'est-à-dire qu'elle laisse toutes les autres annotations tranquilles.

REMARQUE : N'oubliez pas d'ajouter le "," dans la commande sed, sinon vous verrez un commentaire ajouté à votre aperçu. C'est ainsi que Sensei vous avertit des erreurs de syntaxe dans la commande sed.

/* e.g: {{#sed}}s/all/world/,helloall{{/sed}} */

Appels sed imbriqués

J'ai eu la chance de pouvoir faire correspondre @Disabled et @Test en une seule recherche et un seul remplacement.

Si le code est plus compliqué et que je souhaite avoir une séquence de commandes sed, je peux le faire en les imbriquant :

{{#sed}}s/@Test//,{{#sed}}s/@Disabled\n//,{{{ modifierList }}}{{/sed}}{{/sed}}

Dans l'exemple ci-dessus, j'applique le remplacement @Test aux résultats de l'application du remplacement @Disabled sur la {{ modifierList }}}.

Résumé

sed est un moyen très souple de réécrire du code et il est possible d'imbriquer les appels à la fonction sed pour obtenir des conditions de réécriture complexes.

Les recettes de ce type sont souvent temporaires, car elles servent à améliorer notre processus de programmation. Une fois que nous avons développé notre mémoire musculaire et que nous n'utilisons plus le mauvais modèle de programmation, nous pouvons le supprimer ou le désactiver dans le livre de cuisine.

---

Vous pouvez installer Sensei depuis IntelliJ en utilisant "Preferences \NPlugins" (Mac) ou "Settings \NPlugins" (Windows) puis recherchez simplement "sensei secure code".
Tout le code de ce billet de blog se trouve sur GitHub dans le module `junitexamples` de notre dépôt d'exemples de blogs https://github.com/SecureCodeWarrior/sensei-blog-examples

Migrer vers un enregistreur avec Sensei

Ce billet décrit la création d'une recette pour migrer de System.out.println à l'utilisation d'un logger Java.

‍

‍

Lorsque je bidouille du code, plutôt que d'utiliser le TDD, et que je fais des erreurs, j'ai la mauvaise habitude d'imprimer une ligne dans System.out, et j'ai voulu me débarrasser de cette habitude.

J'ai fait un certain nombre d'erreurs en écrivant le code ci-dessous :

   private String getCountdownString() {
        String output = "";
        String prefix="";
        for(int countdown = 10; countdown > 0; countdown-- ){
            output = output + prefix + countdown;
            System.out.println(output);
            prefix=", ";
        }
        System.out.println(output);
        return output;
    }

Initialement, j'ai écrit countdown++ et la boucle ne s'est pas terminée.

Et j'ai utilisé countdown > 1 donc je n'ai pas obtenu le résultat que je voulais.

Au final, j'ai truffé mon code de System.out.println pour m'aider à déboguer. Et cette expérience m'a conforté dans l'idée que je dois apprendre à utiliser un logger comme approche par défaut.

Recherche

Heureusement, j'ai lu la documentation deSensei et j'ai décidé d'utiliser le guide "Getting Started" pour m'aider à créer une recette pour convertir System.out.println et m'encourager à utiliser un logger :

• java.util.logging.Logger

Création d'une recette

La première chose que je fais est de cliquer sur println puis sur alt+enter pour créer une nouvelle recette.

Je le crée avec les détails suivants :

Nom : Logger : utilisez logger au lieu de println

Description : utiliser logger au lieu de println - n'oubliez pas d'arrêter d'utiliser System.out.println

Niveau : Erreur

Je commencerai par faire correspondre l'appel de méthode avec le nom println

recherche :

  appel de méthode :

    nom : "println"

Et l'aperçu me montre toutes les correspondances dans mon code.

Je peux voir que toutes les correspondances dans mon code sont pour System.out.println mais je ne suis pas sûr qu'à long terme ce sera la seule correspondance. Je veux faire correspondre une déclaration plus qualifiée que je veux modifier.

Je développe le matcheur pour rechercher un appel de méthode sur un champ nommé dans la classe System.

recherche :

  appel de méthode :

    nom : "println"

    "on" :

      domaine :

        en :

          classe :

            nom : "Système"

        nom : "out"

Je pourrais, si je le souhaitais, qualifier complètement le nom du système en java.lang.System

Modification du code pour l'enregistrement

Ensuite, je veux créer le QuickFix.

Tout d'abord, je souhaite modifier la ligne de code qui enregistre la sortie :

les correctifs disponibles :

- name : "use Logger" (utiliser l'enregistreur)

  actions :

  - réécrire :

      to: "logger.log(Level.INFO, {{{ arguments.0 }}})"

Je n'ai pas besoin de me souvenir du format du modèle de moustache. J'ai utilisé la fonction Show Variables de l'interface graphique pour afficher l'argument et j'ai double-cliqué dessus. L'interface graphique a ensuite rempli le modèle de moustache correspondant.

Lorsque je l'essaie, je constate que je dois toujours appuyer sur alt+enter pour importer l'énumération des niveaux. Mais si je modifie mon QuickFix pour avoir un élément pleinement qualifié, alors Sensei ajoutera l'importation pour moi, par exemple.

• Il remplacera System.out.println(output) ; par

logger.log(Level.INFO, output) ;

• Et ajoutez un import pour l'enum :

import java.util.logging.Level ;

• Si je réécris en :

logger.log(java.util.logging.Level.INFO, {{{ arguments.0 }}})

Et cela fonctionnera, mais je devrai toujours me souvenir de la syntaxe pour instancier le logger en premier lieu.

Modification du code pour ajouter le champ logger

Je peux modifier mon QuickFix pour créer le champ pour moi aussi.

Je vais d'abord coder le logger, puis l'ajouter à ma recette pour ne plus avoir à le coder.

Logger logger2 = Logger.getLogger(SysOutTest.class.getName()) ;

J'ai tendance à écrire le code d'exemple que je veux voir généré en premier, car je peux alors utiliser la complétion de code et la vérification syntaxique d'IntelliJ pour m'assurer qu'il est correct. Comme effet secondaire, il sera alors dans l'aperçu du code lorsque j'éditerai la recette pour ajouter les lignes QuickFix qui créeront ce code.

Et lorsque j'écris le code d'exemple, je veux utiliser un nom de champ différent (ici j'utilise logger2) parce que Sensei est assez intelligent pour ne pas ajouter un champ en double, donc je dois le tromper en utilisant un nom différent.

Je vais donc modifier la recette pour créer ce code en ajoutant un champ appelé logger.

les correctifs disponibles :

- name : "use Logger" (utiliser l'enregistreur)

  actions :

  - réécrire :

      to: "logger.log(java.util.logging.Level.INFO, {{{ arguments.0 }}})"

  - addField :

      field: "java.util.logging.Logger logger = Logger.getLogger({{{ containingClass.name\

        \}}.class.getName())"

      cible : "parentClass"

Notez que j'ai modifié SysOutTest pour en faire une variable mustache afin qu'elle prenne le nom de n'importe quelle classe dans laquelle j'utilise cette recette. Et encore une fois, je ne me suis pas souvenu de la syntaxe mustache, j'ai utilisé l'interface graphique Show Variables pour trouver le remplacement dont j'avais besoin.

En qualifiant complètement le Logger de java.util.logging.Logger, Sensei ajoutera l'importation et écrira la ligne de code que je veux, c'est-à-dire

Logger logger = Logger.getLogger(SysOutTest.class.getName()) ;

Une chose utile à propos de cette recette est que, parce qu'elle n'ajoute le champ logger qu'une seule fois, je peux l'utiliser sur n'importe quel code existant où j'ai utilisé `System.out.println` et utiliser Sensei pour changer toutes les occurrences dans mon fichier de code en même temps.

Prochaines étapes

Une fois que je me serai habitué à cela, je finirai par m'entraîner à ne plus utiliser System.out.println.

Je peux utiliser Sensei pour m'aider à écrire du code de manière proactive en créant une deuxième recette qui m'aide à créer un logger.

Par exemple, je peux trouver une classe dans laquelle il n'y a pas de champ appelé logger, et en ajouter un.

Si je crée une recette de niveau Information

Nom : Logger : ajouter un logger

Description : Ajouter un logger à la classe

Pour faire correspondre une classe sans champ d'enregistrement :

recherche :

  classe :

    sans :

      enfant :

        domaine :

          nom : "logger"

Je vais ensuite réutiliser une partie de la correction rapide que nous avons vue plus tôt :

les correctifs disponibles :

  - name : "Ajouter un enregistreur"

    actions :

      - addField :

          field: "java.util.logging.Logger logger = Logger.getLogger({{{ containingClass.name\

        \}}.class.getName())"

          cible : "self"

Notez la différence de cible par rapport à la première correction rapide. Celle-ci utilise self parce que notre Search correspondait à la classe. La première correction rapide utilise parentClass parce que nous avons trouvé du code dans la classe elle-même.

Résumé

Il s'agit de l'un des principaux flux associés à l'utilisation de Sensei pour améliorer vos compétences personnelles en matière de programmation :

• créer une recette pour vous aider à mettre en œuvre votre "meilleure pratique" immédiate
• une fois que vous savez comment utiliser cette meilleure pratique, créez une recette pour accélérer votre flux de travail.

---

Vous pouvez installer Sensei à partir d'IntelliJ en utilisant "Preferences \ Plugins" (Mac) ou "Settings \ Plugins" (Windows) puis en recherchant simplement "sensei secure code".

Le code source et les recettes se trouvent dans le dépôt `sensei-blog-examples` sur le compte GitHub Secure Code Warrior , dans le module `pojoexamples`.

• https://github.com/securecodewarrior/sensei-blog-examples

Partage de livres de cuisine au sein d'une équipe

Lorsqu'une personne crée une recette Sensei pour améliorer la qualité de son code ou sa productivité, tous les membres de l'équipe peuvent en bénéficier lorsque les livres de recettes sont partagés.

Sensei fournit un certain nombre de mécanismes pour le partage des livres de cuisine :

• Stocker les livres de cuisine dans le projet sous contrôle de version
• Stockage des livres de cuisine dans un dossier partagé
• Stocker les livres de cuisine dans Github
• Fichiers zippés sur HTTP(s)

En partageant les livres de recettes, Sensei aide les équipes à collaborer sur le partage des connaissances. Cette collaboration permet d'améliorer la communication et d'intégrer les approches convenues en matière de qualité du code.

Par exemple, partagez un livre de cuisine :

• aide les membres de l'équipe à partager des recettes utiles entre eux.
• aide les chefs d'équipe à codifier les pratiques de codage convenues, à l'intention du personnel subalterne, afin d'identifier les violations courantes et de trouver une solution rapide pour la version convenue. 
• une équipe AppSec pourrait créer des recettes pour mettre en évidence un problème dans le code, et l'équipe de développement pourrait écrire la solution rapide.

Les sections suivantes expliquent comment mettre en œuvre chacun des mécanismes de partage.

Stocker les livres de cuisine dans le projet sous contrôle de version

Le dossier projet .sensei est l'option par défaut lors de la création d'un fichier de livre de cuisine.

• `projet://.sensei`

Tous les livres de cuisine et les recettes seront stockés dans un dossier .sensei dans votre projet.

L'approche la plus simple pour le partage est d'ajouter le dossier projet .sensei au contrôle de version.

Le dossier .sensei peut alors être géré comme n'importe quel autre artefact de code partagé associé au projet. Les livres de cuisine sont stockés sous forme de configuration YAML, ce qui permet de les fusionner facilement au cours des processus de validation et de révision.

C'est l'approche adoptée pour le projet public sensei-blog-examples.

• https://github.com/SecureCodeWarrior/sensei-blog-examples

Le dossier .sensei contient le livre de cuisine avec toutes les recettes, et il est disponible pour tous ceux qui clonent le dépôt.

Stockez vos livres de cuisine dans n'importe quel dossier

Les équipes peuvent également utiliser des livres de cuisine stockés dans des endroits centraux.

L'enregistrement du livre de cuisine dans n'importe quel dossier avec des droits d'écriture partagés permettra à toute l'équipe de mettre à jour les recettes et de les importer dans n'importe quel projet sur lequel elle travaille.

L'emplacement correspond au chemin d'accès au répertoire.

Stocker les recettes dans Github

Sensei peut également accéder aux recettes stockées dans un dépôt Github. Les dépôts privés et publics sont pris en charge.

Github via SSH

L'accès au référentiel SSH est configuré à l'aide de la syntaxe suivante pour l'emplacement

git@github.com:SecureCodeWarrior/acookbook.git

Pour que cela fonctionne, le référentiel doit contenir le contenu d'un dossier de livres de cuisine.

Il est également possible de configurer la branche et le sous-dossier du livre de cuisine, par exemple dans la branche principale, dans le sous-dossier du livre de cuisine.

par exemple

• git@github.com:SecureCodeWarrior/sensei-blog-examples.git|master|.sensei

Une clé SSH doit être configurée pour les dépôts privés.

• https://github.com/settings/keys

La clé ne doit pas comporter de phrase d'authentification.

Github sur HTTPS

Il est également possible d'accéder à des dépôts publics via HTTPS, et la même syntaxe repo.git|branch|folder est utilisée, par exemple.

Pour notre projet d'exemples de blogs :

• https://github.com/SecureCodeWarrior/sensei-blog-examples.git|master|.sensei

Pour notre exemple de protection de base, nous pouvons ignorer la branche et le sous-dossier car nous obtiendrons la branche principale par défaut, et le fichier `rules.sensei` se trouve dans le dossier racine... :

• https://github.com/SecureCodeWarrior/cookbook-basic-protection-set

Zippé sur HTTP(s)

Sensei peut également accéder à des livres de cuisine zippés, via HTTP ou HTTPS.

Par exemple, si j'ai un serveur HTTP qui écoute localement sur le port 8000

• http://localhost:8000/rules.sensei.zip

Le fichier zip du livre de cuisine doit contenir le contenu d'un dossier du livre de cuisine, par exemple le fichier des règles.sensei .

Résumé du partage

Sensei soutient l'utilisation de plusieurs livres de cuisine afin qu'un programmeur individuel puisse disposer de recettes qui soutiennent son propre apprentissage et sa propre productivité.

Plus important encore, nous savons que les équipes travaillent plus efficacement lorsque les connaissances sont partagées. L'existence de référentiels partagés par l'équipe, par exemple pour un projet spécifique, une bibliothèque spécifique ou un ensemble partagé de modèles de migration, peut contribuer à stimuler la productivité de l'équipe et à codifier l'expérience de l'équipe.

Lorsqu'un livre de recettes est partagé, plusieurs équipes peuvent utiliser le même livre de recettes, ce qui peut également améliorer la collaboration entre les équipes de différentes disciplines, par exemple entre l'AppSec et le développement.

Avec les quatre mécanismes de partage disponibles, Sensei a au moins une approche que vous pouvez utiliser pour augmenter la collaboration sur le partage des connaissances.

---

Vous pouvez installer Sensei à partir d'IntelliJ en utilisant "Preferences \ Plugins" (Mac) ou "Settings \ Plugins" (Windows) puis en recherchant simplement "sensei secure code".

Tous les articles du blog Sensei , le code et les recettes sont sur Github :

•  https://github.com/SecureCodeWarrior/sensei-blog-examples

Ce n'est un secret pour personne : à l'adresse Secure Code Warrior , nous croyons fermement au pouvoir de la gamification pour inciter les développeurs à coder en toute sécurité. C'est ce que nous faisons, et les résultats ont été étonnants jusqu'à présent. Mais qu'en est-il de l'utilisation d'un véritable jeu vidéo pour évaluer les nouvelles recrues potentielles ? Est-ce que cela va trop loin, ou est-ce que cela pourrait être une pratique efficace ?

C'est ce que fait la startup Scoutible, et je dois dire que son approche m'intrigue. Scoutible évalue les candidats potentiels à l'aide d'un jeu vidéo - pas des évaluations gamifiées, mais une véritable expérience de jeu vidéo - et vérifie comment la personne se comporte dans certaines situations. Le jeu saisit "des millions de points de données utilisés pour mesurer les différents attributs d'un candidat" pendant seulement 20 minutes de jeu, et utilise ces points de données pour évaluer comment le candidat se comporterait pour le poste en question.

Il y a beaucoup de choses à aimer ici, et beaucoup de choses à apprendre aussi. Le produit est flexible pour répondre aux besoins des clients, et il cible un problème que de nombreuses personnes responsables de l'embauche connaissent depuis longtemps. Les tests autodéclarés assessment, comme Myers-Briggs, ne sont tout simplement pas fiables. Ils vous permettent de "jouer" le système, ou du moins d'essayer de le faire, en n'étant pas entièrement honnête. Dans un jeu, vous avez un objectif et vous devez vous adapter et résoudre des problèmes pour atteindre cet objectif. C'est assez simple et ingénieux si cela fonctionne comme le prétend Scoutible. J'ai hâte d'en savoir plus.

Jeux et gamification

L'approche de Scoutible est logique pour son public cible et son cas d'utilisation. À un moment donné du parcours de Secure Code Warrior, nous avons envisagé la valeur d'une plate-forme de jeu complète ou de mini-jeux intégrés à la formation, mais en fin de compte, cet angle n'a pas ajouté suffisamment de valeur à nos objectifs. Les utilisateurs finaux qui suivent notre formation à la sécurité savent qu'ils sont censés apprendre.

Au sein de notre plateforme Secure Code Warrior , nous mesurons les compétences en codage sécurisé d'un développeur de logiciels tout en utilisant des éléments basés sur le jeu pour maintenir l'intérêt des participants. Cela signifie qu'il faut garder ces questions à l'esprit :

• Comprennent-ils les faiblesses les plus courantes en matière de sécurité des logiciels ?
• Peuvent-ils corriger des bogues de sécurité courants à l'aide de fonctions de sécurité spécifiques au cadre ?
• Ont-ils confiance en leurs compétences en matière de sécurité des logiciels ?
• Quels sont leurs points forts et leurs lacunes en matière de code sécurisé ?

La prise en charge dès la conception

Il y a une autre raison pour laquelle je suis très attaché au produit de Scoutible. Il s'agit d'un avantage non seulement pour l'entreprise qui recrute, mais aussi pour le candidat. Tous les candidats que vous rencontrerez ne sont pas doués pour les entretiens. Pour certains, ce n'est tout simplement pas dans leur personnalité. Pour d'autres, il se peut qu'on ne leur ait jamais enseigné l'art de l'entretien ou qu'ils soient nouveaux sur le marché du travail et qu'il s'agisse de leur premier entretien.

C'est là que je vois une similitude avec les développeurs de logiciels. Malheureusement, de nombreux programmes universitaires ne mettent pas l'accent sur la sécurité. Les développeurs en herbe s'entendent dire : "Vous l'apprendrez sur le tas". Ils quittent l'école en sachant comment faire fonctionner leur code, mais ils perpétuent sans le savoir toutes les vulnérabilités contre lesquelles nous luttons depuis 20 ans ou plus.

Lorsque les développeurs obtiennent ce poste et demandent à se former à la sécurité, ils ont encore moins de temps que lorsqu'ils étaient à l'école. Ils sont payés pour produire des logiciels fonctionnels et efficaces, et la plupart des formations à la sécurité destinées aux développeurs ( courses ) sont ennuyeuses. Soyons honnêtes.

Et si vous pouviez amener vos développeurs, nouveaux et anciens, à se préoccuper de la sécurité sans vraiment y penser ? Comment rendre la formation intéressante, engageante, voire amusante, tout en restant efficace ?

C'est notre défi, et tout comme celui de Scoutible, c'est un défi très réel. Ce n'est pas parce que le problème est extrêmement grave que la solution doit être banale et ennuyeuse. Nous avons déjà essayé. Nous préférons injecter un peu d'amusement, d'excitation, de compétition et d'engagement dans notre solution. Jusqu'à présent, cela a très, très bien fonctionné.

J'ai pensé que si nous pouvions construire un outil qui ressemble à un jeu et qui intègre des tests pour les attributs cognitifs et de personnalité appropriés, nous pourrions résoudre un grand nombre des problèmes que j'ai étudiés.

https://www.inc.com/kevin-j-ryan/scoutible-video-game-reinventing-the-hiring-process.html

Lorsqu'elles sont développées pour la téléphonie mobile, les applications doivent souvent demander des autorisations au système. Elles peuvent avoir besoin d'accéder aux contacts de l'utilisateur, à la connexion Bluetooth ou à la possibilité d'envoyer des messages SMS. Toutes les permissions mentionnées ci-dessus sont des permissions de plateforme, définies par le cadre Android.

Mais dans certains cas, ces autorisations ne suffisent pas et l'application doit définir ses propres autorisations personnalisées. Prenons l'exemple de notre propre entreprise. Secure Code Warrior pourrait créer une application qui enregistre certaines données privées dans le cadre d'un profil, y compris les performances de l'utilisateur sur la plateforme SCW. Nous aimerions permettre à une autre application de formation à la sécurité, par exemple DevTrainer, d'utiliser ces données si l'utilisateur lui en donne l'autorisation. Il s'agit de données sensibles, l'utilisateur ne voudrait certainement pas que n'importe qui les connaisse, mais l'application SCW ne devrait pas complètement les cacher et les protéger car elles pourraient être utiles. Nous souhaitons donc permettre à l'utilisateur d'exercer un contrôle sur ces données. C'est là qu'interviennent les autorisations personnalisées.

Le SCWApp crée une autorisation personnalisée, DevTrainer demande cette autorisation et l'utilisateur peut décider s'il veut l'autoriser ou non. Il s'agit d'une pratique courante et d'un bon moyen de restreindre l'accès aux applications figurant sur la liste blanche.

Malheureusement, les permissions personnalisées présentent certains comportements non intuitifs qui les rendent risquées du point de vue de la sécurité. Concrètement, les autorisations personnalisées peuvent être définies par n'importe quelle application à n'importe quel moment, et "le premier qui gagne", ce qui n'est pas sans conséquences.

Pour le scénario suivant, nous définissons deux profils d'applications que nous avons introduits ci-dessus (toutes ces applications sont fictives à des fins de démonstration) :

1. SCWApp: l'application qui définit une permission personnalisée et défend un composant utilisant cette permission.

2. DevTrainer: cette application définit la même permission que SCWApp et déclare à l'utilisateur qu'elle souhaite détenir cette permission.

Il s'agit d'un scénario courant, appelé "Peer Apps Case" (cas des applications homologues). Si l'application DevTrainer n'était qu'un plugin pour SCWApp, elle n'aurait pas à définir de permission personnalisée. L'hypothèse, dans ce cas, est que SCWApp sera installée avant DevTrainer et qu'aucun comportement inattendu ne se produira. Si, d'une manière ou d'une autre, l'utilisateur installe DevTrainer en premier, il n'est pas informé de la demande d'autorisation. Si l'utilisateur installe ensuite SCWApp, la permission n'est pas accordée rétroactivement à DevTrainer, de sorte que les tentatives d'utilisation du composant sécurisé par l'application DevTrainer échoueront.

C'est là qu'intervient le cas de l'application Peers. Dans certains cas, vous ne pouvez pas vous attendre à ce qu'une application soit installée avant l'autre. Par exemple, si Facebook et Twitter veulent tous deux utiliser les composants de l'autre, ils doivent définir les autorisations personnalisées de l'un et de l'autre.

Cependant, c'est là que les choses se compliquent. Si l'application DevTrainer est installée en premier, l'utilisateur n'est pas informé de sa demande d'autorisation personnalisée. À ce stade, même si l'utilisateur n'a pas été informé, DevTrainer détient l'autorisation personnalisée et peut accéder au composant sécurisé.

La situation est encore plus délicate. L'application DevTrainer peut modifier le niveau de protection des autorisations. Android n'utilise pas le niveau de protection du défenseur, mais le niveau de protection défini en premier, ce qui signifie que l'application installée en premier peut le définir. Cela signifie que si DevTrainer modifie le niveau de protection des permissions pour qu'il devienne normal, toutes les applications futures qui demanderont cette permission n'auront pas à être confirmées par l'utilisateur, mais se verront automatiquement accorder l'accès.

Ce scénario a été inspiré par l'explication de ce problème trouvée sur le github de cwac-security.

La stratégie du "premier qui gagne" a des conséquences dangereuses et la méconnaissance de son comportement peut conduire le développeur à prendre des décisions de sécurité basées sur des données non fiables et à permettre à des applications non souhaitées d'accéder à des données sensibles ou à des services protégés. Pour en savoir plus sur la manière d'éviter les décisions de sécurité basées sur des données non fiables, visitez notre plateforme. Ce comportement a été modifié à partir d'Android 5.0 (Lollipop). Mais comme actuellement, plus de 22% des appareils Android utilisent encore une version inférieure d'Android, il est important d'atténuer les risques du comportement original dans votre application. Vérifiez si la permission a déjà été définie lors de la première exécution de votre application et prenez les mesures appropriées si c'est le cas pour résoudre les risques de sécurité.

Bonne chance pour le codage et à la semaine prochaine !

En définissant des autorisations personnalisées, une application peut partager ses ressources et ses capacités avec d'autres applications.

https://developer.android.com/guide/topics/permissions/defining.html

On parle d'attaque par canal latéral lorsqu'un pirate informatique peut obtenir des informations à partir de la mise en œuvre physique d'un système logiciel plutôt qu'à partir d'une faiblesse théorique dans l'algorithme ou d'un bogue dans le code du logiciel.

Un exemple que j'aime utiliser pour rendre cela plus clair est une façon d'énumérer le nom d'utilisateur. Si vous voulez savoir ce qu'est l'énumération de noms d'utilisateur ou pourquoi c'est mauvais, visitez notre site web pour une explication vidéo ou jouez à un défi pour voir si vous pouvez l'identifier dans le code.

Pour comprendre comment l'énumération des noms d'utilisateur peut être effectuée par le biais d'une attaque par canal latéral, vous devez comprendre comment les mots de passe sont (ou du moins devraient être) traités dans les applications web modernes. Une bonne application web ne connaît pas votre mot de passe, elle ne l'enregistre ni ne le stocke nulle part. Alors comment sait-elle que ce que vous avez tapé est correct et qu'il s'agit bien de votre mot de passe ? Eh bien, votre mot de passe est haché.

Une fonction de hachage est une opération mathématique facile à réaliser dans un sens (bien qu'un peu coûteuse en termes de calcul), mais très difficile à inverser. Lorsque vous vous inscrivez sur un site web, c'est ce hachage qui est stocké en toute sécurité, et non votre mot de passe lui-même. Cela signifie qu'à chaque fois que vous vous connectez, l'application web procède au hachage de votre entrée et compare les résultats du hachage au hachage stocké. Si vous souhaitez en savoir plus sur le stockage sécurisé des mots de passe, vous pouvez le faire sur notre plateforme.

Le hachage des données prend un certain temps sur un ordinateur et les développeurs essaient toujours d'optimiser tout ce qu'ils écrivent pour que les utilisateurs aient une expérience fluide. L'un des moyens d'accélérer le programme est d'ignorer le hachage lorsqu'il n'est pas nécessaire. Par exemple, lorsque le nom d'utilisateur n'existe pas (et donc qu'aucun mot de passe ne doit être vérifié), ils peuvent répondre à l'utilisateur immédiatement. De cette façon, ils peuvent sauter le calcul lent du hachage du mot de passe. Si le nom d'utilisateur est correct, il hachera le mot de passe saisi et le comparera au hachage stocké.

À ce stade, vous avez peut-être deviné où les choses peuvent mal tourner. Même si, en réalité, le hachage ne prend que quelques millisecondes, un pirate peut utiliser ce délai supplémentaire pour savoir si le nom d'utilisateur qu'il a saisi est correct ou non, car un nom d'utilisateur erroné aura une réponse légèrement plus rapide puisque aucun hachage n'a été effectué. Ce type d'attaque par canal latéral est appelé attaque temporelle et constitue un bon exemple de la manière dont différentes exigences non fonctionnelles peuvent se contrecarrer mutuellement. Parfois, un code ne peut pas être à la fois rapide et sûr.

Ainsi, même si les mots de passe sont traités parfaitement et que le message affiché est générique et ne précise pas si le mot de passe ou le nom d'utilisateur est incorrect, le système reste vulnérable. La solution est simple : toujours hacher le mot de passe ou retarder l'envoi de la réponse du temps nécessaire au hachage.

Les informations obtenues peuvent être utilisées par un pirate pour obtenir une liste des utilisateurs du système. Ces informations peuvent être utilisées pour attaquer l'application web, par exemple, par une attaque par force brute ou par nom d'utilisateur/mot de passe par défaut.

https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

La suppression de fichiers sur un système informatique est une opération délicate. Tout le monde, même votre mère, a déjà supprimé un fichier de trop et a été heureux de le retrouver dans la corbeille et de pouvoir le récupérer.

Dans les systèmes informatiques, les données sont représentées par une séquence de bits. Cela signifie que le système doit tenir une comptabilité au sein du système de fichiers pour savoir quels bits représentent quel fichier. Parmi ces informations figurent la taille du fichier, la date de sa dernière modification, son propriétaire, les autorisations d'accès, etc. Ces données comptables sont stockées séparément du contenu du fichier.

En général, lorsqu'un fichier est supprimé, rien ne se passe au niveau des bits représentant le fichier, mais les données comptables sont modifiées de manière à ce que le système sache que cette partie de l'espace de stockage n'a plus de sens et peut être réutilisée. Jusqu'à ce qu'un autre fichier soit enregistré à cet emplacement et que les bits de cet emplacement soient écrasés, vous pouvez souvent encore récupérer les données qui ont été enregistrées. Cela permet non seulement d'accélérer la suppression des fichiers, mais c'est aussi souvent une fonction utile pour annuler la suppression.

Cette approche présente toutefois des inconvénients. Lorsqu'une application sur un système informatique traite des informations sensibles, elle enregistre ces données quelque part sur le système de fichiers. À un moment donné, lorsque les informations ne sont plus nécessaires, ces données peuvent être supprimées. Si aucune précaution supplémentaire n'est prise, ces données peuvent encore être récupérées, même si l'intention du développeur était que toutes les données soient supprimées.

La manière la plus simple d'effacer complètement ces données est de réécrire le contenu du fichier avec des données aléatoires (parfois même plusieurs fois). Il existe plusieurs méthodes de suppression sécurisée des fichiers, qui varient selon les types de stockage et les systèmes de fichiers, comme la méthode Gutmann. Toutefois, pour une utilisation quotidienne, ces méthodes sont un peu excessives et vous pouvez simplement réécrire les données vous-même.

Mais attention ! N'utilisez pas de zéros ou d'autres données à faible entropie. De nombreux systèmes de fichiers peuvent optimiser l'écriture de tels fichiers épars et laisser une partie du contenu original. Il est recommandé de générer des données aléatoires sûres pour écraser l'ensemble du contenu du fichier avant de supprimer le fichier lui-même.

La rémanence des données est la représentation physique résiduelle des données qui ont été effacées d'une manière ou d'une autre. Après l'effacement d'un support de stockage, certaines caractéristiques physiques peuvent permettre de reconstituer les données.

https://fas.org/irp/nsa/rainbow/tg025-2.htm