Contrairement à la plupart des vulnérabilités figurant dans le top 10 des API de l'OWASP, la mauvaise gestion des actifs n'est pas spécifiquement axée sur des défauts de codage. Cette vulnérabilité est plutôt un problème humain ou de gestion qui permet à d'anciennes API de rester en place longtemps après qu'elles aient été remplacées par des versions plus récentes et plus sûres. Elle peut également se produire lorsque des API encore en cours de développement sont exposées à l'environnement de production avant d'avoir été totalement renforcées contre les menaces.

Cette vulnérabilité est particulièrement difficile à gérer en raison de l'avènement des microservices et de l'informatique en nuage. Dans cet environnement, de nouveaux services peuvent être créés rapidement pour répondre à un besoin temporaire, puis oubliés et jamais mis hors service. Si les anciennes API restent connectées à l'environnement de production, cela peut mettre en danger l'ensemble du réseau.

Vous voulez relever un défi ludique sur ce bogue de sécurité ? Entrez dans notre arène : [Commencez ici]

Comment les failles dans la gestion des actifs affectent-elles les API ?

Le défaut de gestion des actifs inappropriés est un produit des temps modernes. Les organisations qui évoluent à la vitesse des affaires peuvent parfois créer des centaines ou des milliers de services et de microservices chaque jour. Cela se fait souvent rapidement et sans la création d'une documentation d'accompagnement, ni d'explication sur l'utilisation des API associées, leur durée d'utilisation ou leur criticité. Cela peut rapidement générer une prolifération d'API qui pourrait devenir incontrôlable avec le temps, surtout s'il n'y a pas de politiques générales en place pour définir la durée d'existence des API.

Dans cet environnement, il est très possible que certaines API soient perdues, oubliées ou jamais mises hors service.

Les utilisateurs autorisés à créer de nouveaux services en dehors du processus normal sont également parfois à blâmer. Par exemple, un groupe de marketing peut créer un service pour aider à soutenir un événement à venir, comme le lancement d'un produit, et ne jamais le retirer une fois l'événement terminé. Quelqu'un qui regarde ce service et ses API associées plus tard peut n'avoir aucune idée de leur raison d'être, et s'il n'y a pas de documentation, cela peut rester un mystère. Elle pourrait ne pas se sentir à l'aise pour supprimer ces API de l'environnement de production ou même pour les mettre à niveau vers des versions plus récentes parce qu'elle n'a aucune idée de leur criticité ou de leur fonction.

La vulnérabilité devient dangereuse parce que la sécurité des API dans les frameworks s'améliore au fil du temps. Un chercheur peut découvrir une vulnérabilité, ou une sécurité supplémentaire peut être ajoutée pour arrêter un type d'attaque de plus en plus populaire. Les anciennes API peuvent rester vulnérables à ces attaques si elles ne sont pas mises à jour, de sorte que les pirates les recherchent souvent ou utilisent des outils automatisés pour les trouver.

Dans un exemple concret fourni par l'OWASP, une entreprise a mis à jour ses API utilisées pour rechercher des bases de données d'utilisateurs afin de corriger une faille critique. Mais elle a laissé les anciennes API en place par erreur.

Un attaquant a remarqué que l'emplacement de la nouvelle API était quelque chose comme (api.criticalservice.com/v2). En remplaçant l'URL par (api.criticalservice.com/v1), il a pu utiliser l'ancienne API avec la vulnérabilité connue. Au final, les données personnelles de plus de 100 millions d'utilisateurs ont été exposées.

Éliminer les failles dans la gestion des actifs

La seule façon d'éliminer le défaut de gestion des actifs inappropriés de votre environnement est de tenir un inventaire rigoureux de toutes les API, de leurs utilisations et de leurs versions. Cela doit commencer par un inventaire des API existantes, en se concentrant sur des facteurs tels que l'environnement dans lequel elles doivent être déployées (production ou développement), les personnes qui doivent y avoir accès via le réseau et, bien sûr, leur version.

Une fois cette étape franchie, vous devez mettre en œuvre un processus dans le cadre duquel une documentation est automatiquement ajoutée à toute nouvelle API ou à tout nouveau service créé. Cette documentation doit porter sur tous les aspects de l'API, y compris la limitation du débit, la manière dont elle traite les demandes et les réponses, le partage des ressources, les points de terminaison auxquels elle peut se connecter, toutes les politiques pertinentes qui s'appliquent, ainsi que tout ce qui sera nécessaire pour les auditer ultérieurement. Vous devez également éviter d'utiliser en production des API qui ne sont pas destinées à la production ou qui proviennent de l'environnement de développement. Envisagez également d'ajouter une limite de temps aux API dont l'utilisation continue doit être justifiée par leurs propriétaires afin d'éviter un déclassement automatique.

Chaque fois que de nouvelles versions d'API actives sont disponibles, effectuez une analyse des risques à l'adresse assessment pour déterminer si vous devez procéder à une mise à niveau et comment le processus doit se dérouler pour éviter de perturber l'environnement de production. Une fois que vous avez migré vers les nouvelles API, supprimez complètement les anciennes de l'environnement.

En faisant tout cela, vous pouvez éviter que la vulnérabilité d'une mauvaise gestion des actifs ne nuise à votre organisation, à vos utilisateurs ou à votre réseau. Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

‍

Un article de blog précédent décrivait l'erreur Java "Bitwise vs Boolean Operator" (opérateur booléen).

• Java Gotchas - Opérateur booléen ou bitwise

Nous avons ajouté une variante de ce problème, ainsi que d'autres problèmes liés à Java, dans un petit quiz amusant intitulé "Challenge The Sensei".

• scw.typeform.com/to/rgw7q7OE

Si vous avez lu l'article de blog ci-dessus, vous êtes en bonne position pour répondre à au moins une des questions.

Mais ce n'est peut-être pas le cas de vos amis. Si vous trouvez le quiz amusant, vous pouvez le partager avec eux et voir s'ils font aussi bien que vous.

Nous ne voulons pas nous contenter de vous poser des questions. Nous voulons essayer d'utiliser ceci pour aider à l'éducation et à la codification des connaissances. Nous avons donc créé un dossier Github qui contient des exemples de code exécutables pour le problème et la solution.

• github.com/SecureCodeWarrior/challenge-the-sensei

Il s'agit d'un Sensei activé.

Lorsque vous clonez le repo et le chargez dans IntelliJ, en supposant que vous ayez installé le plugin Secure Code Warrior Sensei IntelliJ Plugin est installé, il verra automatiquement que vous avez un dossier .sensei , et chargera les recettes Sensei .

Lorsque vous parcourez le code dans l'IDE, IntelliJ devrait vous indiquer que l'erreur existe dans le code, ce qui devrait faciliter la détection de l'erreur dans le code :

