Informations sur le code sécurisé

Cette semaine, nous allons parler du comportement par défaut des bibliothèques Zip. Si vous êtes développeur d'applications, il est fort probable que vous l'ayez déjà utilisé. 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 : des textures pour les jeux, des modules linguistiques pour la saisie automatique sur 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 des archives zip peuvent contenir des informations de traversée de chemin. Une fois extrait, cela entraînera la création de fichiers en dehors du répertoire prévu. Cela est souvent fait dans le but de remplacer des fichiers existants.

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

fichier1
.. /fichier2

Lorsque cette archive est extraite, le fichier1 est extrait là où nous nous attendons à ce qu'il soit, 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.

Attention donc, 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 empirique est valable pour toutes les bibliothèques, mais vous devez en particulier vérifier le comportement par défaut de votre bibliothèque zip pour ces types de fichiers.

Démontrons les conséquences lorsque ce cas n'est pas correctement traité sous Android. Sous Android, la bibliothèque Java Zip (java.util.zip) est utilisée, la bibliothèque permet par défaut de parcourir les chemins comme expliqué ci-dessus.

Le format exécutable Dalvik d'Android (.dex) limite le nombre 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 d'API 21 (Android 5.0 Lollipop). Cette bibliothèque enregistre les 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 le remplaçant à 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 simplement d'un exemple théorique, mais cela a été démontré sur l'application My Talking Tom, qui compte plus de 100 millions de téléchargements sur l'App Store. Voici une vidéo de l'exploit qui a été présentée à Black Hat.

Vérifiez toujours le comportement de votre bibliothèque zip afin d'être conscient de ses insécurités. 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 canonique et le chemin obtenu 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 des archives extraites pour éviter les bombes zippées, mais ce billet sera publié pendant encore une semaine.

Si tu veux relever quelques défis lors de la traversée d'un chemin ou si vous souhaitez tester vos compétences en matière de codage sécurisé, consultez notre plateforme.

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

- Nous pouvons injecter un fichier dans un zip 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

C'est exactement ce que signifie le tapjacking, une combinaison de « tap » et de « hijacking ». Il s'agit d'une attaque au cours de laquelle l'attaquant détourne les tapotements de l'utilisateur et l'incite à faire quelque chose dont il n'avait pas l'intention. Alors, comment cela fonctionne-t-il et comment l'éviter ?

Nous allons commencer notre histoire avec des superpositions d'écran. Superpositions d'écran ou, comme les appelle Google, fenêtres utilisant le type TYPE_APPLICATION_OVERLAY. Il s'agit de fenêtres dessinées au-dessus d'autres applications et qui ne masquent généralement qu'une partie de l'écran. Elles sont souvent utilisées (comme l'exemple d'image ci-dessous) lorsqu'une application demande de nouvelles autorisations.

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

Cependant, ces superpositions présentent certains risques de sécurité. Toute superposition d'écran active peut écouter les tapotements. Sinon, comment Facebook pourrait-il savoir que nous avons tapé ou fait glisser la bulle ? Cela permet aux applications de vous espionner et de voler potentiellement des mots de passe et des données de carte de crédit.

Une étape plus loin, et c'est de là que vient le terme tapjacking, les superpositions peuvent dessiner des éléments au-dessus d'autres applications en incitant l'utilisateur à effectuer différentes actions. L'utilisateur pense qu'il interagit avec la superposition, mais en réalité, ses touches exécutent également des actions dans l'application sous-jacente. De cette façon, la superposition peut vous inciter à activer certaines autorisations ou à modifier certains paramètres dangereux, comme illustré dans ce ancienne vidéo YouTube.

La vidéo de démonstration ci-dessus a été mise en ligne sur YouTube en 2010, elle a donc été réalisée sur une ancienne version d'Android. Mais l'attaque est toujours d'actualité aujourd'hui, car vulnérabilités a été découvert qui permet le tapjacking dans les nouvelles versions d'Android telles que Nougat et Marshmallow.

Alors, que peux-tu y faire ? En tant qu'utilisateur, il est important de prendre conscience des conséquences de ces superpositions et de connaître les applications qui les utilisent. À partir du niveau d'API 23 (Android 6.0 Marshmallow), c'est devenu une autorisation qui doit être explicitement accordé par l'utilisateur. Cependant, cela laisse 50 % d'Androidles utilisateurs restent vulnérables. Vous pouvez toujours vérifier quelles applications utilisent cette autorisation dans les paramètres sous « Afficher sur d'autres applications ».

En tant que développeurs, il nous appartient de nous assurer que les actions des utilisateurs sont effectuées en toute connaissance de cause et avec leur consentement. Android fournit un paramètre pour vos vues qui font exactement cela, appelé Le filtre touche lorsqu'il est masqué. Lorsqu'il est activé, le framework supprime les touches reçues chaque fois que la fenêtre des vues est masquée par une autre fenêtre visible. C'est aussi simple que cela, réglez Le filtre se touche lorsqu'il est masqué à true, et votre application est protégée contre le tapjacking.

Bonne chance et à la semaine prochaine !

