Prenez des mesures au cours du développement pour renforcer et sécuriser votre backend web.

Les petites entreprises, les banques et de nombreux secteurs d’activité dépendent des applications web. Dès la conception d’une application web, il est essentiel de s’assurer que des protocoles permettent de vérifier les vulnérabilités au fur et à mesure de l’évolution du développement, afin d’é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 du côté du 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 le côté client, c’est la partie avec laquelle l’utilisateur interagit. Il est généralement construit avec du HTML, du CSS et du Javascript.
  • Le backend est la partie serveur. C’est essentiellement la façon dont l’application fonctionne, applique la logique commerciale, les changements et les mises à jour. Certaines des piles technologiques côté serveur les plus populaires 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 du contenu.

Un petit rappel avant de commencer – authentification, contrôle d’accès et gestion des sessions

Il est fréquent de confondre les termes. Nous allons donc les clarifier rapidement :

  • L’authentification consiste à prouver 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 l’accès de l’utilisateur à l’application. Il permet d’appliquer la politique selon laquelle les utilisateurs ne peuvent pas agir en dehors des autorisations qui leur sont accordées.
  • La gestion des sessions concerne les réponses et les transactions de demande associées au même utilisateur. Il s’agit d’un mécanisme d’échange utilisé entre l’utilisateur et l’application après une authentification réussie.

Explorons les points suivants pour améliorer la sécurité des sites web back-end.

Défauts d’injection

Depuis 2010, l’OSWAP a classé l’injection comme le premier risque le plus dangereux pour les applications web.

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 maintenant manipuler le champ du mot de passe en utilisant l'

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 d’utilisateurs de la base de données, le mot de passe étant toujours valide (1 = ‘1’). S’il se connecte en tant qu’administrateur, il peut effectuer toutes les modifications qu’il souhaite.

Comment l’empêcher ?

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

La meilleure façon de vérifier qu’il n’y a pas de failles d’injection est de procéder à un examen manuel approfondi du code source afin de vérifier si les requêtes dans la base de données sont effectuées au moyen d’instructions préparées. Vous pouvez également utiliser des outils pour vérifier les vulnérabilités.

Et vous devriez également faire ce qui suit.

  • Utilisez des outils ORM (Object Relational Mapping Tools).
  • Échapper à toutes les entrées. Un champ de date ne doit jamais contenir autre chose que des dates.
  • Isolez vos données de manière à ce que seules les données accessibles à partir d’un emplacement donné soient conservées à cet emplacement.
  • Écrivez de bons codes d’erreur. Ne rendez pas votre base de données ou votre backend trop verbeux.

Troy Hunt a donné un cours brillant sur l’injection SQL. Si vous êtes intéressé, vous pouvez l’explorer.

Authentification défectueuse

Comme nous l’avons déjà mentionné, l’authentification concerne la fourniture des informations d’identification. C’est la première ligne de défense contre l’accès illimité. Cependant, une mauvaise mise en œuvre et le non-respect de la politique de sécurité peuvent conduire à une authentification défaillante.

L’authentification brisée se produit principalement selon trois schémas :

  • Le bourrage d’identifiants : l’attaquant dispose d’une liste de noms d’utilisateur et de mots de passe valides et peut automatiser l’attaque pour s’assurer que les identifiants sont valides.
  • Attaque par la force : lorsque l’application autorise des mots de passe faibles pour les utilisateurs ou les administrateurs.
  • Détournement de session : lorsque l’application expose l’identifiant de session, l’URL, ou n’effectue pas de rotation après la connexion.

Dans tous les cas, le pirate peut accéder à un compte important et dépendre de l’entreprise, ce qui peut entraîner le blanchiment d’argent, l’usurpation d’identité ou la divulgation d’informations hautement sensibles et protégées par la loi.

Comment s’en prémunir ?

Avant de mettre en place le système d’authentification, posez-vous la question suivante : que pourrait faire un pirate si le système d’authentification était compromis ?

En fonction de la réponse, vous pouvez prendre les mesures suivantes.

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

Contrôle d’accès défaillant