• Passez la souris sur le code mis en évidence et vous verrez apparaître un message vous indiquant l'erreur.
• Utilisez la touche Show Context Action : alt+enter (Windows) option+enter (macOS) et nous aurons peut-être un QuickFix disponible pour corriger le code.

Sensei des recettes ont été ajoutées pour :

• Opérateurs binaires
• Diviser l'adresse IP
• Ordre d'affirmation

Nous ajouterons à l'avenir d'autres recettes et d'autres textes explicatifs pour couvrir le reste du code... mais que cela ne vous empêche pas de jeter un coup d'œil au code et de repérer l'erreur par vous-même.

Et n'oubliez pas d'essayer le quiz et de"défier le Sensei".

Java Gotchas - Opérateurs booléens et opérateurs bitwise

> "Java Gotcha" - un modèle d'erreur courant qu'il est facile de mettre en œuvre accidentellement.

Une erreur Java assez simple à commettre accidentellement est l'utilisation d'un opérateur Bitwise au lieu d'un opérateur de comparaison booléen.

Par exemple, une simple erreur de frappe peut conduire à écrire "&" alors que vous vouliez en réalité écrire "&&".

Une heuristique courante que nous apprenons lors de l'examen du code est la suivante :

> Les mots "&" ou "|" utilisés dans une déclaration conditionnelle ne sont probablement pas destinés à être utilisés.

Dans cet article de blog, nous allons explorer l'heuristique et identifier les moyens d'identifier et de corriger ce problème de codage.

Quel est le problème ? Les opérations bitwise fonctionnent bien avec les booléens

L'utilisation des opérateurs Bitwise avec les booléens est parfaitement valide, de sorte que Java ne signale pas d'erreur de syntaxe.

Si je construis un test JUnit pour explorer une table de vérité à la fois pour Bitwise OR (|) et Bitwise AND (&), nous verrons que les sorties de l'opérateur Bitwise correspondent à la table de vérité. Dans ces conditions, nous pourrions penser que l'utilisation des opérateurs bitwise n'est pas un problème.

Table de vérité AND

@Test
    void bitwiseOperatorsAndTruthTable(){
          Assertions.assertEquals(true, true & true);
          Assertions.assertEquals(false, true & false);
          Assertions.assertEquals(false, false & true);
          Assertions.assertEquals(false, false & false);
    }

Le test est réussi, il s'agit d'un Java parfaitement valide.

Table de vérité OR

   @Test
    void bitwiseOperatorsOrTruthTable(){
        Assertions.assertEquals(true, true | true);
        Assertions.assertEquals(true, true | false);
        Assertions.assertEquals(true, false | true);
        Assertions.assertEquals(false, false | false);
    }

Ce test est également réussi, pourquoi préférons-nous "&&" et "||" ?

Les images de la table de vérité ont été créées à l'aide de l'outil outil de table de vérité à partir de web.standfor.edu.

Problème : Fonctionnement en court-circuit

Le vrai problème est la différence de comportement entre les opérateurs binaires (&, |) et booléens (&&, ||).

Un opérateur booléen est un opérateur de court-circuit et n'évalue que ce qui est nécessaire.

par exemple

if (args != null & args.length() > 23) {
    System.out.println(args);
}

Dans le code ci-dessus, les deux conditions booléennes seront évaluées, car l'opérateur Bitwise a été utilisé :

• args != null
• args.length() > 23

Cela expose mon code à une NullPointerException si args est nul car nous allons toujours vérifier la longueur de args, même si args est nul car les deux conditions booléennes doivent être évaluées.

Opérateurs booléens Évaluation des courts-circuits

Lorsqu'un && est utilisé, par exemple

if (args != null && args.length() > 23) {
    System.out.println(args);
}

Dès que nous savons que l'expression args != null est évaluée à false, l'évaluation de l'expression de la condition s'arrête.

Nous n'avons pas besoin d'évaluer le côté droit.

Quel que soit le résultat de la condition du côté droit, la valeur finale de l'expression booléenne sera fausse.

Mais cela ne se produirait jamais dans un code de production

Il s'agit d'une erreur assez facile à commettre, qui n'est pas toujours détectée par les outils d'analyse statique.

J'ai utilisé le Google Dork suivant pour voir si je pouvais trouver des exemples publics de ce modèle :

filetype:java if "!=null & "
Cette recherche a permis de retrouver du code d'Android dans le RootWindowContainer
isDocument = intent != null & intent.isDocument()

C'est le type de code qui pourrait passer un examen de code parce que nous utilisons souvent les opérateurs Bitwise dans les instructions d'affectation pour masquer les valeurs. Mais dans ce cas, le résultat est le même que dans l'exemple de l'instruction if ci-dessus. Si intent est null, une exception NullPointerException sera levée.

Très souvent, nous nous en sortons avec cette construction parce que nous codons souvent de manière défensive et écrivons du code redondant. La vérification de != null peut être redondante dans la plupart des cas d'utilisation.

Il s'agit d'une erreur commise par les programmeurs dans le code de production.

Je ne sais pas si les résultats de la recherche sont à jour, mais lorsque j'ai lancé la recherche, j'ai obtenu des résultats avec du code provenant de Google, Amazon, Apache... et de moi.

Une récente demande d'extension sur l'un de mes projets open source visait à résoudre exactement cette erreur.

if(type!=null & type.trim().length()>0){
    acceptMediaTypeDefinitionsList.add(type.trim());
}

Comment le trouver

Lorsque j'ai vérifié mon exemple de code dans quelques analyseurs statiques, aucun d'entre eux n'a détecté ce code d'autodestruction caché.

L'équipe de Secure Code Warrior a créé et examiné une recette assez simple de Sensei qui pourrait répondre à ce besoin.

Les opérateurs Bitwise étant parfaitement valables et souvent utilisés dans les affectations, nous nous sommes concentrés sur l'utilisation des instructions if et sur l'utilisation de Bitwise &, pour trouver le code problématique.

search:
  expression:
    anyOf:
    - in:
        condition: {}
    value:
      caseSensitive: false
      matches: ".* & .*"

Cette fonction utilise une expression régulière pour faire correspondre " & " lorsqu'elle est utilisée comme expression de condition, par exemple dans une instruction if.

Pour y remédier, nous nous sommes à nouveau appuyés sur les expressions régulières. Cette fois-ci, nous avons utilisé la fonction sed de QuickFix pour remplacer globalement le & de l'expression par &&.

availableFixes:
  - name: "Replace bitwise AND operator to logical AND operator"
    actions:
      - rewrite:
          to: "{{#sed}}s/&/&&/g,{{{ . }}}{{/sed}}"

Notes de fin

Cela couvre l'utilisation abusive la plus courante d'un opérateur bitwise, c'est-à-dire lorsqu'un opérateur booléen était en fait prévu.