Il est parfois essentiel qu'une application soit en mesure de vérifier qu'une action est effectuée en toute connaissance de cause et avec le consentement de l'utilisateur, par exemple en accordant une demande d'autorisation, en effectuant un achat ou en cliquant sur une publicité. Malheureusement, une application malveillante pourrait tenter d'inciter l'utilisateur à effectuer ces actions sans le savoir, en dissimulant l'objectif de la vue.

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

Publié à l'origine sur Blogue DevSecCon.

Ayant été des deux côtés de la barrière, je ne connais que trop bien les tensions qui peuvent survenir entre l'équipe de développement et les spécialistes AppSec lorsqu'il s'agit de faire respecter les meilleures pratiques en matière de sécurité.

C'est difficile ; en fin de compte, la principale priorité d'un développeur est de fournir des fonctionnalités logicielles. Ils doivent être beaux, fonctionnels et permettre de mettre en valeur la puissance de l'application. Les pratiques de développement agiles étant généralement utilisées de nos jours, ces fonctionnalités doivent être mises en œuvre dans des délais stricts... et la sécurité figure rarement en tête de liste des préoccupations alors que d'autres enjeux sont en jeu.

La sécurité est considérée comme le domaine de compétence de l'équipe AppSec, qui a la tâche peu enviable de scanner le code (ou pire encore, de le réviser manuellement, ligne par ligne) et de signaler à l'équipe de développement que son code n'est pas sécurisé, voire totalement inutilisable. Ce sont les bâtons dans la boue qui permettent de distinguer leur bon travail, de stopper l'innovation et, en général, de créer un casse-tête pour les développeurs. En fin de compte, de nombreux problèmes de sécurité ne peuvent être résolus que très simplement. Une seule ligne de code pourrait peut-être renforcer une porte dérobée vulnérable en quelques minutes.

Mais voici le problème. La « sécurité » étant synonyme d'expérience négative, les développeurs ne s'y intéressent tout simplement pas aussi étroitement qu'ils le devraient. Ces correctifs en une ligne ne se produisent pas : après tout, les gars d'AppSec rencontrent continuellement les mêmes problèmes. Cela doit être assez exaspérant pour eux de continuer à signaler des failles d'injection SQL, plus de vingt ans après leur découverte (et leur correction ultérieure).

Ce que nous avons fait jusqu'à présent ne fonctionne pas aussi efficacement que nous l'espérions. Nous devons nous concentrer sur la réparation du lien entre les développeurs et les spécialistes de la sécurité des applications, en nous efforçant de créer une culture de sécurité positive dans laquelle les développeurs reçoivent les outils et la formation nécessaires pour avoir un réel impact dans l'espace.

Qui sait ? Ils pourraient même en tomber amoureux comme moi !

La sécurité positive est le moyen le plus rapide et le plus simple d'améliorer la sécurité des applications

Ville « et non, il ne s'agit pas d'une question de résultats intangibles. Il s'agit d'un ingrédient absolument essentiel à la recette du succès du codage sécurisé.

Les développeurs détiennent la clé pour améliorer la sécurité dès le début de la production, en écrivant du code sécurisé en premier lieu. En créant une culture de sécurité positive et en suscitant l'intérêt des développeurs pour la sécurité des applications, les vulnérabilités courantes peuvent être supprimées avant même qu'elles ne soient numérisées ou révisées manuellement dans AppSec Land.

C'est il est trente fois plus coûteux de corriger des vulnérabilités dans un code déjà validé, donc trouver une formation qui tire parti des points forts des développeurs, qui suscite de l'intérêt et qui fonctionne réellement constitue une étape importante dans la réduction des coûts futurs liés à l'identification et à la correction de ces vulnérabilités récurrentes.

Les initiatives positives, centrées sur les développeurs, favorisent la mise en place d'une culture de sécurité adaptée.

Lorsque tout le monde est sur la même longueur d'onde en ce qui concerne les meilleures pratiques en matière de sécurité, une culture de sécurité positive est un sous-produit positif et vital.

Les initiatives positives et évolutives axées sur les développeurs favorisent la mise en place d'une culture de sécurité adaptée. Il est essentiel de faire appel à l'esprit créatif et à la résolution de problèmes des développeurs pour les convaincre, ainsi que pour garantir que les nouvelles recrues puissent répondre rapidement aux attentes de l'équipe en matière de sécurité. Entrer en contact pour un aperçu de l'évolution de la relation entre les développeurs en matière de sécurité et des idées pour déployer un programme de sensibilisation à la sécurité efficace dans vos propres organisations.

Deleting files on a computer system is tricky. Everybody, even your mother, has deleted a file too many before and has been happy to find it still in the trash and able to recover it.

Data in computer systems is represented by a sequence of bits. That means the system needs to do some bookkeeping within the file system to know which bits represent which file. Among this information is the size of the file, the time it was last modified, its owner, access permissions and so on. This bookkeeping data is stored separately from the contents of the file.

Usually, when a file is removed nothing happens to the bits representing the file, but the bookkeeping data is changed so that the system knows this part of the storage is now meaningless and can be reused. Until another file is saved in this location and the bits in this location are overwritten, you can often still recover the data that was saved. This not only improves the speed of deleting files but is often a useful feature to undo the deletion.

However, there are downsides to this approach. When an application on a computer system handles sensitive information it will save this data somewhere on the file system. At some point, when the information is no longer needed, this data may be deleted. If no extra care is taken this data may still be recoverable even though the intention of the developer was that all data was deleted.

