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

Cette semaine, nous allons parler du comportement par défaut des bibliothèques Zip. Si vous êtes un développeur d'applications, il est très probable que vous ayez déjà utilisé ce type de librairie. La plupart des ressources téléchargées sur Internet sont au format zip, ce qui est logique : les données compressées sont plus petites, elles se téléchargent donc plus rapidement et consomment moins de bande passante.

Si vous voulez des exemples plus concrets : textures pour les jeux, packs de langues pour l'autocomplétion dans les claviers, ... De nombreuses ressources ne sont pas automatiquement intégrées à l'application, mais téléchargées ultérieurement.

Mais soyez prudent lorsque vous utilisez cette fonctionnalité, car les noms de fichiers dans les archives zip peuvent contenir des informations de traversée de chemin. Lors de l'extraction, cela conduit à la création de fichiers en dehors du répertoire prévu. Ceci est souvent fait dans le but d'écraser des fichiers existants.

Supposons que nous ayons une archive zip contenant les deux fichiers suivants :

fichier1
../fichier2

Lorsque cette archive est extraite, le fichier 1 est extrait à l'endroit prévu, c'est-à-dire dans le répertoire de décompression. Cependant, le fichier 2 a été écrit un répertoire plus haut que celui où nous avons demandé à la bibliothèque zip d'extraire l'archive.

Soyez donc prudent, si votre bibliothèque zip ne prend pas soin de gérer correctement ce cas, elle permettra à un attaquant d'écrire un fichier arbitraire dans le système. Vérifiez toujours si votre bibliothèque est sécurisée, cette règle est valable pour toutes les bibliothèques, mais en particulier vous savez qu'il faut vérifier le comportement par défaut de votre bibliothèque zip pour ces types de fichiers.

Démontrons les conséquences d'une mauvaise gestion de ce cas dans Android. Dans Android, la bibliothèque Java Zip (java.util.zip) est utilisée, la bibliothèque permet par défaut la traversée de chemin comme expliqué ci-dessus.

Le format Dalvik Executable (.dex) d'Android a des limitations sur la quantité de classes qu'un seul fichier peut avoir. Les applications qui ont besoin de plus de classes peuvent utiliser la bibliothèque MultiDex Support qui a été ajoutée depuis le niveau API 21 (Android 5.0 Lollipop). Cette bibliothèque enregistre des fichiers .dex secondaires dans le répertoire de données de l'application, ce répertoire est accessible en écriture par l'utilisateur de l'application et ce code sera chargé et exécuté lorsque le fichier .dex sera nécessaire.

Cela signifie qu'un attaquant peut modifier le fichier .dex en l'écrasant à l'aide d'une archive zip malveillante et, pire encore, ce fichier sera chargé et exécuté, ce qui entraînera une vulnérabilité d'exécution de code à distance. Il ne s'agit pas d'un simple exemple théorique, mais d'une démonstration sur l'application My Talking Tom, qui a été téléchargée plus de 100 millions de fois sur le magasin d'applications. Voici une vidéo de l'exploit qui a été présenté à Black Hat.

Vérifiez toujours le comportement de votre bibliothèque zip afin de connaître ses faiblesses. Si vous ne pouvez pas désactiver la traversée de chemin dans votre bibliothèque zip, assurez-vous de valider le nom de chaque entrée avant de l'extraire. Le nom doit être canonisé et le chemin résultant doit se trouver dans le répertoire dans lequel vous souhaitez extraire l'archive. Pendant que nous y sommes, vous devriez également vérifier la taille totale de l'archive extraite afin d'éviter les zip bombs, mais cela fera l'objet d'un article une autre semaine.

Si vous souhaitez relever des défis sur la traversée des chemins ou tester vos compétences en matière de codage sécurisé, consultez notre plateforme.

À la prochaine fois, et n'oubliez pas : code sécurisé ou pas !

- Nous pouvons injecter dans un zip un fichier dont le nom est préfixé par un nombre arbitraire de " ../ "
- Si la bibliothèque zip ne prend pas soin de gérer correctement ce cas, cela nous permettrait d'écrire en dehors du répertoire d'extraction prévu
- Si le fichier zip n'est pas fiable, cela donne à l'attaquant une vulnérabilité d'écriture arbitraire.