Il existe d'autres situations où cela pourrait se produire, par exemple dans l'exemple de l'affectation, mais lorsque nous écrivons des recettes, nous devons essayer d'éviter les identifications faussement positives, faute de quoi les recettes seront ignorées ou désactivées. Nous élaborons des recettes qui correspondent aux occurrences les plus courantes. Au fur et à mesure de l'évolution de Sensei , nous pourrons ajouter des spécificités supplémentaires à la fonctionnalité de recherche afin de couvrir davantage de conditions de correspondance.

Dans sa forme actuelle, cette recette permettrait d'identifier de nombreux cas d'utilisation en direct, et surtout celui qui a été rapporté dans le cadre de mon projet.

NOTE : Quelques guerriers du code ont contribué à cet exemple et à la révision de la recette - Charlie Eriksen, Matthieu Calie, Robin Claerhaut, Brysen Ackx, Nathan Desmet, Downey Robersscheuten. Merci pour votre aide.

---

Vous pouvez installer Sensei à partir d'IntelliJ en utilisant "Préférences \NPlugins" (Mac) ou "Paramètres \NPlugins" (Windows) puis en recherchant "sensei secure code".

Nous avons beaucoup de code source et de recettes pour ces articles de blog (y compris celui-ci) dans le dépôt `sensei-blog-examples` dans le compte GitHub Secure Code Warrior .

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

En savoir plus sur Sensei

Qu'est-ce que l'analyse statique ?

L'analyse statique est l'analyse automatisée du code source sans exécuter l'application.

Lorsque l'analyse est effectuée pendant l'exécution du programme, on parle d'analyse dynamique.

L'analyse statique est souvent utilisée pour détecter :

• Vulnérabilités en matière de sécurité.
• Problèmes de performance.
• Non-respect des normes.
• Utilisation de concepts de programmation obsolètes.

Comment fonctionne un outil d'analyse statique ?

Le concept de base commun à tous les outils d'analyse statique consiste à rechercher dans le code source des schémas de codage spécifiques auxquels est associée une sorte d'avertissement ou d'information.

Cela peut être aussi simple que "Les classes de test de JUnit 5 n'ont pas besoin d'être 'publiques'". Ou quelque chose de plus complexe à identifier comme "Une entrée de chaîne non fiable est utilisée dans une instruction d'exécution SQL".

Les outils d'analyse statique varient dans la manière dont ils mettent en œuvre cette fonctionnalité.

• pour créer un arbre syntaxique abstrait (AST),
• la recherche d'expressions régulières dans le texte,
• une combinaison de ce qui précède.

La recherche d'expressions régulières dans le texte est très souple, il est facile d'écrire des règles de correspondance, mais elle peut souvent donner lieu à un grand nombre de faux positifs et les règles de correspondance ne tiennent pas compte du contexte du code environnant.

La correspondance AST traite le code source comme un code de programme, et non comme un simple fichier rempli de texte, ce qui permet une correspondance plus spécifique et contextuelle et peut réduire le nombre de faux positifs signalés par rapport au code.

L'analyse statique dans l'intégration continue

L'analyse statique est souvent réalisée au cours du processus d'intégration continue (CI) afin de générer un rapport sur les problèmes de conformité qui peut être examiné afin d'obtenir une vue objective de la base de code au fil du temps.

Certaines personnes utilisent l'analyse statique comme mesure objective de la qualité de leur code en configurant l'outil d'analyse statique de manière à ce qu'il ne mesure que des parties spécifiques du code et ne rende compte que d'un sous-ensemble de règles.

L'objectivité est assurée par les règles utilisées puisqu'elles ne varient pas dans leur évaluation du code au fil du temps. Il est clair que la combinaison des règles utilisées et leur configuration est une décision subjective et que différentes équipes choisissent d'utiliser différentes règles à différents moments.

Il est utile que l'analyse statique soit effectuée dans le cadre de l'IC, mais cela risque de retarder le retour d'information au programmeur. Les programmeurs ne reçoivent pas de retour d'information lorsqu'ils codent, mais plus tard, lorsque le code est soumis à l'outil d'analyse statique. Un autre effet secondaire de l'exécution de l'analyse statique en IC est qu'il est plus facile d'ignorer les résultats.

Pour aider les équipes à prêter davantage attention aux résultats de l'analyse statique, il est généralement possible de configurer un seuil métrique dans le processus de construction, afin de faire échouer la construction si le seuil est dépassé, par exemple si un certain nombre de règles sont déclenchées.

Analyse statique dans l'IDE

Pour recevoir un retour d'information plus rapidement, il existe de nombreux plugins IDE qui exécutent les règles d'analyse statique dans l'IDE à la demande, ou périodiquement lorsque le code est modifié.

Les violations de règles sont alors visibles dans l'IDE lorsque le programmeur écrit du code, et pour rendre les règles plus difficiles à ignorer, les violations peuvent souvent être configurées pour être affichées sous forme de code souligné dans l'éditeur.

Personnellement, je trouve que c'est un moyen utile d'améliorer mon codage, en particulier lorsque je travaille avec une nouvelle bibliothèque couverte par l'outil d'analyse statique. Bien qu'il puisse être "bruyant" avec des faux positifs ou des règles qui ne vous intéressent pas, cela peut être résolu en prenant une mesure supplémentaire pour configurer l'outil d'analyse statique afin d'ignorer les règles. Mais vous pouvez résoudre ce problème en prenant la peine de configurer l'outil d'analyse statique pour qu'il ignore certaines règles.

Correction du code sur la base des règles de l'analyse statique

Avec la plupart des outils d'analyse statique, la correction de la règle est laissée au programmeur, qui doit donc comprendre la cause de la violation de la règle et la manière de la corriger.

Très peu d'outils d'analyse statique offrent également la possibilité de corriger les violations, car la correction est souvent liée au contexte de l'équipe, à la technologie utilisée et aux styles de codage convenus.

Règles par défaut

Une fausse confiance dans la qualité des règles peut survenir lorsque les outils d'analyse statique sont livrés avec des règles par défaut, il est tentant de croire qu'elles couvrent tous les problèmes qu'un programmeur pourrait rencontrer, et toutes les circonstances dans lesquelles une règle devrait s'appliquer. Parfois, les circonstances dans lesquelles une règle devrait s'appliquer peuvent être subtiles et ne pas être faciles à détecter.

L'espoir est qu'en utilisant un outil d'analyse statique et en recherchant plus en détail les règles et les violations, les programmeurs développeront les compétences nécessaires pour détecter et éviter le problème dans le contexte de leur domaine spécifique.

Lorsque le domaine nécessite des règles contextuelles, les outils d'analyse statique peuvent ne pas proposer de règles correspondant à votre domaine ou à votre bibliothèque et, en outre, les outils peuvent souvent être difficiles à configurer et à développer.

Gênes

Aucun de ces "inconvénients" n'est insurmontable :

• faux positifs
• l'absence de correctifs
• configuration pour ignorer les règles
• ajouter des règles spécifiques au contexte