The easiest way to completely erase that data is to rewrite the file content with random data (sometimes even several times over). There are several existing methods of secure file removal and they vary across storage types and file systems such as the Gutmann method. However, for day to day application use, these are a bit overkill and you can just overwrite the data yourself.

Be careful though! Do not use all zeros or other low entropy data. Many filesystems may optimize writing such sparse files and leave some of the original content. It is recommended to generate securely random data to overwrite the entire file contents before deleting the file itself.

Data remanence is the residual physical representation of data that has been in some way erased. After storage media is erased there may be some physical characteristics that allow data to be reconstructed.

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

Alors que le nombre de cybermenaces ne cesse de croître, les entreprises font des compromis quotidiens entre sécurité, praticité et rapidité, s'exposant ainsi à des risques. De nouvelles approches de codage sécurisé sont nécessaires, donc Secure Code Warrior a collaboré avec Evans Data Corp. pour mener des recherches primaires sur les attitudes des développeurs à l'égard du codage sécurisé, des pratiques de code sécurisées et des opérations de sécurité (télécharger le livre blanc) ici).

Ce rapport a révélé que si la pensée réactive « à l'ancienne » domine toujours, il existe une prise de conscience croissante de la nécessité de solutions plus proactives, qui font des développeurs eux-mêmes la première ligne de défense.

Toute exploration de l'adoption de pratiques de codage sécurisées doit commencer par une compréhension des humains impliqués dans leur mise en œuvre, de leur perception de celle-ci et de leur capacité à les mettre en œuvre. Cela nous amène à la pièce la plus importante du puzzle : comment leur donner les moyens de coder de manière plus sécurisée dès le départ et d'envoyer du code de qualité plus rapidement et en toute confiance ?

Codage sécurisé : où en sommes-nous aujourd'hui et qu'est-ce qui doit changer ? Télécharger l'infographie « L'élément humain » maintenant.

Perspectives actuelles : réactives ou proactives

Lorsque les développeurs et les responsables du développement ont été interrogés sur les activités qu'ils associent au codage sécurisé, les trois réponses les plus fréquentes ont été les suivantes :

• Utilisation d'outils d'analyse sur les applications déployées.
• Vérification manuelle du code pour détecter les vulnérabilités.
• Pratique active et continue de l'écriture de logiciels protégés contre les vulnérabilités.

Comme nous pouvons le constater, deux des trois réponses les plus fréquentes se concentraient toujours sur les approches réactives : la première dépendait de l'outillage (scanners) et la seconde du développeur (c'est-à-dire humain) effectuant des vérifications manuelles.

Dans le même temps, deux des trois activités nominées font appel à l'élément humain. Cela montre que la sécurité est de plus en plus perçue comme une question humaine. Mais de toutes les activités nominées, la plus révélatrice est la troisième, qui identifie le facteur humain un logiciel écrit qui est protégé contre les vulnérabilités en premier lieu. Cela met en évidence un changement vers la gauche : une approche proactive et préventive qui intègre la sécurité dans les logiciels dès le début du SDLC.

Quelle est la place de la sécurité dans le SDLC ?

Lorsqu'on demande aux développeurs et aux responsables du développement comment ils envisagent l'intégration de pratiques de code sécurisées dans le SDLC, les avis divergent. 55 % des responsables pensent que le codage sécurisé est intégré à l'ensemble du processus de développement, contre seulement 43 % des développeurs. La différence pourrait refléter les rôles différents de ces deux groupes au sein du SDLC. La direction est généralement moins impliquée dans le travail de programmation proprement dit et a tendance à avoir une vision plus globale, tandis que les développeurs peuvent être plus préoccupés par les détails.

Mais du point de vue de la sécurité globale et de la qualité du code, ce qui est alarmant, c'est que seuls 13 % des développeurs et 10 % des responsables déclarent que les pratiques de code sécurisées devraient être intégrées dès les étapes de conception, dès le début du SDLC. Il s'agit d'une opportunité énorme et non exploitée. Selon une étude d'IBM, il est trente fois plus coûteux de corriger les vulnérabilités présentes dans le code après la publication que si elles étaient détectées et corrigées au début.1 Cela constitue une puissante incitation à une nouvelle défense proactive et dirigée par l'homme en matière de sécurité logicielle, qui donne aux développeurs les moyens de coder de manière plus sécurisée, dès le départ. La sécurité des logiciels ne peut pas être résolue en se fiant uniquement à l'outillage : elle doit tenir compte de l'élément humain.

L'élément humain est-il préparé ?

97 % des développeurs interrogés estiment avoir reçu une formation suffisante en matière de codage sécurisé, et 95 % ont reconnu que la formation au codage sécurisé avait été précieuse pour leur carrière. Mais avant d'accepter ces affirmations pour argent comptant, nous devons nous demander : pourquoi les vulnérabilités du code sont-elles toujours aussi répandues ? Les affirmations des développeurs concernant leur expertise en matière de code sécurisé ne sont-elles qu'un cas d'ego humain ? Les preuves vont certainement dans ce sens. Plus modestement, plus de 88 % des développeurs interrogés admettent que le codage sécurisé est difficile à apprendre, et 91 % des responsables du développement reconnaissent que les pratiques de codage sécurisé sont difficiles à mettre en œuvre. Lorsqu'on leur demande d'identifier leurs principales préoccupations personnelles concernant la mise en œuvre de code sécurisé, 28 % des développeurs trouvent le processus d'apprentissage difficile, tandis que 24 % le trouvent ennuyeux. Cela montre que la formation des développeurs doit être améliorée.

