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.

La vulnérabilité de l'assignation de masse est née parce que de nombreux cadres modernes encouragent les développeurs à utiliser des fonctions qui lient automatiquement les entrées des clients dans des variables de code et des objets internes. Cela permet de simplifier le code et d'accélérer les opérations.

Les attaquants peuvent utiliser cette méthode pour forcer la modification de propriétés d'objets qui ne devraient jamais être mises à jour par un client. Normalement, cela entraîne des problèmes spécifiques à l'entreprise, comme un utilisateur qui s'octroie des privilèges d'administrateur, au lieu de faire tomber un site web ou de voler des secrets d'entreprise. Les attaquants doivent également avoir une idée des relations entre les objets et la logique commerciale de l'application qu'ils exploitent.

Cependant, cela ne rend pas moins dangereuse la vulnérabilité de l'assignation de masse entre les mains d'un utilisateur intelligent et malveillant.

Avant de vous lancer dans le guide complet, jouez à notre défi ludique et voyez comment vous vous en sortez :

Comment les attaquants peuvent-ils exploiter la vulnérabilité de l'assignation de masse ?

Le scénario proposé par l'OWASP (et légèrement modifié par nos soins) suppose une application de covoiturage qui inclut différentes propriétés liées à des objets dans le code à l'aide de l'affectation de masse. Il s'agit notamment de propriétés liées aux autorisations que les utilisateurs peuvent modifier et de propriétés dépendant du processus qui ne doivent être définies qu'en interne par l'application. Toutes deux utilisent l'affectation en masse pour lier des propriétés à des objets.

Dans ce scénario, l'application de covoiturage permet aux utilisateurs de mettre à jour leur profil, comme c'est souvent le cas dans les applications destinées aux utilisateurs. Pour ce faire, elle utilise un appel API envoyé à PUT, qui renvoie l'objet JSON suivant :

{"user_name":"SneakySnake", "age":17, "is_admin":false}

Comme l'attaquant, M. SneakySnake dans ce cas, a compris la relation entre les propriétés et les objets, il peut renvoyer sa demande initiale de mise à jour de son profil avec la chaîne suivante :

{"user_name":"SneakySnake","age":24,, "is_admin":true}

Comme le point d'accès est vulnérable à l'assignation de masse, il accepte la nouvelle entrée comme étant valide. Notre pirate a non seulement ajouté quelques années à son profil, mais il s'est également attribué des privilèges d'administrateur.

Éliminer la vulnérabilité de l'assignation de masse

Bien qu'il soit pratique d'utiliser la fonction d'affectation de masse dans certains frameworks, vous devez éviter de le faire si vous voulez que vos API soient sécurisées. Au lieu de cela, analysez les valeurs de la demande au lieu de les lier directement à un objet. Vous pouvez également utiliser un objet de transfert de données réduit qui offrirait pratiquement la même commodité que la liaison directe à l'objet lui-même, mais sans le risque associé.

À titre de précaution supplémentaire, les propriétés sensibles telles que les privilèges d'administrateur de l'exemple ci-dessus peuvent être refusées afin qu'elles ne soient jamais acceptées par le serveur lors d'un appel à l'API. Une meilleure idée encore serait de refuser toutes les propriétés par défaut, puis d'autoriser des propriétés spécifiques, non sensibles, que vous souhaitez que les utilisateurs puissent mettre à jour ou modifier. L'une ou l'autre de ces mesures peut contribuer à verrouiller les API et à éliminer la vulnérabilité de l'affectation de masse dans votre environnement.

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.

Ajoutez une formation centrée sur le développeur aux fichiers SARIF standard de l'industrie, directement dans les flux de travail de balayage de code GitHub avec notre nouvelle action GitHub.

Le 30 septembre, GitHub a officiellement annoncé la disponibilité générale de l'analyse de code GitHub. L'analyse de code GitHub est une approche native de GitHub qui permet aux développeurs de trouver facilement les vulnérabilités de sécurité avant qu'elles n'atteignent la production.

L'analyse du code s'intègre aux actions GitHub " ou à un environnement CI/CD existant " pour maximiser la flexibilité des équipes de développement. Il analyse le code au fur et à mesure qu'il est créé, ce qui permet de faire apparaître des évaluations de sécurité exploitables dans les demandes d'extraction et d'automatiser la sécurité dans le cadre d'un flux de travail GitHub.