Mais elles sont souvent utilisées comme excuses pour éviter d'utiliser les outils d'analyse statique, ce qui est dommage car l'analyse statique peut être extrêmement utile, en tant que moyen d'améliorer la qualité de l'information :

• mettre en évidence de meilleures approches pour les développeurs débutants
• obtenir un retour d'information rapide sur les violations claires du code
• identifier des problèmes obscurs que le programmeur n'a jamais rencontrés auparavant
• renforcer le fait que le programmeur a adopté une bonne approche de codage (lorsqu'aucune violation n'est signalée)

Outils d'analyse statique basés sur les IDE

En tant que contributeur individuel à un projet, j'aime utiliser des outils d'analyse statique qui s'exécutent à partir de l'IDE afin de recevoir rapidement un retour d'information sur mon code.

Cela complète le processus d'examen des demandes d'extraction et l'intégration de l'IC qu'un projet peut avoir.

J'essaie d'identifier les outils qui me donneront une longueur d'avance et qui amélioreront mon flux de travail individuel.

Lorsque des outils fonctionnent dans l'IDE, il peut être tentant de les considérer comme interchangeables, car ils ont tendance à partager la même interface graphique de base et la même approche de configuration.

Les outils peuvent avoir des fonctionnalités ou des ensembles de règles qui se chevauchent, mais pour en tirer le meilleur parti, j'installe plusieurs outils afin de tirer parti de leurs points forts.

Les outils IDE d'analyse statique que j'utilise activement lors du codage sont énumérés ci-dessous :

• les inspections intégrées d'IntelliJ - les modèles de codage courants
• SpotBugs - erreurs courantes
• SonarLint - modèles d'utilisation courants
• CheckStyle - modèles de style courants
• Sensei à partir de Secure Code Warrior - création de règles personnalisées

Je les utilise tous parce qu'ils fonctionnent bien ensemble et se complètent mutuellement.

IntelliJ Inspections

Si vous utilisez IntelliJ, vous utilisez déjà leurs inspections.

Il s'agit de règles d'analyse statique qui sont signalées dans l'IDE. Certaines d'entre elles ont également des options QuickFix pour réécrire le code afin de résoudre le problème.

Les règles peuvent être configurées pour être activées ou désactivées, et pour choisir le niveau d'erreur utilisé pour le mettre en évidence dans l'IDE.

Il y a beaucoup de bonnes inspections IntelliJ. Je le sais parce que je les ai lues pendant que j'écrivais ces lignes. J'utilise les Inspections IntelliJ par défaut et je ne les ai pas configurées, mais pour tirer pleinement parti des Inspections, vous devriez les lire, identifier celles qui sont pertinentes pour votre style de codage, et configurer le niveau d'avertissement de manière à ce que vous les remarquiez dans le code.

L'avantage des inspections IntelliJ est qu'elles sont fournies gratuitement avec l'IDE et qu'elles aident à construire la mémoire musculaire de l'utilisateur :

• remarquer les avertissements et les erreurs dans le code source au fur et à mesure que vous écrivez le code
• le passage de la souris sur le code signalé pour connaître les violations des règles
• utiliser alt+enter pour appliquer une solution rapide au problème

SpotBugs

Le plugin SpotBugs IntelliJ utilise l'analyse statique pour essayer de vous alerter sur les bogues dans votre code.

SpotBugs peut être configuré à partir des Préférences d'IntelliJ pour analyser votre code, les règles utilisées peuvent être trouvées dans l'onglet Détecteur.

J'ai tendance à utiliser SpotBugs après avoir écrit et revu mon code, puis je lance l'option "Analyser les fichiers du projet, y compris les sources de test".

Cela m'aide à identifier les bogues, le code mort et les optimisations évidentes. Cela m'oblige également à faire des recherches sur certaines des violations signalées pour m'aider à décider de ce qu'il faut faire.

SpotBugs détecte les problèmes mais ne propose pas d'actions QuickFix pour tenter de les résoudre.

SpotBugs est facile à configurer et je le considère comme un second avis objectif utile à consulter dans mon IDE.

SonarLint

Le plugin SonarLint.

SonarLint peut être configuré à partir des préférences d'IntelliJ pour sélectionner les règles sur lesquelles le code est validé.

Par défaut, SonarLint fonctionne en temps réel et affiche les problèmes liés au code que vous êtes en train d'éditer.

SonarLint ne propose pas de solutions rapides, mais la documentation associée aux rapports de violation est généralement claire et bien documentée.

J'ai trouvé SonarLint utile dans le passé pour m'alerter sur les nouvelles fonctionnalités de Java que je connaissais dans les versions plus récentes de Java.

CheckStyle

Le plugin CheckStyle propose un mélange de règles de formatage et de qualité de code.

Le plugin CheckStyle est fourni avec "Sun Checks" et "Google Checks".

Vous pouvez facilement en trouver la définition en ligne.

CheckStyle apporte la plus grande valeur ajoutée lorsqu'un projet a pris le temps de créer son propre ensemble de règles. Le plugin de l'IDE peut alors être configuré pour utiliser ce jeu de règles et les programmeurs peuvent effectuer une analyse, avant de livrer le code à l'IC.

CheckStyle est très souvent utilisé comme plugin d'échec de construction pour les processus de CI lorsque le nombre de violations de CheckStyle dépasse un seuil.

Sensei

Sensei utilise l'analyse statique basée sur un arbre syntaxique abstrait (AST) pour faire correspondre le code et pour créer des corrections rapides, ce qui permet une identification très spécifique du code présentant des problèmes.

L'AST permet aux QuickFix associés à une recette de comprendre le code environnant. Par exemple, lors de l'ajout d'une nouvelle classe dans le code, toute importation pour cette classe ne sera ajoutée au fichier source qu'une seule fois, et non pour chaque remplacement.

Sensei a été créé pour faciliter l'élaboration de règles de correspondance personnalisées qui n'existent pas ou qui seraient difficiles à configurer dans d'autres outils. 

Plutôt que de modifier un fichier de configuration, toute la configuration peut être effectuée dans l'interface graphique. Lors de la création de nouvelles recettes, l'interface graphique permet de voir facilement à quel code la recette correspond. Et lors de la définition des QuickFixes, l'état avant et après du code peut être comparé immédiatement. Il est ainsi plus facile de créer des recettes très contextuelles, c'est-à-dire propres à une équipe, à une technologie ou même à un programmeur.

J'utilise Sensei en combinaison avec d'autres outils d'analyse statique. Par exemple, la plupart des outils d'analyse statique trouvent des problèmes, mais ne les résolvent pas. Un cas d'utilisation courant de Sensei est de reproduire la recherche correspondante de l'autre outil dans Sensei, et de l'étendre avec une correction rapide. L'avantage est que la correction personnalisée appliquée répond déjà aux normes de codage de votre projet.