https://www.blackhat.com/docs/ldn-15/materials/london-15-Welton-Abusing-Android-Apps-And-Gaining-Remote-Code-Execution.pdf

Le langage de balisage extensible (XML) est un langage de balisage utilisé pour coder des documents dans un format qui est à la fois facile à manipuler par les machines et lisible par l'homme. Cependant, ce format couramment utilisé comporte de nombreuses failles de sécurité. Dans ce premier article de blog sur le XML, j'expliquerai les bases de la manipulation sécurisée des documents XML à l'aide d'un schéma.

L'OWASP divise les différentes vulnérabilités liées à XML et aux schémas XML en deux catégories.

Documents XML malformés

Les documents XML malformés sont des documents qui ne respectent pas les spécifications XML du W3C. Parmi les exemples de documents malformés, on peut citer la suppression d'une balise de fin, la modification de l'ordre de différents éléments ou l'utilisation de caractères interdits. Toutes ces erreurs doivent entraîner une erreur fatale et le document ne doit subir aucun traitement supplémentaire.

Afin d'éviter les vulnérabilités causées par des documents malformés, vous devez utiliser un analyseur XML bien testé qui respecte les spécifications du W3C et qui ne prend pas beaucoup plus de temps pour traiter les documents malformés.

Documents XML non valides

Les documents XML non valides sont bien formés mais contiennent des valeurs inattendues. Dans ce cas, un attaquant peut tirer parti d'applications qui ne définissent pas correctement un schéma XML pour déterminer si les documents sont valides. Vous trouverez ci-dessous un exemple simple de document qui, s'il n'est pas validé correctement, peut avoir des conséquences inattendues.

Un magasin en ligne qui stocke ses transactions dans des données XML :

   <purchase></purchase>
     <id>123</id>
     <price>200</price>
   

And the user only has control over the <id> value. It is then possible, without the right counter measures, for an attacker to input something like this:</id>

   <purchase></purchase>
     <id>123</id>
     <price>0</price>
     <id></id>
     <price>200</price>
   

If the parser that processes this document only reads the first instance of the <id> and <price> tags this will lead to unwanted results. </price></id>

Il est également possible que le schéma ne soit pas assez restrictif ou que d'autres validations d'entrée soient insuffisantes, de sorte que des nombres négatifs, des décimales spéciales (comme NaN ou Infinity) ou des valeurs excessivement grandes peuvent être saisis là où ils ne sont pas attendus, ce qui conduit à un comportement involontaire similaire.

Pour éviter les vulnérabilités liées à des documents XML non valides, il convient de définir un schéma XML précis et restrictif afin d'éviter les problèmes liés à une validation incorrecte des données.

Dans le prochain billet, nous aborderons des attaques plus avancées sur les documents XML, telles que les Jumbo Payloads et le redoutable numéro quatre du Top Ten de l'OWASP, XXE.

Entre-temps, vous pouvez perfectionner ou mettre à l'épreuve vos compétences en matière de validation d'entrées XML sur notre portail.

Les spécifications pour XML et les schémas XML comportent de nombreuses failles de sécurité. En même temps, ces spécifications fournissent les outils nécessaires pour protéger les applications XML. Même si nous utilisons les schémas XML pour définir la sécurité des documents XML, ils peuvent être utilisés pour effectuer une variété d'attaques : récupération de fichiers, falsification de requêtes côté serveur, balayage de ports ou force brute.

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

L'insuffisance de la journalisation et de la surveillance résulte principalement de l'échec d'un plan de cybersécurité concernant la journalisation de toutes les tentatives d'authentification échouées, des accès refusés et des erreurs de validation d'entrée. Elle peut se produire à d'autres endroits de l'environnement de production, mais elle est surtout associée à l'incapacité d'arrêter les tentatives de connexion non valides.

Il s'agit d'une vulnérabilité dangereuse car elle signifie que les équipes de cybersécurité ne répondront pas aux attaques parce qu'elles n'en ont pas connaissance. Cela donne un avantage considérable aux attaquants, qui peuvent ainsi passer inaperçus pendant qu'ils tentent de pénétrer plus avant dans un système ou d'améliorer leurs informations d'identification. En fait, sans une journalisation et une surveillance appropriées, il devient très difficile, voire impossible, de détecter et d'arrêter les attaques avant qu'elles ne fassent des dégâts importants.