Le contrôle d’accès vise à garantir ce que l’utilisateur authentifié est autorisé à faire. L’authentification et la gestion des sessions sont les fondements 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 les plus courantes du contrôle d’accès sont les suivantes

  • Une mauvaise configuration de CORS qui permet un accès non autorisé à l’API.
  • Manipulation des métadonnées permettant d’accéder directement aux méthodes.
  • Navigation forcée : L’attaquant essaiera une URL, modifiera les chemins (par exemple, de http://website.domain/user/ à http://website.domain/admin) et pourra même découvrir des fichiers importants.

Comment s’en prémunir ?

La plupart du temps, les failles d’accès sont dues à l’ignorance des exigences essentielles d’une gestion efficace des accès.

  • Refusez l’accès par défaut, à l’exception des 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é du 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.

Elle se produit lorsque l’application ne protège pas correctement les informations telles que les identifiants ou les données sensibles comme les cartes de crédit ou les dossiers médicaux. Plus de 4 000 dossiers sont violés chaque minute.

L’impact sur les entreprises est important du point de vue financier : Selon IBM, une violation moyenne peut coûter 3,92 millions de dollars.

Comment s’en prémunir ?

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

Et ensuite, prévenir de telles failles :

  • Cryptez les données sensibles : Pour les données au niveau de REST, cryptez tout. Pour les données en transit, assurez-vous d’utiliser des passerelles sécurisées ( SSL )
  • Identifiez les données qui nécessitent une protection supplémentaire et limitez l’accès à un groupe d’utilisateurs légitimes en appliquant un cryptage basé sur des clés.
  • Évitez les algorithmes de cryptage faibles : utilisez des algorithmes récents et solides.
  • Disposez d’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 en format objet pour être stockées ou envoyées à une autre application. La sérialisation consiste à convertir des données en format objet comme XML ou JSON pour les rendre utilisables. La désérialisation est le processus inverse.

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

Le deuxième exemple du top 10 de l’OWASP illustre bien le 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’identifiant de l’utilisateur, le niveau de l’utilisateur et le mot de passe haché.

Un attaquant peut modifier l’objet sérialisé pour obtenir des 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 s’en prémunir ?

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

Vous devez également

  • Ne jamais faire confiance aux entrées des utilisateurs.
  • Valider les données : Si votre application n’utilise qu’une chaîne de caractères, assurez-vous qu’il s’agit bien d’une chaîne de caractères avant de l’utiliser
  • Utilisez une vérification pour vous assurer que les données n’ont pas été modifiées. C’est utile lorsque vous envoyez des données entre deux sources de confiance (par exemple, lorsque vous stockez des données côté client).

Serveur XSS

LeXSS serveur (Cross-site scripting) est un type d’injection lorsqu’un pirate utilise une application web pour envoyer un code malveillant à différents utilisateurs. Cela se produit lorsque l’attaquant publie des données élaborées contenant du code malveillant que l’application stocke. Cette vulnérabilité se situe du côté du serveur ; le navigateur se contente de rendre 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 en profitent pour ajouter des messages contenant des scripts malveillants. Par la suite, d’autres utilisateurs reçoivent ce lien par courrier électronique ou voient le message en question et cliquent dessus.

Comment éviter cela ?

Après l’identification primaire de toutes les opérations potentiellement exposées au risque de XSS et devant être protégées, vous devez envisager les mesures suivantes.

  • Validez l’entrée : vérifiez la longueur de l’entrée, utilisez des expressions rationnelles et n’autorisez qu’un certain nombre de caractères.
  • Validez 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 afin d’assainir les caractères potentiellement malveillants.
  • Limiter le 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 approprié pour les balises HTML fournies par l’utilisateur afin de vous assurer qu’elles ne contiennent aucun moyen d’exécuter du JavaScript.

Conclusion

La phase de développement est cruciale pour la sécurité des applications web. Vous devriez envisager d’inclure un scanner de vulnérabilités de sécurité dans le cycle de vie du développement, afin que les problèmes identifiés soient corrigés avant la mise en production.