Je me retrouve périodiquement à créer des recettes Sensei qui existent déjà dans le jeu IntelliJ Intensions parce que le rapport Intension ne correspond pas tout à fait au contexte que j'ai créé ou parce que le QuickFix fourni par IntelliJ ne correspond pas au modèle de code que je veux utiliser.

Je renforce les outils existants, plutôt que de tenter de les remplacer complètement.

Sensei peut également être très utile lorsque vous identifiez une variante contextuelle d'une règle commune, par exemple si vous utilisez une bibliothèque SQL non prise en charge par l'outil d'analyse statique, mais que les règles SQL communes du moteur d'analyse statique s'appliquent toujours, vous pouvez alors créer des variantes spécifiques à la bibliothèque de ces règles à l'aide de Sensei.

Sensei n'est pas livré avec un grand nombre de recettes génériques comme les outils d'analyse statique mentionnés, sa force est de rendre facile la création de nouvelles recettes, avec des QuickFixes configurés pour correspondre à votre style de codage spécifique et à vos cas d'utilisation.

NOTE : nous travaillons sur un référentiel public de recettes pour couvrir les cas d'utilisation génériques. vous pouvez le trouver ici.

Résumé

J'ai tendance à choisir des outils qui fonctionnent ensemble, qui sont configurables et faciles à étendre pour répondre à mon contexte spécifique. J'utilise des outils d'analyse statique dans l'IDE depuis des années pour m'aider à identifier les problèmes et en apprendre davantage sur les langages de programmation et les bibliothèques que j'utilise.

J'utilise tous les outils mentionnés en combinaison :

• IntelliJ Intentions permet de signaler les problèmes de code les plus courants dès la sortie de la boîte, souvent avec des solutions rapides associées.
• SpotBugs trouve des bogues simples que j'aurais pu manquer et me signale des problèmes de performance.
• SonarLint identifie des fonctionnalités Java dont je n'étais pas conscient et m'incite à trouver d'autres façons de modéliser mon code.
• CheckStyle m'aide à me conformer à un style de codage convenu qui est également appliqué pendant l'IC.
• Sensei m'aide à créer des QuickFixes pour améliorer les scénarios courants trouvés par les outils d'analyse statique et à créer des recettes spécifiques à un projet ou à une technologie qui peuvent être difficiles à configurer dans un autre outil.

---

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

Vous pouvez trouver un dépôt de code d'exemple et de recettes pour des cas d'utilisation courants sur le compte GitHub Secure Code Warrior , dans le projet `sensei-blog-examples`.

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

En savoir plus sur Sensei

Le projet Sensei lui-même possède son propre ensemble de recettes qui se sont développées au fil du temps. Ce billet de blog est un exemple d'un des scénarios pour lesquels l'équipe de Sensei a construit une recette. Une mauvaise configuration de Guice, qui a conduit à une NullPointerException signalée lors de l'exécution pendant les tests.

Cela peut être généralisé à de nombreux scénarios d'injection de dépendances où le code est syntaxiquement correct, mais où une erreur s'est glissée parce que la configuration du câblage était incorrecte.

Cela arrive souvent lorsque nous apprenons la technologie et que nous commettons la simple erreur d'oublier de câbler les choses. Mais cela arrive aussi aux professionnels expérimentés parce que, eh bien... nous faisons tous des erreurs, et nous n'avons peut-être pas de tests unitaires pour tout couvrir.

Exceptions au moment de l'exécution dues à un câblage incorrect de l'injection de dépendances

Le code ci-dessous échoue à l'exécution avec une NullPointerException.

‍

injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());

Le code est syntaxiquement correct, mais il échoue parce que nous avons omis une requestStaticInjection dans notre configuration SystemOutModule.

‍

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
    }
}

Lorsque nous essayons d'utiliser le rapporteur, créé à l'aide de l'injecteur, il n'est pas complètement instancié et nous recevons une NullPointerException lorsque nous appelons reportThisMany.

Il se peut que nous l'ayons manqué lors de notre revue de code, ou que nous n'ayons pas eu de tests unitaires déclenchant l'injection de dépendance, et qu'elle se soit glissée dans notre construction.

‍

Signes d'alerte

Dans ce cas, il y a un signe d'avertissement, le CountReporter a un champ statique annoté avec @Inject mais... la classe CountReporter elle-même est un paquet privé.

Dans une base de code complexe, cela pourrait être un signe d'avertissement que le code est incorrect, car la classe Module qui configure les liaisons doit se trouver dans le même paquet pour que cela fonctionne.

‍

class CountReporter {
    @Inject
    private static ILineReporter reporter;

Une autre erreur que nous avons commise, et que nous aurions pu relever lors d'un examen du code, est que nous avons oublié de lier les champs dans la méthode de configuration de SystemOutModule.

binder().requestStaticInjection(CountReporter.class) ;

Si nous avions écrit le code requestStaticInjection, l'erreur de syntaxe générée lors de la tentative d'utilisation du CountReporter nous aurait alertés sur cette simple erreur.

> 'reporters.CountReporter' n'est pas public dans 'reporters'. Il n'est pas possible d'y accéder depuis l'extérieur du paquet

‍

Malheureusement. Nous avons oublié, et il n'y avait pas de signes syntaxiques dans le code.

Comment Sensei peut-il vous aider ?

Nous n'utiliserions probablement pas Sensei pour récupérer la requestStaticInjection manquante car tout notre câblage de configuration Guice devrait utiliser cette méthode, et nous ne pouvons pas garantir que tout le câblage sera aussi simple que ce cas d'utilisation.

Nous pourrions écrire une règle Sensei pour rechercher des signes d'alerte indiquant que notre code n'est pas à la hauteur.

Dans le cas présent, cela signifie :

• Recherchez les classes dont les champs sont annotés @Inject
• Lorsque les cours ne sont pas publics.

Ce qui précède était le signe d'avertissement qu'il était peu probable qu'ils aient été câblés.

En créant une recette, nous aurons un signe d'alerte précoce, pendant le codage, et nous réduirons la dépendance à l'égard de nos pull requests ou de la résolution de notre dette technologique pour nous permettre d'ajouter des tests unitaires.

Comment créer une recette ?

La tâche que je souhaite accomplir est la suivante :

• Créez une recette qui fait correspondre les champs annotés avec @Inject qui se trouvent dans des classes privées protégées.

Cela devrait nous permettre d'identifier les modules qui l'utilisent et d'ajouter le code de câblage manquant.

Dans ma classe CountReporter, j'utiliserai Alt+Enter pour créer une nouvelle recette et je partirai de zéro.

Je vais lui donner un nom et ajouter une description :

Nom : Guice : Injected Field Not Public
Description : Si le champ injecté n'est pas public, il se peut que le code ne soit pas câblé au niveau
: Avertissement

La recherche que j'écris cherche une classe avec un champ annoté comme Inject mais qui n'a pas été scopé comme public.

search :
field :
with :
annotation :
type : "com.google.inject.Inject"
in :
class :
without :
modifier : "public"

Fixer

Le QuickFix de la recette modifiera la classe injectée en changeant la portée. Mais ce n'est pas le seul code que je dois modifier.

les correctifs disponibles :

- name : "Change class to public. N'oubliez pas de demander l'injection de cette classe"
actions :
- changeModifiers :
visibility : "public"
target : "parentClass"

Lorsque la recette est déclenchée, il me reste une étape manuelle à effectuer dans mon code, en ajoutant la ligne contenant requestStaticInjection pour instancier complètement l'objet.

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
        // instantiate via dependency injection
        binder().requestStaticInjection(CountReporter.class);
    }
}