Vous êtes prêt à tester vos compétences en relevant un défi dès maintenant ? Jetez un coup d'œil à ce qui suit :

Comment les attaquants exploitent-ils les lacunes en matière de journalisation et de surveillance ?

Toute API est vulnérable à une journalisation et une surveillance insuffisantes si le niveau de journalisation n'est pas défini correctement, s'il est trop bas, si les messages d'erreur ne sont pas suffisamment détaillés ou si aucune fonction de journalisation n'est présente.

Un exemple intéressant serait celui d'un pirate qui obtiendrait une liste importante de noms d'utilisateurs compromis pour un site web ou un service. En expérimentant, il pourrait découvrir qu'il faut trois tentatives de connexion infructueuses avant que le système ne soit verrouillé et que le personnel chargé de la cybersécurité ne soit averti.

Armés de ces informations, au lieu d'essayer de forcer des comptes individuels, ils pourraient écrire un script pour essayer de se connecter sous chaque nom de leur liste compromise en utilisant des mots de passe communs comme "123456" ou "password". L'astuce consiste à n'essayer chaque nom d'utilisateur qu'une fois, voire deux, afin de rester en dessous du seuil de verrouillage et d'alerte. S'ils ont de la chance, ils compromettront au moins quelques mots de passe dès le départ. Ensuite, ils attendent simplement un jour que le compteur de connexions se réinitialise et recommencent le processus en utilisant des mots de passe différents comme "qwerty" ou "god". Si les administrateurs ne détectent jamais ce qu'ils font, les attaquants peuvent parcourir la liste plusieurs fois et finir par compromettre la plupart des comptes dont les mots de passe sont faibles.

C'est ce qui s'est passé dans l'exemple fourni par l'OWASP, où une plateforme de partage de vidéos a été attaquée au moyen d'un bourrage d'informations d'identification qui a exploité une vulnérabilité insuffisante en matière de journalisation et de surveillance. Jusqu'à ce que l'entreprise commence à recevoir des plaintes d'utilisateurs, elle n'avait aucune idée de l'existence de cette attaque. Elle a fini par trouver des preuves dans les journaux de l'API et a dû envoyer une notification de changement forcé de mot de passe à tous ses utilisateurs, ainsi que signaler l'attaque aux autorités réglementaires.  

Élimination de la vulnérabilité liée à l'insuffisance de la journalisation et de la surveillance

L'automatisation et la surveillance constante peuvent contribuer à mettre fin à cette vulnérabilité. Pour commencer, toutes les tentatives d'authentification qui échouent doivent être enregistrées. Ce journal doit être mis dans un format lisible par une machine, comme STIX et TAXII, afin qu'il puisse être intégré dans un système de gestion des informations et des événements de sécurité (SIEM) formé à la recherche d'attaques, quels que soient les seuils utilisés.

Vous devez également protéger vos fichiers journaux. Considérez-les comme des informations sensibles et protégez-les contre la suppression ou la modification par des pirates. Une bonne politique consiste à sauvegarder les fichiers journaux et à les crypter.

Enfin, créez des tableaux de bord et des alertes personnalisés afin de détecter toute activité suspecte et d'y répondre le plus rapidement possible. Si vous éliminez le temps qu'un attaquant passe avec le système, vous supprimez sa capacité à utiliser des techniques d'attaque lentes et faibles pour ne pas être détecté.

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.

Depuis 2015, nous encourageons les développeurs du monde entier à adopter une approche proactive et positive de la sécurité, en les aidant à acquérir les compétences nécessaires pour sécuriser leur code, à réduire les travaux de reprise et de remédiation, et à considérer l'équipe de sécurité comme autre chose que la police du plaisir.

Nous nous engageons toujours aux côtés des développeurs pour sécuriser le code dans toute la galaxie, mais il est temps de faire bouger les choses et d'amener nos développeurs aguerris et sensibilisés à la sécurité à un niveau supérieur.

Nous sommes ravis de vous annoncer la sortie d'une toute nouvelle fonctionnalité sur la plateforme Secure Code Warrior : Missions. Cette toute nouvelle catégorie de défis constitue la phase suivante de la formation à la sécurité développée par les développeurs. Elle permet aux utilisateurs de passer de la mémorisation des connaissances en matière de sécurité à leur application dans un environnement de simulation du monde réel. Cette approche de micro-apprentissage, basée sur l'échafaudage, permet de développer de puissantes compétences de codage sécurisé qui sont pertinentes pour l'emploi et beaucoup plus divertissantes que de regarder (verticalement) d'interminables vidéos de formation en arrière-plan d'une journée de travail.

