Directeur de la stratégie client. Chef Singh et cofondateur.
Jaap Karan Singh
Jaap Karan Singh est directeur de la stratégie client, Chief Singh et cofondateur de Secure Code Warrior. Après des tests de sécurité chez BAE Systems en Australie, Jaap est passé du piratage d'applications Web à la formation des développeurs sur la manière de protéger leurs propres applications. Jaap conçoit et met en œuvre l'ensemble de la stratégie client, qui comprend la réussite client, les renouvellements, le support, les opérations et le marketing client.
Basé à Sydney, Jaap a dispensé des formations sur les concepts de sécurité logicielle et a organisé des ateliers dans les principales organisations financières et de télécommunications du monde entier. Il est spécialisé dans les technologies Javascript telles que HTML5, Node, Express et Mongo.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Lorsque votre application Web révèle trop d'informations, elle peut permettre aux attaquants de s'y introduire plus facilement. Dans cet article, nous expliquerons ce qu'est l'exposition aux informations, pourquoi elle est dangereuse et comment la prévenir.
La grande majorité des sites Web utilisent des bases de données XML pour exécuter des fonctions critiques telles que la conservation des informations de connexion des utilisateurs, des informations sur les clients, des informations d'identité personnelle et des données confidentielles ou sensibles, laissant aux attaques XQuery une empreinte d'attaque assez importante.
Les attaques par injection de code sont parmi les plus courantes, mais aussi les plus dangereuses, auxquelles de nombreux sites Web et applications seront confrontés. Ils sont très variés en termes de sophistication et de danger, mais presque tous les sites ou applications qui acceptent les entrées des utilisateurs peuvent être vulnérables.
Contrairement à de nombreuses vulnérabilités, l'exploitation des processus locaux d'inclusion de fichiers et de traversée de chemins à des fins malveillantes nécessite un attaquant suffisamment qualifié, pas mal de temps et peut-être un peu de chance.
Il est courant que les sites Web et les applications permettent aux utilisateurs d'envoyer des commentaires et diverses autres informations via une application par courrier électronique. Et la plupart des gens n'y pensent même pas en termes de risque de sécurité potentiel.
Des problèmes peuvent survenir lorsque des utilisateurs malveillants peuvent manipuler une requête LDAP. Cela peut inciter le serveur récepteur à exécuter des requêtes non valides qui ne seraient normalement pas autorisées, ou même à accorder un accès administrateur ou de haut niveau à des utilisateurs non valides ou peu sécurisés sans mot de passe.
Les attaquants utilisent l'injection SQL, l'une des plus anciennes (depuis 1998 !) et les vulnérabilités de données les plus embêtantes du marché, visant à voler et à modifier les informations sensibles disponibles dans des millions de bases de données dans le monde entier.
À bien des égards, la vulnérabilité d'inclusion de fichiers distants est beaucoup plus dangereuse et plus facile à exploiter que son équivalent local. En tant que tel, il convient de le trouver et d'y remédier dès que possible.
Les sessions sont essentielles à une bonne expérience utilisateur lors de l'utilisation du Web. Cependant, une gestion incorrecte des sessions peut entraîner des failles de sécurité que les attaquants peuvent exploiter.
Une journalisation et une surveillance insuffisantes constituent l'une des conditions les plus dangereuses qui puissent exister au sein de la structure défensive d'une application. Si cette vulnérabilité ou cette condition existe, presque toutes les attaques avancées lancées contre elle finiront par réussir.
L'exposition de données sensibles se produit chaque fois que des informations destinées uniquement à une consultation autorisée sont exposées à une personne non autorisée dans un état non chiffré, non protégé ou faiblement protégé.
Même si vous avez complètement sécurisé un serveur d'applications et les systèmes principaux qu'il utilise, les communications peuvent toujours être vulnérables à l'espionnage si la protection de la couche de transport est insuffisante.
Lorsque vous créez une application métier, que ce soit pour un usage interne ou externe par vos clients, vous ne laissez probablement pas chaque utilisateur exécuter toutes les fonctions. Si vous le faites, vous risquez d'être vulnérable à une violation du contrôle d'accès.
Bien que les problèmes de codage puissent être à l'origine du problème, les erreurs de logique métier sont le plus souvent le résultat de défauts de conception ou d'hypothèses logiques incorrectes lors de la création initiale d'une application.
Le cross-site scripting (XSS) utilise la confiance des navigateurs et l'ignorance des utilisateurs pour voler des données, prendre le contrôle de comptes et dégrader des sites Web ; il s'agit d'une vulnérabilité qui peut devenir très rapidement très dangereuse. Voyons comment fonctionne le XSS, quels dommages peuvent être causés et comment les prévenir.
Les bases de données NoSQL sont de plus en plus populaires. Il est difficile de nier leur rapidité et leur facilité de traitement des données non structurées, mais à mesure que leur utilisation se généralise, de nouvelles vulnérabilités apparaissent inévitablement.
Une référence directe à un objet se produit lorsqu'un enregistrement spécifique (l' « objet ») est référencé dans une application. Il prend généralement la forme d'un identifiant unique et peut apparaître dans une URL.
Une désérialisation non sécurisée peut se produire chaque fois qu'une application considère les données en cours de désérialisation comme étant fiables. Si un utilisateur est en mesure de modifier les données récemment reconstruites, il peut effectuer toutes sortes d'activités malveillantes telles que des injections de code, des attaques par déni de service ou l'élévation de ses privilèges.
Nous allons aborder l'un des problèmes les plus courants rencontrés par les organisations qui gèrent des sites Web ou qui permettent à leurs employés d'accéder à distance à des ressources informatiques, ce qui concerne à peu près tout le monde. Et oui, vous avez probablement deviné que nous allons parler d'authentification.
Les attaques par injection XML sont de vilains petits exploits inventés par des pirates informatiques pour les aider à compromettre les systèmes hébergeant des bases de données XML. Cela inclut le genre de choses qui viennent à l'esprit lorsque l'on pense aux bases de données traditionnelles, à savoir des magasins détaillés d'informations sur tout, des médicaments aux films.
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é. Il existe toutefois une meilleure approche.
Les attaques CSRF sont assez complexes et reposent sur plusieurs couches pour réussir. En d'autres termes, beaucoup de choses doivent se passer en faveur de l'attaquant pour que cela fonctionne. Malgré cela, ils constituent un vecteur d'attaque extrêmement populaire et lucratif.
Si un attaquant peut insérer un code CR ou LF dans une application existante, il peut parfois modifier son comportement. Les effets sont moins faciles à prévoir que ceux de la plupart des attaques, mais ils ne peuvent pas être moins dangereux pour l'organisation cible.
Si une application ne dispose pas de contrôles anti-automatisation suffisants, les attaquants peuvent simplement continuer à deviner les mots de passe jusqu'à ce qu'ils trouvent une correspondance. Voici comment les en empêcher.
En matière de cybersécurité, les attaquants peuvent exploiter rapidement n'importe quelle application ou programme autorisé à prendre en charge le téléchargement de fichiers sans restriction. Et les résultats peuvent être dévastateurs.
Les attaques par injection de commandes du système d'exploitation peuvent être effectuées par des pirates informatiques débutants et moins expérimentés, ce qui en fait l'une des faiblesses les plus courantes rencontrées par les équipes de sécurité. Heureusement, il existe de nombreux moyens très efficaces de les empêcher de réussir.
Il est vraiment ahurissant de constater que de nombreux établissements comptent encore sur des salles de classe, des manuels scolaires arides et des formations vidéo époustouflantes pour intégrer le meilleur d'eux-mêmes à de nouvelles initiatives, en particulier lorsqu'il existe une méthode d'apprentissage bien meilleure, plus engageante et plus utile : la formation contextuelle.
Étant donné que toutes les applications utilisent des composants, dont la plupart ne sont pas écrits par vous, les vulnérabilités des composants que vous utilisez peuvent devenir des responsabilités. Discutons de ce que signifie l'utilisation de composants présentant des vulnérabilités connues, de sa dangerosité et de la manière de la résoudre.
Regardez à la demande pour découvrir comment donner aux responsables AppSec les moyens de devenir des facilitateurs de l'IA, plutôt que des bloqueurs, grâce à une approche pratique axée sur la formation. Nous allons vous montrer comment tirer parti de Secure Code Warrior (SCW) pour mettre à jour stratégiquement votre stratégie AppSec à l'ère des assistants de codage basés sur l'IA.
.avif)