Je pourrais éventuellement écrire une autre recette pour reprendre cela. Je ne le ferais probablement pas si l'oubli de l'injection statique ne devenait pas une erreur semi-régulière que je commettais en codant.

‍

Résumé

S'il nous arrive de commettre une erreur dont la racine est commune, Sensei peut nous aider à codifier les connaissances relatives à la détection et à la résolution du problème, avec l'espoir qu'il ne passera pas au travers des révisions de code et ne se retrouvera pas en production.

Parfois, les recettes que nous écrivons identifient des modèles heuristiques, c'est-à-dire que leur correspondance ne garantit pas l'existence d'un problème, mais il est probable qu'il y en ait un.

De même, les recettes et les solutions rapides que nous écrivons n'ont pas besoin d'être exhaustives, elles doivent être suffisamment bonnes pour nous aider à identifier et à résoudre les problèmes sans être trop compliquées. En effet, lorsqu'elles deviennent trop compliquées, elles deviennent plus difficiles à comprendre et à maintenir.

---

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 de ce billet se trouvent dans le dépôt `sensei-blog-examples` du compte GitHub Secure Code Warrior , dans le module `guiceexamples`.

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

En savoir plus sur Sensei

Modification de la visibilité des méthodes et des classes pour JUnit 5

L'une des joies de la programmation est l'apprentissage constant nécessaire pour rester à jour. L'un des problèmes est que nous développons une familiarité et des schémas d'utilisation qui peuvent avoir un impact sur l'adoption de nouvelles approches. Sensei peut aider à la migration en identifiant les schémas obsolètes et en nous indiquant le correctif à utiliser pour aller de l'avant.

Par exemple, lorsque j'ai migré de JUnit 4 à JUnit 5, j'avais l'habitude d'écrire toutes mes classes et méthodes de test en tant que publiques. Mais avec JUnit 5, elles peuvent être privées.

par exemple, au lieu de :

public class Junit5VisibilityTest {
    @Test
    public void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}

J'ai vraiment envie d'écrire :

class Junit5VisibilityTest {
    @Test
    void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}

Il m'a fallu un certain temps pour acquérir la mémoire musculaire nécessaire pour coder ainsi, et je commets encore des erreurs de temps à autre.

L'utilisation Sensei

Avec Sensei , je peux créer des recettes qui trouvent les méthodes et les classes publiques et modifient automatiquement les déclarations pour les rendre privées.

Pour ce faire, j'ai créé une recette :

Nom - JUnit : Les méthodes de test de JUnit 5 n'ont pas besoin d'être publiques
Description - Les méthodes de test de JUnit 5 n'ont pas besoin d'être publiques
Niveau - Erreur

Je l'ai classé comme erreur parce que je veux éradiquer cette pratique de codage et je veux une plus grande visibilité du problème lorsque j'écris du code dans l'IDE.

Modification de la déclaration de classe

Pour trouver les classes, je recherche toute classe qui a une annotation enfant de @Test dans Junit 5, c'est-à-dire org.junit.jupiter.api.Test.

Et lorsque la classe a le modificateur public :

search :
class :
with :
child :
annotation :
type : "org.junit.jupiter.api.Test"
modifier : "public"

Ensuite, la solution rapide modifie le modificateur pour supprimer la visibilité afin qu'il devienne la valeur par défaut, et la valeur par défaut est package private, ce qui est ce que je recherche.

availableFixes :
- name : "remove public visibility from JUnit 5 Test class"
actions :
- changeModifiers :
visibility : ""

Modifier les déclarations de méthode

La recette de l'amendement de la déclaration de méthode est à peu près la même que celle de la classe.

Tout d'abord, je recherche les méthodes publiques annotées avec @Test dans JUnit 5.

search :
method :
annotation :
type : "org.junit.jupiter.api.Test"
modifier : "public"

Je modifie ensuite le modificateur pour qu'il devienne la visibilité par défaut.

availableFixes :
- name : "Remove @Test method public visibility"
actions :
- changeModifiers :
visibility : ""

Conseil : modification de plusieurs méthodes

Sensei a la possibilité d'appliquer la correction rapide à toutes les violations du fichier en cours.

Lorsque j'utilise alt+enter pour appliquer le QuickFix.

Si je développe le menu du nom QuickFix, je peux voir une option pour :

"Fix All : 'JUnit : Les méthodes de test de JUnit 5 n'ont pas besoin d'être publiques' dans le fichier"

Lorsque je sélectionne cette option, Sensei modifie toutes les occurrences du problème, et pas seulement celle que je sélectionne.

Modifier la classe

De même qu'une méthode n'a pas besoin d'être publique, la classe n'a pas besoin de l'être non plus.

Je peux créer une recette et un QuckFix pour modifier la classe.

Nom - JUnit : Junit 5 Test classes do not need to be public
Description - Junit 5 Test classes do not need to be public
Niveau - Erreur

Lorsque je trouve une classe qui est publique et qui a une méthode avec une annotation @Test. Je souhaite alors modifier la visibilité.

search :
class :
modifier : "public"
anyOf :
- child :
method :
annotation :
type : "Test"

Je peux à nouveau modifier la définition de la classe à l'aide de l'action changeModifiers.

availableFixes :
- name : "Remove @Test class public visibility"
actions :
- changeModifiers :
visibility : ""

Résumé

Un outil d'analyse statique m'a initialement alerté sur cette approche recommandée dans JUnit. Mais l'outil d'analyse statique ne m'a pas aidé à développer la mémoire musculaire nécessaire pour modifier mon code au fur et à mesure que je programme.

Utilisez le "niveau" pour vous alerter. Lorsqu'il s'agit d'un problème que j'essaie d'éliminer de mon codage, je commence par le mettre à "Erreur", puis je le réduis au fur et à mesure que je me désintéresse de l'approche du codage.

N'oubliez pas que vous pouvez utiliser Sensei pour corriger tous les problèmes du fichier actuel en même temps, en utilisant l'option du menu déroulant lors de l'application de la correction rapide.