Notre première mission publique jouable est une simulation de la faille Unicode de GitHub. Elle peut sembler faussement simple, mais il s'agit d'une vulnérabilité très intelligente qu'il est amusant de disséquer. Le chercheur en sécurité 0xsha a réalisé une étude de cas complète sur la façon dont ce même bogue peut être utilisé pour exploiter Django par le biais de transformations de cas, tout en révélant également comment le comportement de la vulnérabilité peut changer d'un langage de programmation à l'autre. Il y a encore beaucoup à découvrir sur ce problème de sécurité, et notre mission est un excellent point de départ.

La collision frontale de GitHub (cartographie des cas)

Dans un billet de blog du 28 novembre 2019, le groupe de recherche en sécurité Wisdom a fait état d'un bug de sécurité qu'il a découvert sur GitHub. Ils ont décrit comment ils ont pu utiliser une collision de mappage de cas dans Unicode pour déclencher une livraison d'email de réinitialisation de mot de passe à la mauvaise adresse email (ou si nous pensions comme un attaquant, une adresse email du choix de l'acteur de la menace).

Bien qu'une faille de sécurité ne soit jamais une bonne nouvelle, les chercheurs en sécurité qui pratiquent le whitehat offrent une certaine clémence - sans parler de la possibilité d'éviter un désastre - s'ils découvrent des erreurs potentiellement exploitables dans une base de code. Leurs blogs et leurs rapports sont souvent très intéressants à lire, et c'est plutôt cool de découvrir une nouvelle vulnérabilité et son fonctionnement.