De quoi a besoin l'élément humain ?

Pour surmonter le facteur « difficile », une formation sécurisée intéressante nécessite un processus « d'échafaudage » qui aide le développeur à acquérir des compétences de codage sécurisé étape par étape. Pour une pertinence maximale et une applicabilité immédiate, cette formation doit être dispensée dans le langage spécifique : cadre qu'ils utilisent au quotidien.

Pour surmonter le facteur « ennui », la formation au code sécurisé doit être dispensée de manière pratique, ce qui s'est avéré bien plus intéressant pour les développeurs que les modèles obsolètes en classe ou « regardez cette vidéo ». Celles-ci devraient inclure des simulations en direct qui permettent aux développeurs de relever des défis de sécurité parfois risqués dans un environnement sûr. L'objectif devrait être d'apprendre aux développeurs à détecter et à corriger les vulnérabilités dans le code pendant qu'il travaille et à intégrer le codage sécurisé à leur flux quotidien. Un autre facteur clé est le linting et le coaching à l'intérieur de l'IDE, qui aident les développeurs à constamment apprendre et à améliorer leurs compétences au fur et à mesure qu'ils codent, tout en prévenant et en éliminant les vulnérabilités au fur et à mesure.

Si vous souhaitez savoir comment fournir à vos développeurs ce nouveau niveau d'outils et de formations centrés sur les développeurs, réservez une démo maintenant.

Vous pouvez également téléchargez votre copie du livre blanc Passer de la réaction à la prévention : le nouveau visage de la sécurité des applications

‍

Les cyberattaques sont, sans aucun doute, en augmentation. Selon le rapport d'enquête sur les violations de données 2021 de Verizon, le paysage des menaces est plus dangereux aujourd'hui plus que jamais. Les organisations de toutes tailles sont confrontées à un volume d'attaques de plus en plus important et à un niveau de sophistication accru de la part des acteurs malveillants qui les ciblent. Et les taux de réussite des attaquants montent également en flèche.

L'analyse des attaques les plus récentes permet de révéler certaines des vulnérabilités et techniques les plus courantes utilisées par les pirates informatiques lors de cette campagne sans précédent contre les cyberdéfenses. Certaines des attaques les plus populaires, telles que celles qui ont permis à l'Open Web Application Security Project (OWASP) Les 10 principaux risques et vulnérabilités de sécurité pour 2021, impliquait le vol ou la compromission d'informations d'identification. Et selon des recherches sur la sécurité menée par Akamai, l'écrasante majorité (près de 75 %) ciblait directement les informations d'identification détenues par les API.

L'essor et la possible ruine des API

Il n'est pas étonnant que les interfaces de programmation d'applications, pour la plupart simplement appelées API, soient en plein essor au sein des réseaux de presque toutes les organisations. Ils constituent un élément essentiel de la plupart des services basés sur le cloud, qui prennent rapidement en charge les fonctions des actifs sur site dans la plupart des entreprises, organisations et agences gouvernementales. De nos jours, il est quasiment impossible de gérer une activité ou une tâche sans le cloud, en particulier celles qui sont destinées au public. Cela signifie que les API seront certainement le ciment qui permettra à de nombreux services de fonctionner ensemble sur chaque réseau.

L'avantage des API est qu'elles sont pour la plupart petites et discrètes en termes d'allocation des ressources réseau. Et ils sont totalement flexibles, de sorte qu'ils peuvent être chargés d'effectuer presque tous les travaux. À la base, les API sont des logiciels individuels conçus pour contrôler ou gérer un programme particulier. Ils peuvent être utilisés pour exécuter des fonctions très spécifiques, telles que l'accès à des données à partir d'un système d'exploitation, d'une application ou d'un service hôte.

Malheureusement, c'est cette même flexibilité et le fait qu'elles soient souvent petites et négligées par les équipes de sécurité qui font des API des cibles attrayantes. La plupart des API sont conçues par les développeurs pour une flexibilité totale afin qu'elles puissent, par exemple, continuer à fonctionner même si le programme principal qu'ils gèrent est modifié ou modifié. Et il existe peu de normes. Presque comme les flocons de neige, de nombreuses API sont uniques en ce sens qu'elles sont créées pour remplir une fonction particulière avec un seul programme sur un réseau spécifique. S'ils sont codés par des développeurs qui ne sont pas très attentifs à la sécurité ou qui ne se concentrent pas spécifiquement sur la sécurité, ils peuvent et auront probablement un certain nombre de vulnérabilités que les attaquants peuvent trouver et exploiter.

Malheureusement, le problème devient rapidement incontrôlable. Selon Gartner, d'ici 2022, vulnérabilités impliquant des API deviendra le vecteur d'attaque le plus fréquent dans toutes les catégories de cybersécurité.