En créant une recette Sensei , je peux voir mon ancienne approche de codage en temps réel. Et la corriger rapidement, pour renforcer l'approche si je commets parfois des erreurs de codage.

---

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 `junitexamples`.

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

Ajout automatique d'un constructeur privé avec Sensei

Dans une classe utilitaire, lorsque les champs et les méthodes sont statiques, il n'y a pas de raison évidente de l'instancier.

Par exemple, UtilityClass utility = new UtilityClass() ;

Le code ci-dessous est une implémentation simple d'une classe Utility.

public class UtilityClass {
    public static final Boolean ULTIMATE_TRUTH = true;
    public static boolean getTrue(){
        return ULTIMATE_TRUTH;
    }
}

C'est le type de schéma de codage que les outils d'analyse statique peuvent détecter, mais ils n'offrent souvent pas la possibilité de résoudre le problème.

Je peux utiliser Sensei pour identifier le modèle de codage et générer automatiquement un constructeur privé pour m'empêcher d'instancier la classe.

Recherche de la classe

Je vais ajouter une nouvelle recette sur la classe utilitaire appelée :

•  Classes statiques : créer un constructeur privé.

Dans un premier temps, je vais créer un matcheur simple pour rechercher une classe.

recherche :

  class: {}

Cela correspondra à n'importe quelle classe, ce qui est suffisant pour me permettre de commencer à écrire une solution rapide. Une fois que j'aurai trouvé une solution rapide qui fonctionne, j'affinerai la recherche pour qu'elle mette en évidence les classes qui ont le plus de chances d'avoir un constructeur privé.

Correction rapide

Pour la solution rapide, je souhaite générer un constructeur privé.

Dans la classe d'exemple, cela se traduirait par

   private UtilityClass(){}

Pour ajouter le code ci-dessus à ma classe, ma solution rapide ajoutera une méthode, et le nom de la méthode sera un modèle Mustache qui utilise le nom de la classe.

les correctifs disponibles :

- name: "add private constructor"
  actions:
  - addMethod:
      method: "private {{{ name }}}(){}"

Dans l'éditeur graphique, j'utilise l'option Afficher les variables pour créer le modèle Moustache, puis je modifie le champ pour ajouter le modificateur privé, les crochets et les accolades afin que la syntaxe soit correcte.

Cela me permet d'ajouter un constructeur privé à n'importe quelle classe.

L'aperçu QuickFix m'aide car je peux voir le code généré pendant que j'écris le modèle Mustache.

Maintenant que je le sais, je peux résoudre le problème. J'affinerai les conditions de recherche pour afficher la recette au moment le plus approprié.

Recherche des constructeurs manquants

Idéalement, je ne veux pas créer une recette qui signale une erreur pour chaque classe. J'ajouterai donc quelques conditions supplémentaires dans la recherche afin de ne faire correspondre que les classes qui n'ont pas de constructeur.

recherche :

  classe :
sans :
enfant :
méthode :
constructeur : true

Le YAML est légèrement différent de l'interface graphique.

Dans l'interface graphique, je la configure pour qu'elle recherche une classe sans méthode enfant, c'est-à-dire un constructeur "oui". Nous utilisons "yes" dans l'interface graphique au lieu de "true" pour rendre l'interface graphique un peu plus conviviale.

Cette recette ne se révèlera désormais que pour toute classe sans constructeur.

Réduire la recherche de coupables probables

Je pourrais donc aller plus loin et rechercher la présence de méthodes ou de champs statiques.

Je recherche toute classe sans constructeur et qui possède soit tous les champs statiques publics, soit toutes les méthodes statiques publiques.

recherche :

  class :
with :
anyOf :
- child :
method :
allOf :
- modifier : "public"
- modificateur : "static"
- enfant :
champ :
allOf :
- modificateur : "static"
- modificateur : "public"
sans :
enfant :
méthode :
constructeur : true

Puisque Sensei est utilisé pour m'aider, en tant que programmeur, dans l'IDE, plutôt que pour analyser statiquement le code et signaler toutes les erreurs, ce filtre est suffisamment bon pour exclure la plupart des classes de ma base de code où je pourrais avoir une bonne raison d'avoir un constructeur public par défaut.

Dans certains projets, cela peut être un pas de trop car les classes utilitaires peuvent avoir des méthodes privées, et je peux donc choisir de rechercher la présence de "toutes" les méthodes statiques publiques, plutôt que "toutes".

       - enfant :
champ :
anyOf :
- modificateur : "static"
- modificateur : "public"

Conseils

Sensei n'est pas conçu pour remplacer un outil d'analyse statique. Sensei peut compléter un outil d'analyse statique pour les problèmes courants associés à votre processus de codage ou à votre technologie. En reproduisant suffisamment la correspondance pour mettre en évidence un problème, et en soutenant le processus de développement en générant le code QuickFix.

Ce que j'essaie de faire, c'est de créer une recette assez simple qui inclut toutes les situations où j'en ai besoin, mais en la filtrant pour qu'elle ne soit pas suggérée dans chaque classe.

Lorsque je travaille sur des recettes, j'essaie de réduire les risques. Dans ce cas, je n'étais pas sûr de pouvoir créer le constructeur privé, j'ai donc créé le QuickFix en premier. J'ai ensuite remanié les conditions de recherche pour les rendre plus spécifiques.

Parfois, lorsque je travaille sur des recettes, je ne suis pas sûre de savoir comment effectuer la recherche, alors j'y travaille d'abord.

Je trouve qu'il est plus facile de créer des recettes lorsque je les construis de manière incrémentale, en passant du remaniement du QuickFix à la recherche.

---

Vous pouvez installer Sensei à partir d'IntelliJ en utilisant "Préférences \NPlugins" (Mac) ou "Paramètres \NPlugins" (Windows) puis en recherchant "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

‍

Le tapjacking, combinaison de "tap" et de "hijacking", signifie exactement cela. Il s'agit d'une attaque où l'attaquant détourne les robinets de l'utilisateur et l'amène à faire quelque chose qu'il n'avait pas l'intention de faire. Comment cela fonctionne-t-il et comment pouvons-nous l'empêcher ?