Une approche transparente de la sécurité pour les développeurs.

Construit sur le standard ouvert SARIF (Static Analysis Results Interchange Format), l'analyse de code est conçue pour s'adapter aux besoins croissants des organisations, afin qu'elles puissent inclure des solutions open-source et commerciales de test de sécurité des applications statiques (SAST) au sein de la même expérience GitHub-native.

Les outils d'analyse de code tiers peuvent être lancés avec une action GitHub ou une application GitHub basée sur un événement dans GitHub lui-même, comme une demande d'extraction. Les résultats sont formatés en tant que SARIF et téléchargés dans l'onglet Alertes de sécurité de GitHub. Les alertes sont ensuite regroupées par outil, et GitHub peut suivre et supprimer les alertes en double. Les développeurs peuvent ainsi utiliser l'outil de leur choix pour tous leurs projets sur GitHub, tout en bénéficiant de l'expérience native de GitHub. Il s'agit tout simplement d'éviter les perturbations liées à certaines approches traditionnelles de la sécurité et de respecter le flux de travail des développeurs.

Hier, Secure Code Warrior a été présenté par GitHub comme le seul fournisseur de formation centré sur les développeurs dans leur article de blog,Third-Party Code Scanning Tools : Static Analysis & Developer Security Training, aux côtés de Synk, Checkmarx, Fortify On Demand, Synopsis et Veracode.

Bien que de nombreuses solutions SCA/SAST fournissent de nombreux détails sur chacune des vulnérabilités découvertes, ainsi que des références aux avis publiés et aux CWE associés, tous les développeurs ne sont pas des experts en sécurité, et il ne faut pas s'attendre à ce qu'ils le soient. Des conseils et des outils pratiques et utilisables sont la clé d'une prise de conscience exploitable.

Micro-apprentissage contextuel.

Plus les développeurs disposent d'informations sur les vulnérabilités, plus ils sont en mesure de comprendre les risques, d'accorder la priorité à la résolution des problèmes les plus urgents et, en fin de compte, de les prévenir. C'est là qu'intervient Secure Code Warrior . Notre mission est de permettre aux développeurs d'écrire du code sécurisé dès le début grâce à une formation amusante, engageante et spécifique au cadre, en les aidant à penser et à coder avec un état d'esprit de sécurité afin d'obtenir des améliorations rapides en matière de conformité, de cohérence, de qualité et de rapidité de développement.

Intégration de l'analyse de code GitHub

Secure Code Warrior a créé une action GitHub qui apporte l'apprentissage contextuel à l'analyse du code GitHub. Cela signifie que les développeurs peuvent utiliser une action tierce telle que l'action Snyk Container pour trouver des vulnérabilités, puis augmenter le résultat avec un apprentissage hyper pertinent spécifique à CWE.

L'action GitHub Secure Code Warrior traite un fichier SARIF standard et ajoute un apprentissage contextuel basé sur les références CWE dans un objet de règle SARIF. Cela permet aux équipes de développement et de sécurité non seulement de trouver des vulnérabilités, mais aussi d'enrichir les rapports de l'outil SAST avec des connaissances exploitables qui les aident à éviter que les vulnérabilités ne se reproduisent.

Vous êtes prêt à l'essayer ?

Obtenez l'action gratuitement directement depuis la place de marché GitHub ici.
Pour en savoir plus sur l'action GitHub Secure Code Warrior , cliquez ici.

Cette série de blogs se concentrera sur certaines des pires vulnérabilités liées aux interfaces de programmation d'applications (API). Ces vulnérabilités sont si graves qu'elles figurent sur la liste des principales vulnérabilités des API établie par l'Open Web Application SecurityProject (OWASP). Compte tenu de l'importance des API dans les infrastructures informatiques modernes, il s'agit de problèmes critiques que vous devez à tout prix éviter dans vos applications et vos programmes.

La vulnérabilité du contrôle d'accès au niveau de la fonction manquante permet aux utilisateurs d'exécuter des fonctions qui devraient être restreintes, ou leur permet d'accéder à des ressources qui devraient être protégées. Normalement, les fonctions et les ressources sont protégées directement dans le code ou par des paramètres de configuration, mais il n'est pas toujours facile de le faire correctement. La mise en œuvre de contrôles appropriés peut être difficile car les applications modernes contiennent souvent de nombreux types de rôles et de groupes, ainsi qu'une hiérarchie d'utilisateurs complexe.