La principale raison pour laquelle les attaquants veulent compromettre les API n'est pas pour s'emparer d'une fonction spécifique exécutée par l'API, mais pour voler les informations d'identification qui y sont associées. L'un des plus gros problèmes des API, en plus d'être truffées de vulnérabilités, est qu'elles sont souvent manière trop autorisée en ce qui concerne leurs fonctionnalités de base. Par souci de simplicité, la plupart des API disposent d'un accès proche du niveau administrateur sur un réseau. Si un attaquant prend le contrôle d'un réseau, il peut souvent utiliser ses autorisations pour lancer des incursions plus profondes et plus importantes dans un réseau. Et comme l'API est autorisée à effectuer toutes les tâches vers lesquelles l'attaquant le redirige, ses actions peuvent souvent contourner la surveillance traditionnelle de la cybersécurité, car l'API n'enfreint aucune règle grâce à son pass VIP d'accès aux coulisses.

Si les entreprises ne font pas attention, la montée en puissance des API au sein de leur réseau et de leurs clouds peut également poser de gros problèmes si elles sont la cible d'attaquants.

Défendre les API

Aussi dangereuse que soit la situation en matière d'API, elle est loin d'être désespérée. Il y a un gros effort à travers les mouvements comme DevSecOps pour sensibiliser les développeurs à la sécurité et pour intégrer la sécurité et les meilleures pratiques à tous les aspects de la création de logiciels, du développement aux tests et au déploiement. L'inclusion de la sécurité des API dans cette formation sera essentielle pour toute organisation qui souhaite inverser la tendance de l'exploitation des API d'ici 2022 et au-delà.

Cela dit, il existe quelques bonnes pratiques qui peuvent être mises en œuvre dès maintenant en termes de sécurité des API.

La première chose à faire est d'inclure des contrôles d'identité stricts pour toutes les API. Vous devriez presque les considérer comme des utilisateurs humains lorsque vous attribuez des autorisations. Tout simplement parce qu'une API est conçue uniquement pour exécuter une fonction spécifique, vous devez réfléchir à ce qui pourrait se passer si un attaquant parvenait à la compromettre. Envisagez d'utiliser un contrôle d'accès basé sur les rôles. Idéalement, vous devriez au final appliquer les principes de confiance zéro à vos API et à vos utilisateurs, mais le chemin est souvent long. Une bonne gestion des identités est un bon point de départ. Assurez-vous simplement d'inclure des API dans ce programme.

Vous devez également contrôler étroitement les différents appels effectués par vos API autant que possible. Si vous limitez ces appels à des requêtes très contextuelles, il sera beaucoup plus difficile pour un attaquant de les modifier à des fins malveillantes. Vous pouvez même superposer vos API, une API initiale effectuant un appel hautement contextuel à une autre API qui sait exactement ce qu'il faut rechercher et ce qu'il faut ignorer. Cela peut être un moyen efficace de limiter les fonctionnalités disponibles pour un acteur de la menace, même s'il est capable d'exploiter et de compromettre une API au sein de cette chaîne.

Les menaces qui pèsent sur les API peuvent certainement sembler insurmontables. Mais en mettant en œuvre les meilleures pratiques tout en aidant et en récompensant les développeurs qui deviennent des champions de la sécurité, la situation peut sembler bien moins désespérée. Avec une bonne formation et de l'entraînement, vous pouvez mettre en place un programme de sécurité robuste qui laisse peu de marge de manœuvre aux attaquants, même s'ils devaient d'une manière ou d'une autre compromettre l'un de vos outils d'API, minuscules mais essentiels.

En tant que professionnel de la sécurité des applications, il est de votre devoir de garantir la cybersécurité des applications de votre organisation. Vous n'êtes toutefois pas responsable de l'écriture du code sur lequel l'application s'exécute. Les ingénieurs de l'équipe de développement sont. Alors, comment s'assurer qu'ils développent ces systèmes en tenant compte de la sécurité ?

Il est fort probable que vous fassiez certaines ou même la totalité des opérations suivantes :

• Examiner tout le code pour détecter les failles de sécurité et les signaler à l'équipe de développement pour qu'elle les corrige.
• Appliquer un processus d'évaluation par les pairs strict tout au long de votre cycle de développement sécurisé.
• Faire effectuer régulièrement des tests d'évaluation et d'intrusion des applications par des équipes de sécurité internes ou externes.
• Mise en œuvre d'outils d'analyse pour détecter les vulnérabilités.
  

Ce sont d'excellentes pratiques exemplaires, mais elles sont également coûteuses et similaires à la prise d'antibiotiques chaque fois que vous tombez malade. Non seulement cela a un coût élevé, mais cela perd de son efficacité et peut affaiblir votre système immunitaire au fil du temps.

Comment faites-vous pour vous assurer que le code fourni par les développeurs est écrit de manière sécurisée en premier lieu ?

Au-delà du codage sécurisé, pensez d'abord à la façon dont les gens apprennent. La plupart d'entre nous sont des apprenants visuels et nous apprenons par la pratique. Pourtant, la formation au code sécurisé est souvent proposée sous la forme d'une activité à cocher et n'est pas pertinente pour le travail quotidien des développeurs. Il est conçu pour prouver que les développeurs ont souvent suivi une formation en matière de sécurité pour se conformer aux normes du secteur, et non pour que les développeurs conservent ces connaissances, et encore moins pour profiter du processus d'apprentissage.