Pour passer au niveau suivant de prouesses en matière de codage sécurisé, il est extrêmement utile non seulement de trouver les vulnérabilités courantes (en particulier les nouvelles vulnérabilités les plus intéressantes - nous savons tous que les acteurs malveillants chercheront un terrain fertile pour déterrer des données à l'aide de ces nouvelles techniques), mais aussi de disposer d'un environnement sûr et pratique pour comprendre comment les exploiter.

C'est ce que nous allons faire. Poursuivez votre lecture pour découvrir comment une collision de cartographie de cas en Unicode peut être exploitée, comment elle se présente en temps réel, et comment vous pouvez adopter l'état d'esprit d'un chercheur en sécurité et l'essayer par vous-même.

Prêt à affronter une collision de cartographie de cas dès maintenant ? Allez-y :

Unicode : Complexe, personnalisable à l'infini et bien plus que des émojis

Le terme "Unicode" ne fait peut-être pas partie du lexique du commun des mortels, mais il y a de fortes chances que la plupart des gens l'utilisent sous une forme ou une autre tous les jours. Si vous avez utilisé un navigateur web, un logiciel Microsoft ou envoyé un emoji, vous avez été confronté de près ou de loin à l'Unicode. Il s'agit d'une norme permettant d'encoder et de traiter de manière cohérente les textes provenant de la plupart des systèmes d'écriture du monde, afin que tout le monde puisse s'exprimer (numériquement) à l'aide d'un seul jeu de caractères. À l'heure actuelle, il existe plus de 143 000 caractères. Vous êtes donc couvert, que vous utilisiez l'islandais ou le turc sans point, ou tout ce qui se trouve entre les deux.

En raison du grand nombre de caractères Unicode, il est souvent nécessaire de trouver un moyen de convertir les caractères en un autre caractère "équivalent". Par exemple, il semble logique que si vous convertissez une chaîne Unicode avec un point en ASCII, elle se transforme simplement en "i", n'est-ce pas ?

Un grand volume d'encodage de caractères est synonyme d'un grand potentiel de désastre

Une collision de mappage de cas en Unicode est une faille de logique d'entreprise qui peut conduire à une prise de contrôle de comptes non protégés par 2FA. Pour illustrer la vulnérabilité en question, examinons un exemple de ce bogue dans un extrait de code réel :

app.post(/api/resetPassword, function (req, res) {
  var email = req.body.email;
  db.get(SELECT rowid AS id, email FROM users WHERE email = ?, [email.toUpperCase()],
      (err, user) => {
          if (err) {
              console.error(err.message);
              res.status(400).send();
          } else {
              generateTemporaryPassword((tempPassword) => {
                  accountRepository.resetPassword(user.id, tempPassword, () => {
                      messenger.sendPasswordResetEmail(email, tempPassword);
                      res.status(204).send();
                  });
              });
          }
      });
});

La logique est la suivante :

1. Il accepte l'adresse électronique fournie par l'utilisateur et la met en majuscules pour des raisons de cohérence.
2. Il vérifie si l'adresse électronique existe déjà dans la base de données.
3. Si c'est le cas, il définira un nouveau mot de passe temporaire (ce n'est d'ailleurs pas la meilleure pratique. Utilisez plutôt un lien avec un jeton qui permet de réinitialiser le mot de passe).
4. Il envoie ensuite un courrier électronique à l'adresse obtenue à l'étape 1, contenant le mot de passe temporaire (il s'agit d'une très mauvaise pratique, pour de nombreuses raisons...).

Voyons ce qui se passe avec l'exemple fourni dans le billet de blog original, où un utilisateur demande une réinitialisation de son mot de passe pour l'adresse électronique John@GıtHub.com (notez le i sans point turc) :

1. La logique convertit John@Gıthub.com en JOHN@GITHUB.COM
2. Il recherche cela dans la base de données et trouve l'utilisateur JOHN@GITHUB.COM
3. Il génère un nouveau mot de passe et l'envoie à John@Gıthub.com.

Notez que ce processus aboutit à l'envoi du courrier électronique hautement sensible à la mauvaise adresse électronique. Oups !

Comment chasser ce démon de l'Unicode ?

L'aspect intéressant de cette vulnérabilité spécifique est qu'elle est due à de multiples facteurs :

1. Le comportement réel du casting Unicode
2. La logique déterminant l'adresse électronique à utiliser, c'est-à-dire l'adresse électronique fournie par l'utilisateur, au lieu de celle qui existe déjà dans la base de données.

En théorie, vous pouvez résoudre ce problème spécifique de deux manières, comme indiqué dans l'article de blog de Wisdom :

1. Convertir l'e-mail en ASCII avec la conversion Punycode
2. Utilisez l'adresse électronique de la base de données plutôt que celle fournie par l'utilisateur.

Lorsqu'il s'agit de renforcer un logiciel, il est préférable de ne rien laisser au hasard et de mettre en place autant de couches de défense que possible. Pour autant que nous le sachions, il existe peut-être d'autres moyens d'exploiter ce codage, mais nous ne les connaissons pas encore. Tout ce que vous pouvez faire pour réduire les risques et fermer les fenêtres qui pourraient être laissées ouvertes à un attaquant est précieux.

Vous êtes prêt à l'essayer vous-même ?

La plupart des développeurs savent que les données compromises sont mauvaises pour les affaires. Cependant, les ingénieurs sensibilisés à la sécurité sont un antidote puissant contre les vulnérabilités croissantes, les brèches et les problèmes de cybersécurité.

Il est temps d'améliorer vos compétences en matière de codage sécurisé et de sensibilisation. Découvrez cette vulnérabilité de GitHub dans une simulation immersive et sûre, où vous pourrez voir l'impact d'un mauvais code dans les contextes frontend et backend. Les attaquants ont un avantage, alors égalisons le terrain de jeu et appliquons de vraies compétences avec un contre-pied blanc.

Si la plupart des vulnérabilités de cette liste sont assez spécifiques aux API, le problème des fonctions de sécurité désactivées, des fonctions de débogage activées et des autorisations incorrectes peut se poser n'importe où. Il est probablement un peu plus répandu dans les API, mais les attaquants tentent souvent de trouver des failles non corrigées et des fichiers ou répertoires non protégés n'importe où dans un réseau. Le fait de tomber sur une API dont le débogage est activé ou dont les fonctions de sécurité sont désactivées ne fait que faciliter leur travail infâme. Pire encore, il existe des outils automatisés permettant de détecter et d'exploiter les mauvaises configurations de sécurité. Si vous en avez dans votre environnement, il y a donc de fortes chances qu'elles soient exploitées, ce qui explique pourquoi cette vulnérabilité figure sur la liste de l'OWASP des failles dangereuses des API.

Avant de passer aux choses sérieuses, essayez de résoudre ce problème de débogage :

Comment les fonctions de sécurité désactivées, les fonctions de débogage activées et les autorisations incorrectes se glissent-elles dans une API ?

Pour comprendre comment cette faille multidimensionnelle de l'API est ajoutée aux réseaux, nous devons la décomposer en ses éléments constitutifs. Commençons par le problème des fonctions de débogage activées. Le débogage est un outil utile qui aide les développeurs à comprendre pourquoi les applications ne fonctionnent pas correctement ou font des erreurs. Lorsque le débogage est activé, les erreurs et les exceptions génèrent des pages d'erreur détaillées permettant aux développeurs de voir ce qui n'a pas fonctionné et de résoudre les problèmes. Il est tout à fait possible d'activer le débogage lorsqu'une application est encore en cours de développement.

Cependant, il y a une raison pour laquelle la plupart des frameworks sont accompagnés d'avertissements concernant l'utilisation du mode débogage dans un environnement de production, probablement directement dans le code où le débogage est activé. Par exemple, dans le code où le débogage est activé :

# AVERTISSEMENT DE SECURITE : ne pas exécuter avec le débogage activé en production !
DEBUG = True

Dans cet exemple, le débogage a été activé. L'application Django génère des pages d'erreur détaillées lorsqu'une exception est levée. Si cela est fait dans un environnement de production, un adversaire aurait accès à ces pages d'erreur, qui contiennent des métadonnées sur l'environnement. Bien que le débogage soit désactivé par défaut dans la plupart des frameworks, il est facile d'oublier de le réactiver s'il est activé au cours d'un long processus de développement. Ensuite, lorsque l'application est transférée dans un environnement de production, elle fournit aux attaquants de nombreuses informations sur la manière de compromettre une application, voire un serveur ou un réseau entier.

Si l'activation du mode débogage est généralement un problème isolé, les vulnérabilités liées aux autorisations incorrectes et aux fonctions de sécurité désactivées sont souvent associées. Par exemple, dans un scénario réel fourni par l'OWASP, un attaquant a utilisé un moteur de recherche pour trouver une base de données qui était accidentellement connectée à l'internet. Comme le système de gestion de base de données populaire utilisait sa configuration par défaut, l'authentification était désactivée. Ainsi, en combinant les vulnérabilités liées aux autorisations inappropriées et aux fonctions de sécurité désactivées, l'attaquant a pu accéder à des millions d'enregistrements contenant des informations confidentielles, des préférences personnelles et des données d'authentification.

Élimination des vulnérabilités liées aux fonctions de sécurité désactivées, aux fonctions de débogage activées et aux autorisations incorrectes

Vous devrez probablement adopter une double approche pour éliminer cette vulnérabilité. Pour éliminer la partie du problème liée à l'activation du débogage, ajoutez simplement une vérification au processus de développement afin de vous assurer que le débogage est désactivé avant de transférer une API ou une application dans l'environnement de production. Dans notre exemple, la commande appropriée serait la suivante :

# AVERTISSEMENT DE SECURITE : ne pas exécuter avec le debug activé en production !
DEBUG = False

Les fonctionnalités de débogage de l'application Django sont maintenant désactivées avec l'indicateur DEBUG configuré à False. Aucune page d'erreur ne sera générée en réponse aux erreurs. Si un adversaire accède quand même aux pages d'erreur, elles ne contiendront pas de métadonnées utiles et ne constitueront pas un risque pour l'application.

Il est un peu plus difficile d'éliminer les vulnérabilités liées aux fonctions de sécurité désactivées et aux autorisations inappropriées, car elles peuvent englober un large éventail de vulnérabilités spécifiques. La meilleure façon de les arrêter est de développer un processus standard et reproductible pour permettre le déploiement rapide et facile des actifs verrouillés dans l'environnement de production.

Même dans ce cas, vous devez créer un processus dans lequel les fichiers d'orchestration, les composants d'API et les services en nuage tels que les autorisations de seau Amazon S3 sont constamment examinés et mis à jour. Cet examen doit également évaluer l'efficacité globale des paramètres de sécurité dans l'ensemble de l'environnement au fil du temps, afin de s'assurer que l'organisation améliore constamment la sécurité de ses API.

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.