• Assurez la sécurité des applications de la bonne manière! Détectez, protégez, surveillez, accélérez et plus encore…
  • Prenez des mesures en cours de développement pour renforcer et sécuriser votre backend Web.

    Les petites entreprises, les banques et de nombreux secteurs dépendent des applications Web. Dès le moment de la création d'une application Web, il est essentiel de s'assurer d'avoir des protocoles pour vérifier les vulnérabilités au fur et à mesure que le développement évolue pour éviter les failles de sécurité, les fuites de données et les problèmes financiers.

    Les attaques Web les plus dangereuses sont celles qui se produisent côté serveur où les données sont stockées et analysées.

    Qu'est-ce que le backend?

    Une application Web est divisée en deux parties: Frontend et Backend.

    • Le frontend est côté client, c'est la partie avec laquelle l'utilisateur interagit. En règle générale, il est construit avec HTML, CSS et Javascript.
    • Le backend est côté serveur. Il s'agit essentiellement de la façon dont l'application fonctionne, applique la logique métier, les modifications et les mises à jour. Certaines des piles technologiques populaires côté serveur impliquent PHP, NodeJS, Java, Ruby, C, Python, la base de données, la sécurité (authentification, contrôle d'accès, etc.), la structure et la gestion de contenu.

    Un petit rappel avant de commencer - authentification, contrôle d'accès et gestion de session

    Il est courant pour nous de confondre les termes. Alors clarifions-le rapidement:

    • L'authentification concerne la preuve de l'identité de l'utilisateur (par exemple, mot de passe, nom d'utilisateur, questions de sécurité, empreintes digitales)
    • Le contrôle d'accès concerne ce que l'utilisateur peut accéder à l'application. Il applique la politique selon laquelle les utilisateurs ne peuvent pas agir en dehors de leurs autorisations prévues.
    • La gestion de session concerne les réponses et les transactions de demande associées au même utilisateur. C'est un mécanisme d'échange qui est utilisé entre l'utilisateur et l'application après s'être authentifié avec succès.

    Explorons ce qui suit pour une meilleure sécurité Web back-end.

    Défauts d'injection

    Depuis 2010, OSWAP a classé l'injection comme le risque d'application Web le plus dangereux.

    Les failles d'injection permettent à un utilisateur de fournir des données contenant des mots-clés qui modifieront le comportement des requêtes construites sur la base de données. Par exemple, supposons que nous ayons un script SQL qui vérifie si une entrée correspondante existe dans la base de données.

    uname = request.POST['username']
    passwd = request.POST['password']
    sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'" 
    database.execute(sql)

    Un attaquant peut désormais manipuler le champ du mot de passe en utilisant Injection SQL, par exemple en saisissant le mot de passe 'OR 1 =' 1, ce qui conduit à la requête SQL suivante:

    sql = "SELECT id FROM users WHERE username='' AND password='password' OR 1='1'

    Ce faisant, l'attaquant peut accéder à toutes les tables utilisateur de la base de données, le mot de passe étant toujours valide (1 = '1'). S'ils se connectent en tant qu'administrateur, ils peuvent apporter les modifications souhaitées.

    Comment l'empêcher?

    Il est très FACILE pour éviter les défauts d'injection.

    Le meilleur et simple moyen de vérifier s'il n'y a pas de défauts d'injection est une revue manuelle approfondie du code source pour vérifier si les requêtes dans la base de données sont effectuées via des instructions préparées. Vous pouvez également utiliser des outils pour vérifier vulnérabilités.

    Et vous devez également faire ce qui suit.

    • Utilisez les ORM (Object Relational Mapping Tools).
    • Échappez à toutes les entrées. Un champ de date ne doit jamais contenir autre chose que des dates.
    • Isolez vos données afin que seules les choses auxquelles vous devez accéder à partir d'un emplacement donné soient conservées à cet emplacement.
    • Écrivez de bons codes d'erreur de manipulation. Ne rendez pas votre base de données ou votre backend trop verbeux.

    Chasse à la Troie a obtenu un cours brillant sur l'injection SQL. Si vous êtes intéressé, vous pouvez explorer cela.

    Authentification cassée

    Comme mentionné précédemment, l'authentification concerne les informations d'identification fournies. C'est la ligne de front de la défense contre un accès illimité. Cependant, une mauvaise mise en œuvre et le non-respect de la politique de sécurité peuvent conduire à une authentification interrompue.

    L'authentification interrompue se produit principalement par trois modèles:

    • Remplissage des informations d'identification: où l'attaquant a une liste de noms d'utilisateur et de mots de passe valides et peut automatiser l'attaque pour déterminer que les informations d'identification sont valides.
    • Attaque Bruteforce: où l'application autorise les mots de passe faibles pour les utilisateurs ou les administrateurs.
    • Détournement de session: où l'application expose l'ID de session, l'URL ou ne tourne pas après la connexion.

    Dans tous les cas, l'attaquant peut accéder à un compte important et dépendre de l'entreprise qui peut provoquer le blanchiment d'argent, le vol d'identité ou divulguer des informations hautement sensibles protégées par la loi.

    Comment l'empêcher?

    Avant de mettre en œuvre le système d'authentification, posez-vous la question suivante: que pourrait faire un attaquant si le système d'authentification est compromis?

    Et selon la réponse, vous pouvez faire ce qui suit.

    • Mettez en œuvre une authentification multifacteur pour empêcher les attaques automatisées.
    • Encouragez (ou forcez) l'utilisateur à adopter une bonne politique de mot de passe.
    • Limitez les échecs de connexion.
    • Utilisez un hachage d'algorithme efficace. Lors du choix d'un algorithme, tenez compte de la longueur maximale du mot de passe.
    • Testez le système de délai d'expiration de session et assurez-vous que le jeton de session est invalidé après la déconnexion.

    Contrôle d'accès cassé

    Le contrôle d'accès existe pour garantir ce que l'utilisateur authentifié est autorisé à faire. L'authentification et la gestion de session sont la base des règles de contrôle d'accès. Mais lorsque ces règles ne sont pas bien définies, cela peut entraîner des problèmes importants.

    Les failles courantes de contrôle d'accès incluent:

    • Mauvaise configuration CORS qui autorise l'accès non autorisé à l'API.
    • Manipulation des métadonnées pour accéder directement aux méthodes.
    • Navigation forcée: l'attaquant essaiera une URL, modifiera les chemins (par exemple, http: //website.domain/user/ vers http: //website.domain/admin), et peut même découvrir des fichiers importants.

    Comment l'empêcher?

    La plupart du temps, les failles d'accès brisées résultent de l'ignorance des exigences essentielles d'une gestion efficace des accès.

    • Refuser par défaut sauf les ressources publiques.
    • Désactivez la liste des répertoires du serveur et assurez-vous que les fichiers de sauvegarde ne sont pas présents.
    • Limitez le taux d'accès à l'API pour réduire l'impact des attaques automatisées.
    • Invalidez les jetons JWT après la déconnexion du côté backend.

    Exposition des données

    Également appelée violation de données, l'exposition des données est une cyber-menace qui menace les entreprises et leurs clients.

    Cela se produit lorsque l'application ne protège pas correctement les informations telles que les informations d'identification ou les données sensibles telles que les cartes de crédit ou les dossiers médicaux. Plus de 4000 enregistrements sont violé chaque minute.

    L'impact sur les entreprises est important du point de vue financier: une violation moyenne peut coûter 3.92 millions USD, selon IBM.

    Comment l'empêcher?

    En tant que développeur backend, vous devez demander quelles sont les informations qui doivent être protégées.

    Et puis pour éviter de tels défauts:

    • Crypter les données sensibles: pour les données REST, cryptez tout. Pour les données en transit, veillez à utiliser des passerelles sécurisées ( SSL )
    • Identifiez les données qui nécessitent une protection supplémentaire et limitez l'accessibilité à un groupe d'utilisateurs légitimes uniquement en appliquant un cryptage basé sur des clés.
    • Évitez les algorithmes de chiffrement faibles: utilisez des algorithmes puissants.
    • Ayez un plan de sauvegarde sécurisé.

    Désérialisation non sécurisée

    La sérialisation et la désérialisation sont des concepts utilisés lorsque des données sont converties au format objet pour être stockées ou envoyées à une autre application. La sérialisation consiste à convertir les données au format objet comme XML ou JSON pour les rendre utilisables. La désérialisation n'est que le processus inverse.

    Les attaques contre les désérialiseurs peuvent conduire à des attaques de déni de service, de contrôle d'accès et d'exécution de code à distance (RCE) s'il existe des classes qui peuvent être modifiées pour changer de comportement.

    Le deuxième exemple du document OWASP top 10 fournit une bonne illustration du sérialiseur d'objets PHP:

    a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
    i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

    Il s'agit d'un supercookie contenant des informations telles que l'ID utilisateur, le niveau de l'utilisateur et le mot de passe haché.

    Un attaquant peut modifier l'objet sérialisé pour avoir accès aux privilèges d'administrateur:

    a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
    i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

    Comment l'empêcher?

    Il est essentiel de ne pas accepter d'objets sérialisés provenant de sources non fiables.

    Tu devrais aussi:

    • Ne faites jamais confiance à l'entrée de l'utilisateur.
    • Valider les données: si votre application est à l'exception d'une chaîne, assurez-vous qu'il s'agit d'une chaîne avant de l'utiliser
    • Utilisez une vérification pour vous assurer que les données n'ont pas été modifiées. Il est utile que vous envoyiez des données entre deux sources de confiance (par exemple, en stockant des données côté client).

    Serveur XSS

    Serveur XSS (Cross-site scripting) est un type d'injection lorsqu'un attaquant utilise une application Web pour envoyer du code malveillant à différents utilisateurs. Cela se produit lorsque l'attaquant publie des données spécialement conçues contenant du code malveillant stocké par l'application. Cette vulnérabilité est côté serveur; le navigateur rend simplement la réponse.

    Par exemple, dans un forum, les messages des utilisateurs sont enregistrés dans une base de données, souvent sans vérification. Les attaquants profitent de cette occasion pour ajouter des articles contenant des scripts malveillants. Par la suite, d'autres utilisateurs reçoivent ce lien par e-mail ou voient le message en question et cliquent dessus.

    Comment l'empêcher?

    Après l'identification primaire de toutes les opérations qui sont potentiellement à risque de XSS et qui doivent être protégées, vous devez tenir compte des éléments suivants.

    • Valider l'entrée: vérifiez la longueur de l'entrée, utilisez la correspondance regex et n'autorise qu'un certain jeu de caractères.
    • Valider la sortie: si l'application copie dans ses réponses à un élément de données provenant d'un utilisateur ou d'un tiers, ces données doivent être codées en HTML pour nettoyer les caractères potentiellement malveillants.
    • Autoriser la limite HTML: par exemple, si vous avez un système de blog de commentaires, n'autorisez que l'utilisation de certaines balises. Si vous le pouvez, utilisez un cadre adapté au balisage HTML fourni par l'utilisateur pour essayer de vous assurer qu'il ne contient aucun moyen d'exécuter JavaScript.

    Conclusion

    La phase de développement est cruciale pour la sécurité des applications Web. Et, vous devriez envisager d'inclure un scanner de vulnérabilités de sécurité dans le cycle de vie du développement, de sorte que les problèmes identifiés sont résolus avant la production.