Les humains ont également tendance à apprendre en faisant des erreurs, de la même manière que notre système immunitaire. Les lymphocytes T se souviennent des types d'agents pathogènes qu'ils ont rencontrés et qu'ils ont réussi à éradiquer dans le passé, afin de pouvoir s'en protéger à l'avenir. C'est exactement le rôle que les développeurs devraient jouer dans votre sécuriser SDLC.

Il est irréaliste de s'attendre à ce qu'ils ne commettent pas d'erreur, mais vous pouvez les préparer de manière à être en mesure de reconnaître les modèles de codage qui se traduiront par des failles de sécurité à l'avenir.

C'est également ainsi qu'un solide processus d'évaluation par les pairs devient si puissant. Ce n'est pas parce qu'un développeur ne remarque pas de faille de sécurité qu'un autre ne le remarquera pas. Et plus l'équipe de développement est formée dans son ensemble, plus les vulnérabilités ont de chances d'être détectées et de ne jamais être mises en production.

Les vulnérabilités logicielles sont comme des agents pathogènes

Les vulnérabilités logicielles sont comme des agents pathogènes dans le sens où vous devez vous en souvenir pour les combattre. En ce qui concerne les agents pathogènes, notre système immunitaire doit souvent être exposé à plusieurs reprises avant de se rappeler comment les combattre afin d'éviter une maladie grave ou pire encore.

Une cyberattaque réussie à partir d'un logiciel vulnérable peut gravement paralyser ou tuer une organisation. Mais si les développeurs découvrent d'abord les vulnérabilités logicielles dans un environnement contrôlé, ils peuvent renforcer leur immunité contre les menaces en améliorant et en mettant régulièrement en pratique leurs connaissances et compétences en matière de codage sécurisé.

Exposez les développeurs à des failles de sécurité dans un environnement contrôlé

Nous ne pouvons jamais nous protéger complètement contre la maladie, mais nous pouvons prendre certaines mesures pour renforcer notre système immunitaire et rester en aussi bonne santé que possible. Faire de l'exercice régulièrement, manger sainement et dormir suffisamment font partie des choix de vie généralement associés à un système immunitaire fort. Mais toutes ces choses demandent un peu d'effort et doivent être continues. Faire du jogging tous les jours pendant une semaine ou arrêter de boire pendant un mois ne nuira guère à votre état de santé général. Il est également déconseillé de sortir et de courir un 10 km le premier jour où nous commençons à courir. Nous devons d'abord exposer notre cœur et nos muscles à l'exercice. Nous savons également qu'il faut un peu d'expérimentation pour trouver un bon équilibre entre notre corps et des aliments sains et des exercices que nous aimons.

Il n'en va pas autrement lorsqu'il s'agit de développer des logiciels sécurisés. L'apprentissage se fait au fil du temps et de la pratique, et les développeurs ont besoin de la même formation continue pour améliorer régulièrement leurs compétences en matière de codage sécurisé. Sans oublier que le développement de logiciels évolue et s'adapte constamment, ce qui signifie que les vulnérabilités le sont également. C'est pourquoi une simple formation ne suffit pas. Les développeurs doivent régulièrement améliorer leurs compétences afin de se familiariser suffisamment avec les menaces potentielles et d'être correctement équipés pour s'en défendre.

Objectif : atteindre l'immunité collective au sein de l'équipe de développement

Une seule personne ne peut prévenir tous les problèmes de sécurité. C'est formidable d'avoir des champions de la sécurité au sein de l'équipe, mais pour bénéficier de la meilleure protection possible, plus il y a de personnes qui connaissent les failles de sécurité et savent comment les prévenir, meilleures sont les chances de votre organisation de les prévenir. Encore une fois, ce n'est pas très différent de la façon dont le système immunitaire possède différents types de lymphocytes T à des fins différentes. Chaque développeur fait partie d'une équipe qui garantit la sécurité. S'ils sont habilités à prendre leurs responsabilités, à bien le faire et même à aimer le faire, vous pouvez ainsi créer une immunité collective contre les cybermenaces au sein de l'équipe de développement.

Faites de la sécurité une priorité grâce à une exposition répétée

Notre cerveau apprend de la même manière que notre système immunitaire. Psychologue allemand Hermann Ebbinghaus a été un pionnier dans le domaine de la mémoire et de l'apprentissage. Il en a déduit que l'apprentissage doit se faire au fil du temps et au cours de plusieurs sessions d'apprentissage. Lorsque nous sommes à l'école, on ne s'attend jamais à ce que nous maintenions de nouvelles connaissances après la première introduction. Les informations nous sont d'abord présentées, puis nous les mettons en pratique avec des conseils, puis nous les pratiquons nous-mêmes. Et même une fois que nous l'avons suffisamment bien apprise pour réussir un examen, l'information a tendance à être oubliée peu de temps après si nous n'utilisons pas régulièrement les connaissances que nous avons consacrées au temps et aux efforts nécessaires pour acquérir. Combien d'entre nous peuvent dire qu'ils se souviennent du français de leur lycée ?

Alors, comment pouvons-nous croire qu'une seule journée passée à regarder des diapositives et à écouter quelqu'un parler de sécurité conduirait les développeurs présents à coder de manière plus sécurisée ?

Les modèles de vulnérabilités récurrentes nous montrent que cela ne fonctionne tout simplement pas.

