6 risques de sécurité des backends Web à prendre en compte lors du développement

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 sont mis en place pour 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 le côté serveur. C'est essentiellement la façon dont l'application fonctionne, applique la logique commerciale, les changements et les mises à jour. Parmi les technologies côté serveur les plus répandues, citons 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 de session

Il est fréquent que nous confondions les termes. Clarifions donc les choses 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 de session 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.

Examinons 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 risque #1 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 pirate peut désormais manipuler le champ du mot de passe en utilisant la fonction Injection SQLpar 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'éviter ?

C'est très FACILE pour é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 à l'aide d'instructions préparées. Vous pouvez également utiliser des outils pour vérifier vulnérabilités.

Vous devez également faire ce qui suit.

• Utiliser des ORMs (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 qui doivent être accessibles à partir d'un endroit donné soient conservées à cet endroit.
• Écrivez des codes d'erreur bien gérés. Ne rendez pas votre base de données ou votre backend trop verbeux.

Troy Hunt a suivi un excellent cours sur l'injection SQL. Si cela vous intéresse, vous pouvez l'explorer.

Authentification interrompue

Comme nous l'avons déjà mentionné, l'authentification concerne la fourniture d'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.

Les ruptures d'authentification se produisent principalement selon trois schémas :

• Remplissage de lettres de créance : où 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 informations d'identification 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 légalement protégées et très sensibles.

Comment l'éviter ?

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 ?

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

• Mettre en œuvre l'authentification multifactorielle pour prévenir les attaques automatisées.
• Encourager (ou forcer) l'utilisateur à adopter une bonne politique en matière de mots de passe.
• Limiter les échecs de connexion.
• Utiliser un algorithme de hachage efficace. Lorsque vous choisissez 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 dans le contrôle d'accès sont les suivantes :

• Mauvaise configuration CORS permettant un accès non autorisé à l'API.
• Manipulation des métadonnées pour un accès direct 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 peut même découvrir des fichiers importants.

Comment l'éviter ?

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

• Refus par défaut, sauf pour 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.
• Limiter l'accès à l'API pour réduire l'impact des attaques automatisées.
• Invalider les jetons JWT après la déconnexion du côté du backend.

Exposition aux 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.

Il se produit lorsque l'application ne protège pas de manière adéquate les informations telles que les identifiants ou les données sensibles comme les cartes de crédit ou les dossiers médicaux. Plus de 4000 dossiers sont Chaque minute, une brèche est ouverte.

L'impact sur les entreprises est important du point de vue financier : Une violation moyenne peut coûter 3,92 millions de dollars, selon l'étude IBM.

Comment l'éviter ?

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

Et ensuite de prévenir de telles failles :

• Chiffrer 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 uniquement en appliquant un cryptage basé sur des clés.
• Évitez les algorithmes de chiffrement faibles : utilisez des algorithmes de chiffrement récents et efficaces. des algorithmes puissants.
• Disposer 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 les 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 document top 10 de l'OWASP 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'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 l'éviter ?

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

Vous devriez aussi :

• Ne vous fiez jamais aux données fournies par l'utilisateur.
• Validez les données : Si votre application ne demande 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 fiables (par exemple, lorsque vous stockez des données côté client).

Serveur XSS

Serveur XSS (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 un 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 profitent de cette occasion pour ajouter des messages avec 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 l'éviter ?

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 prendre en compte les éléments suivants.

• Valider l'entrée : vérifier la longueur de l'entrée, utiliser des expressions rationnelles et n'autoriser qu'un certain nombre 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 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 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 résolus avant la production.