Mais d'abord, pourquoi ne pas vous lancer et jouer à notre défi ludique pour voir où vous en êtes dans la gestion de cette catégorie délicate de bogues ?

Voyons cela de plus près :

Les API sont particulièrement vulnérables à cette faille car elles sont très structurées. Les attaquants qui comprennent le code peuvent faire des suppositions éclairées sur la manière de mettre en œuvre des commandes qui devraient leur être réservées. C'est l'une des principales raisons pour lesquelles la vulnérabilité du contrôle d'accès au niveau des fonctions/ressources a été classée dans le top 10 de l'OWASP.

Comment les attaquants peuvent-ils exploiter la vulnérabilité du contrôle d'accès au niveau de la fonction ?

Les attaquants qui soupçonnent que les fonctions ou les ressources ne sont pas correctement protégées doivent d'abord obtenir l'accès au système qu'ils veulent attaquer. Pour exploiter cette vulnérabilité, ils doivent avoir la permission d'envoyer des appels API légitimes au point de terminaison. Il existe peut-être une fonction d'accès de bas niveau pour les invités ou un moyen de se connecter anonymement dans le cadre de la fonction de l'application. Une fois cet accès établi, ils peuvent commencer à modifier les commandes dans leurs appels API légitimes. Par exemple, ils peuvent remplacer GET par PUT, ou remplacer la chaîne USERS de l'URL par ADMINS. Là encore, comme les API sont structurées, il est facile de deviner quelles commandes peuvent être autorisées et où les placer dans la chaîne.

L'OWASP donne comme exemple de cette vulnérabilité un processus d'enregistrement mis en place pour permettre à de nouveaux utilisateurs de rejoindre un site web. Il utiliserait probablement un appel API GET, comme celui-ci :

GET /api/invites/{invite_guid}

L'utilisateur malveillant recevra en retour un JSON contenant des détails sur l'invitation, notamment le rôle et l'adresse électronique de l'utilisateur. Il peut alors transformer GET en POST et faire passer l'invitation d'un utilisateur à un administrateur à l'aide de l'appel API suivant :

POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}

Seuls les administrateurs devraient pouvoir envoyer des commandes POST, mais si elles ne sont pas correctement sécurisées, l'API les acceptera comme légitimes et exécutera ce que l'attaquant souhaite. Dans ce cas, l'utilisateur malveillant serait invité à rejoindre le système en tant que nouvel administrateur. Après cela, il pourrait voir et faire tout ce qu'un administrateur légitime pourrait faire, ce qui n'est pas une bonne chose.

Élimination de la vulnérabilité du contrôle d'accès au niveau de la fonction

La prévention de cette vulnérabilité de l'API est particulièrement importante car il n'est pas difficile pour un attaquant de trouver des fonctions non protégées dans une API structurée. Tant qu'il peut obtenir un certain niveau d'accès à une API, il peut commencer à cartographier la structure du code et créer des appels qui seront éventuellement suivis.

Ainsi, toutes les fonctions au niveau de l'entreprise doivent être protégées à l'aide d'une méthode d'autorisation basée sur les rôles. La plupart des frameworks proposent des routines centralisées pour y parvenir. Si le cadre que vous avez choisi ne le fait pas, ou si la routine qu'il propose est difficile à mettre en œuvre, il existe de nombreux modules externes spécialement conçus pour faciliter l'utilisation. Quelle que soit la méthode choisie, veillez à mettre en œuvre l'autorisation sur le serveur. N'essayez jamais de sécuriser les fonctions du côté client.

Lorsque vous créez des autorisations au niveau des fonctions et des ressources, gardez à l'esprit que les utilisateurs ne doivent recevoir que les autorisations dont ils ont besoin, rien de plus. Comme c'est toujours le cas lors du codage des API ou de toute autre chose, pratiquez la méthodologie du moindre privilège. Elle sécurisera votre environnement et vous évitera bien des problèmes de cybersécurité.

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.

En cette occasion annuelle des plus festives pour les professionnels de la cybersécurité, le Mois national de la sensibilisation à la cybersécurité est un moment que de nombreuses entreprises utilisent pour réfléchir et évaluer le rythme général de la sensibilisation à la sécurité dans l'ensemble de l'organisation. Et comme 62 % des entreprises ont subi une attaque de phishing ou d'ingénierie sociale au cours de la seule année 2018, on ne saurait trop insister sur l'importance de veiller à ce que chaque personne de l'entreprise - qu'elle ait ou non un rôle à jouer en matière de sécurité - reçoive une formation adéquate en matière de sensibilisation à la cybersécurité.