Commençons par les superpositions d'écran. Les superpositions d'écran ou, comme Google les appelle, les fenêtres de type TYPE_APPLICATION_OVERLAY. Il s'agit de fenêtres qui se superposent à d'autres applications et qui ne masquent généralement qu'une partie de l'écran. Elles sont souvent utilisées (comme dans l'exemple ci-dessous) lorsqu'une application demande de nouvelles autorisations.

Il s'agit d'une fonctionnalité intéressante et amusante que de plus en plus d'applications commencent à utiliser. Pensez aux bulles de chat de Facebook ou à la navigation de Google Maps dans un coin de votre écran, comme dans la capture d'écran ci-dessous.

Cependant, ces superpositions présentent des risques pour la sécurité. Comment Facebook pourrait-il savoir que nous avons appuyé sur la bulle ou que nous l'avons fait glisser ? Cela permet aux applications de vous espionner et de voler potentiellement des mots de passe et des données de carte de crédit.

Un peu plus loin, et c'est de là que vient le terme tapjacking, les overlays peuvent dessiner des choses au-dessus d'autres applications en trompant l'utilisateur pour qu'il effectue différentes actions. L'utilisateur pense qu'il interagit avec la superposition, mais en réalité, ses tapotements exécutent également des actions dans l'application sous-jacente. De cette manière, la superposition peut vous inciter à activer certaines permissions ou à modifier certains paramètres dangereux, comme le montre cette ancienne vidéo de YouTube.

La vidéo de démonstration ci-dessus a été téléchargée sur YouTube en 2010, elle a donc été réalisée sur une ancienne version d'Android. Mais l'attaque est toujours d'actualité, car des vulnérabilités permettant le tapjacking dans les versions plus récentes d'Android, comme Nougat et Marshmallow, ont été mises en lumière.

Que pouvez-vous faire à ce sujet ? En tant qu'utilisateur, il est important de prendre conscience des conséquences de ces superpositions et d'être attentif aux applications qui les utilisent. Depuis le niveau 23 de l'API (Android 6.0 Marshmallow), il s'agit d'une permission qui doit être explicitement accordée par l'utilisateur. Toutefois, 50 % des utilisateurs d'Androidsont encore vulnérables. Vous pouvez toujours vérifier quelles applications utilisent cette permission dans les paramètres sous "Affichage par rapport aux autres applications".

En tant que développeurs, nous devons nous assurer que les actions de l'utilisateur sont effectuées en toute connaissance de cause et avec son consentement. Android fournit un paramètre pour vos vues qui fait exactement cela, appelé filterTouchesWhenObscured. Lorsqu'il est activé, le framework écarte les touches reçues lorsque la fenêtre de la vue est masquée par une autre fenêtre visible. C'est aussi simple que cela, définissez filterTouchesWhenObscured à true, et votre application sera à l'abri du tapjacking.

Bonne chance et à la semaine prochaine !

Il est parfois essentiel qu'une application puisse vérifier qu'une action est effectuée en toute connaissance de cause et avec le consentement de l'utilisateur, par exemple pour accorder une demande d'autorisation, effectuer un achat ou cliquer sur une publicité. Malheureusement, une application malveillante pourrait essayer de tromper l'utilisateur pour qu'il effectue ces actions à son insu, en dissimulant l'objectif de la vue.

https://developer.android.com/reference/android/view/View.html

Le cryptage de l'appareil est le processus de cryptage de toutes les données sur l'appareil Android. Une fois le cryptage activé pour un appareil Android, toutes les données créées par l'utilisateur sont immédiatement cryptées avant d'être écrites sur le support de stockage. Les données sont ainsi protégées et même si une personne non autorisée tente d'y accéder, elle ne pourra pas les lire. Cette fonction est particulièrement intéressante pour les smartphones, car ils sont transportés par l'utilisateur et sont plus susceptibles d'être perdus ou volés que d'autres appareils informatiques. Tout curieux ou voleur ne peut accéder aux données que s'il peut déverrouiller le téléphone.

Android propose deux types de cryptage : le cryptage du disque complet et le cryptage des fichiers.

Cryptage de l'intégralité du disque

Le chiffrement intégral des disques a été introduit au niveau 19 de l'API (Android 4.4 KitKat), mais les nouvelles fonctionnalités du niveau 21 de l'API (Android 5.0 Lollipop) ont réellement donné le coup d'envoi à son utilisation. Le chiffrement intégral du disque utilise une clé unique pour protéger l'ensemble de la partition des données utilisateur de l'appareil. La clé est protégée par les informations d'identification de l'utilisateur, qui doivent être fournies au démarrage de l'appareil avant qu'une partie du disque ne soit accessible.

C'est une bonne chose pour la sécurité, mais cela signifie aussi que la plupart des fonctionnalités de l'appareil sont indisponibles tant que l'utilisateur n'a pas saisi ses informations d'identification. Cela signifie que lorsque l'appareil est redémarré mais non déverrouillé, certaines fonctions comme les alarmes ne peuvent pas fonctionner, les services sont indisponibles et les téléphones ne peuvent pas recevoir d'appels. C'est pour cette raison que le deuxième mode de cryptage a été créé.

Cryptage basé sur les fichiers

Le chiffrement basé sur les fichiers, le deuxième mode de chiffrement des appareils, est disponible depuis le niveau API 24 (Android 7.0 Nougat). Dans ce mode, différents fichiers sont chiffrés avec différentes clés qui peuvent être déverrouillées indépendamment. Avec ce mode de chiffrement est apparu le mode Direct Boot, qui permet aux appareils chiffrés de démarrer directement sur l'écran de verrouillage, en activant les fonctionnalités précédemment manquantes avant de déverrouiller l'appareil.

Le démarrage direct permet aux applications de fonctionner dans un contexte limité avant que l'appareil ne soit déverrouillé. Elles peuvent ainsi continuer à fonctionner comme prévu sans compromettre les informations de l'utilisateur. Afin de fournir cette fonctionnalité, l'appareil Android a besoin de deux emplacements de stockage :

1. Stockage crypté des informations d'identification. Emplacement de stockage par défaut, disponible uniquement lorsque l'utilisateur a déverrouillé l'appareil.
2. Stockage crypté de l'appareil. Disponible en mode d'amorçage direct et après que l'utilisateur a déverrouillé l'appareil.

Si votre application doit accéder à des données lorsqu'elle est exécutée en mode d'amorçage direct, elle doit utiliser le stockage crypté de l'appareil. Mais attention aux implications en termes de sécurité ! Le stockage crypté ne doit pas être utilisé pour stocker des données sensibles ! Le stockage crypté est crypté à l'aide d'une clé qui est disponible dès que l'appareil a démarré avec succès. Toutes les données qui ne doivent être accessibles qu'à l'utilisateur doivent être sauvegardées dans l'emplacement par défaut, le stockage crypté des informations d'identification (Credential Encrypted).

Si vous souhaitez en savoir plus sur ce qu'est le cryptage ou pourquoi il est important, consultez la vidéo sur le portail Secure Code Warrior . Vous pouvez également tester vos connaissances sur le cryptage en relevant quelques défis.

Vous avez besoin d'un guide étape par étape pour votre appareil ? Consultez cet article de Bill Hess sur Pixel Privacy.

J'espère que vous avez appris quelque chose de nouveau. A la semaine prochaine !

Stockage crypté des informations d'identification, qui est l'emplacement de stockage par défaut et qui n'est disponible qu'une fois que l'utilisateur a déverrouillé l'appareil.

https://developer.android.com/training/articles/direct-boot.html