Comment parvenir à une immunité développementale sûre ?

La réponse se trouve dans notre nature. Notre corps et notre esprit fonctionnent de la même manière et apportent de belles solutions aux problèmes, à condition de travailler avec eux et non contre eux.

Pour garantir la sécurité de vos applications, vous devez commencer par améliorer les compétences des développeurs pour qu'ils puissent écrire du code sécurisé. Dans le cas contraire, AppSec continuera à passer tout son temps à examiner tout le code pour détecter les failles de sécurité et à signaler les mêmes vulnérabilités récurrentes au développement, pour être rapidement corrigées sans aucune leçon. Et recommencez pour la prochaine version.

Réitérons donc.

Si vous travaillez en collaboration avec vos responsables du développement pour y parvenir, vous ne vous contenterez pas de mettre en œuvre un SDLC sécurisé et de cocher la case relative aux exigences de formation en matière de sécurité pour la conformité, vous aurez également un impact réel sur le processus de développement. Cerise sur le gâteau, AppSec ne rencontrera plus de vulnérabilités récurrentes et ne les signalera plus aux équipes de développement, et les développeurs passeront moins de temps à les corriger. Cela signifie qu'ils peuvent consacrer plus de temps à créer et à améliorer les logiciels incroyables qui améliorent notre monde.

Êtes-vous prêt à améliorer les compétences de votre équipe de développement ? Allez-y et réservez une démo avec nous.

Bien que cela puisse sembler contre-intuitif pour quiconque travaille en dehors du développement logiciel, de nombreux professionnels employés dans le domaine de la sécurité des applications au fil des ans ont occupé ces postes critiques avec peu ou pas d'expérience en programmation. Ces professionnels de la sécurité des applications font partie de l'équipe chargée de s'assurer qu'aucune vulnérabilité ne s'infiltre dans les applications qui sont devenues la pierre angulaire de nombreux secteurs et organisations. Pourtant, peu d'entre eux peuvent évaluer directement ou corriger le code eux-mêmes.

Au lieu d'avoir une formation en programmation, de nombreux professionnels de la sécurité abordent leurs rôles du point de vue des connaissances clés concernant les vecteurs d'attaque, les menaces, les exploits et les risques commerciaux ; ils ont une vision limitée du code. Bien que tous les experts de la sécurité des applications ne possèdent pas les mêmes compétences, une journée typique consiste pour beaucoup à travailler avec des réviseurs de code et des outils d'analyse pour s'assurer que les programmes et les systèmes sont sécurisés conformément aux normes organisationnelles ou aux cadres industriels et gouvernementaux pertinents. Ils rédigent ensuite des rapports sur leurs découvertes et renvoient des informations sur le vecteur d'attaque susceptible de déchiffrer le code. Il appartient ensuite aux développeurs d'apporter les correctifs nécessaires, même si cela perturbe le travail en cours.

Si la situation a évolué de cette façon, c'est parce que la logique qui a prévalu au fil des ans était que la tâche de protéger les réseaux et les applications était si vaste qu'il n'était pas logique de s'attendre à ce que tous les acteurs de la cybersécurité jouent tous les rôles. Des compétences approfondies en matière de codage ont été laissées aux développeurs, et peu d'importance a été accordée à la capacité d'écrire ou de modifier du code plus loin dans le pipeline de développement.

Cet état d'esprit évolue rapidement, ce qui représente une opportunité unique pour les développeurs de faire le saut lucratif et de réorienter leur carrière dans l'AppSec. Tous les développeurs ne voudront pas adopter ce que l'on appelle le côté obscur, et de nombreux développeurs n'ont pas une opinion particulièrement positive à l'égard des équipes AppSec. Mais pour ceux qui le font, il n'y a jamais eu de meilleur moment pour s'emparer de cette bague en laiton de plus en plus tentante.

DevSecOps est au cœur de presque tous les secteurs

L'un des principaux facteurs qui contribuent à augmenter la valeur des programmeurs et des développeurs soucieux de la sécurité dans toute organisation est la tendance quasi universelle à adopter des pratiques de développement plus agiles. comme DevSecOps. Lorsque le développement, la sécurité et les opérations sont combinés, la cybersécurité devient une responsabilité partagée intégrée au développement de nouveaux logiciels de bout en bout. Dans cet environnement, la capacité à coder est de plus en plus considérée comme un atout précieux à tous les niveaux, et cela est particulièrement vrai pour les ingénieurs qui comprennent également la sécurité de manière inhérente.

Un professionnel de la sécurité des applications qui comprend non seulement la cybersécurité à un niveau élevé, mais aussi le code qui fait que tout fonctionne, est intrinsèquement plus précieux pour toute organisation qu'une personne dont les connaissances sont concentrées sur la théorie. La capacité de découvrir et d'évaluer rapidement les vulnérabilités détectées dans le code, puis d'atténuer ces problèmes, est au cœur de la popularité de DevSecOps.

Les développeurs travaillant dans AppSec apportent également un autre avantage important à toute organisation qui les emploie. En venant du côté développement de la maison, ils peuvent facilement discuter avec les développeurs de la sécurité et des vulnérabilités. Cela permet également de devenir beaucoup plus facilement des entraîneurs pour les équipes de développement, les aidant ainsi à devenir de meilleurs codeurs. Au fil du temps, ils pourraient même être en mesure de supprimer la stigmatisation du « côté obscur » de l'AppSec et de contribuer à unifier les équipes chargées du développement logiciel au sein d'une organisation.