En tant qu'événement de plus en plus mondial, ce mois représente un fourre-tout pour discuter des meilleures pratiques, et les initiatives sont délibérément superficielles. Cependant, même les organisations dotées de solides programmes de sécurité et de spécialistes internes peuvent mettre à profit cette période pour évaluer les équipes plus techniques afin de déterminer ce dont elles ont besoin pour devenir plus conscientes de la sécurité dans le contexte de leur rôle.

Pour les spécialistes AppSec, les chefs d'équipe de développement et les membres de la cohorte d'ingénieurs les plus sensibles à la sécurité, cela peut ressembler à apprendre à sucer des œufs, mais ce sont ces champions au sein de l'entreprise qui peuvent pousser la sécurité et la sûreté vers de nouveaux sommets, à l'échelle de toute l'entreprise.

Comment renforcer le mois de la sensibilisation à la cybersécurité ?

C'est une occasion en or pour l'équipe de sécurité de tendre un rameau d'olivier à l'équipe de développement, peut-être sous la forme d'activités et de programmes inter-équipes qui peuvent aider les développeurs à avoir une vision plus positive de la sécurité dans le contexte de leur travail.

Voici quelques idées pour donner le coup d'envoi :

1. Aidez les développeurs à obtenir le soutien dont ils ont besoin pour apprendre à coder en toute sécurité. Ne pas avoir les bons outils pour le travail est un excellent moyen de se sentir justifié de jeter une tâche dans le panier trop difficile. Si les développeurs n'ont pas la formation et les outils nécessaires pour considérer la sécurité comme une priorité dans le processus de codage, il n'est pas étonnant que tant d'équipes soient mal équipées pour éviter les vulnérabilités courantes dans leur code.
   
   Profitez de ce mois pour comprendre ce qui manque dans la pile technologique de développement, quels managers peuvent travailler ensemble pour améliorer la communication et accroître la visibilité de la sécurité, et qui peut continuer à défendre la sécurité et à en être le champion à l'avenir.
   
2. Accueillez un événement de type "déjeuner et apprentissage". Les communautés de la cybersécurité et du développement regorgent en général de personnes incroyablement généreuses qui ne demandent qu'à partager leur expertise. Contactez des conférenciers, des collègues techniciens d'autres entreprises, ou même des sections locales de l'OWASP, et voyez qui pourrait venir discuter avec l'équipe, ou enregistrer un webinaire avec quelqu'un de l'organisation. C'est un gain relativement rapide, et cela peut être un énorme avantage pour les développeurs en herbe de voir les différents parcours de carrière en sécurité qui s'offrent à eux.
   
3. Rassemblez-vous pour une compétition amicale. L'apprentissage de la sécurité est beaucoup plus amusant lorsque vous faites quelque chose d'un peu différent et spécial. Secure coding tournaments est un excellent moyen d'amener les développeurs à tester leurs compétences en matière de codage sécurisé et à se mesurer à leurs pairs dans un environnement ludique. Mettez en place un thème de déguisement et soyez créatif avec les équipes (pourquoi pas les développeurs contre leurs managers ?). Commandez des pizzas, des boissons, de la musique énergique, et ce sera un événement inoubliable pour toute l'organisation.

Rendre à la communauté ce qu'elle a reçu : Téléchargez votre application gratuite Secure Code Bootcamp

Je suis moi-même développeur et j'ai toujours cherché ce que nous pouvions partager et utiliser gratuitement. C'est une fierté de créer des logiciels gratuits qui peuvent aider les autres, et ce mois-ci est un bon moment pour réfléchir à nos racines et à ce que nous pouvons apporter à la communauté.

C'est pourquoi nous avons le plaisir de vous annoncer notre nouvelle application gratuite, Secure Code Bootcamp. Il s'agit d'un compagnon de codage sécurisé de poche pour les codeurs qui veulent se mettre au défi, en renforçant progressivement leur sensibilisation à la sécurité, n'importe où et n'importe quand.

Téléchargez l'application pour iOS et Android dès maintenant, et apprenez à localiser et à identifier les vulnérabilités OWASP dans Node.JS, Python:Django, Java:Spring, C# .NET : MVC :