La pénurie de compétences en cybersécurité s'aggrave

Shakespeare pensait que c'est un vent mauvais qui ne souffle rien de bon pour personne. Ce qu'il voulait dire, c'est que même la situation la plus sombre profite probablement à quelqu'un. La pénurie de compétences en cybersécurité en est un excellent exemple.

La pénurie de personnel est ressentie de manière aiguë presque partout. Dans un enquête récente menée par le Center for Strategic and International Studies, 82 % des décideurs informatiques ont déclaré que leur organisation souffrait d'une pénurie de compétences en cybersécurité, et 71 % ont déclaré que cette pénurie avait entraîné des dommages directs et mesurables pour leurs organisations. Pour mettre cette crise dans une perspective encore meilleure, le rapport a souligné que rien qu'aux États-Unis, il y avait plus de 520 000 emplois vacants dans le domaine de la cybersécurité en 2020, dans un domaine où seulement 940 000 personnes environ sont employées.

La pénurie de personnel en cybersécurité est une mauvaise nouvelle pour les organisations qui tentent de protéger leur infrastructure, leurs activités et leurs données contre un paysage de menaces de plus en plus dangereux. Mais c'est une bonne opportunité pour les développeurs qui souhaitent se familiariser avec AppSec et la sécurité. Il y a de fortes chances que des postes en cybersécurité et en AppSec soient disponibles presque partout. Et avec des positions en matière de cybersécurité qui occupent en moyenne 21 % de temps en plus pour occuper ces journées, les salaires augmentent dans tous les domaines.

Passer à AppSec

Il n'y a peut-être jamais de meilleur moment pour les développeurs de faire le saut lucratif vers le côté ensoleillé de la sécurité. Les développeurs soucieux de la sécurité ne sont plus considérés comme faisant partie d'une méthode de sécurité provisoire, mais jouent plutôt un rôle à part entière et respecté en tant que défenseurs de la cybersécurité. Cela est particulièrement vrai pour les organisations qui ont adopté DevSecOps et d'autres méthodologies de développement plus agiles. Et la pénurie de talents en cybersécurité signifie que des postes sont disponibles dans presque toutes les entreprises, agences gouvernementales ou organisations. Les personnes possédant les compétences requises peuvent choisir l'endroit où elles souhaitent travailler.

Le passage à AppSec ne convient peut-être pas à tout le monde et, bien entendu, la plupart des développeurs continueront à se concentrer sur la création de fonctionnalités exceptionnelles. Mais pour ceux qui envisagent de faire le saut, investir dans une formation à la sécurité afin d'améliorer leurs compétences de codage existantes peut ouvrir de nombreuses portes. Les meilleurs spécialistes de l'AppSec sont issus de l'ingénierie, car ils comprennent parfaitement la technologie et ont de l'empathie pour le sort de leurs collègues développeurs. DevSecOps signifie que tout le monde est désormais responsable de la sécurité de toute façon, alors pourquoi ne pas profiter de la pénurie de compétences critique actuelle pour faire avancer votre carrière dans la sécurité des applications ? Il n'y a jamais eu de meilleur moment pour prendre une décision positive pour vous-même, votre famille et votre carrière.

A side-channel attack is when a hacker can gather information from the physical implementation of a software system rather than a theoretical weakness in the algorithm or bug in the code of the software.

An example I like to use to make this more clear is a way to do username enumeration. If you want to know what username enumeration is or why it is bad, visit our website for a video explanation or play a challenge to see if you can identify it in code.

Now in order to understand how username enumeration can be done through a side-channel attack, you need to have some understanding of how passwords are (or at least should be) handled in modern web applications. A good web application doesn't know your password, it doesn't save or store your password anywhere. So how does it know that what you typed is correct and in fact your password? Well, your password is hashed.

A hashing function is a mathematical operation that is easy to perform one way (although somewhat computationally expensive) but very difficult to reverse and for good hashing algorithms, the output is unique depending on the input. When you register on a website, that hash is stored safely, not your password itself. That means that every time you log-in, the web application hashes your input and compares the hashed results to the stored hash. If you want to learn more about secure password storage, you can do that on our platform.

Hashing input takes some time on a computer and developers always try to optimize everything they write in order for the users to have a smooth experience. One thing that speeds up the program is to skip the hashing when it is not needed. For example, when the username does not exist (and so no password needs to be checked) they can respond to the user immediately. This way they can skip the slow computation of hashing the password. If the username was correct they will hash the password input and compare that to the stored hash.

At this point, you might have guessed where things can go wrong. Even though in reality the hashing takes only a few milliseconds, a hacker can use this added delay to find out if the username he entered was correct or not since a wrong username will have a slightly faster response because no hashing was done. This type of side-channel attack is called a timing attack and it is a good example for how different non-functional requirements can counteract each other. Sometimes code cannot be fast and secure at the same time.

So even though the passwords are handled perfectly, and the message that is displayed is generic and does not advise whether the password or username was incorrect, the system is still vulnerable. The solution is easy, always hash the password or delay sending the reply the time it would take to hash.

The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.

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