Dans la plupart des cas, les serveurs d'applications Web doivent être accessibles au public, ce qui signifie qu'ils sont exposés à toutes sortes de menaces.
Beaucoup de ces menaces sont prévisibles et facilement évitables, tandis que d'autres sont inconnues et peuvent vous surprendre. Pour minimiser la possibilité de ce dernier cas, nous proposons une liste de conseils essentiels pour assurer la sécurité des serveurs d'applications Web.
Avant de commencer avec la liste des astuces, vous devez comprendre qu'un serveur d'applications Web n'est pas un îlot. Le serveur est le composant central de la batterie d'applications Web qui rend possible l'hébergement et l'exploitation d'une application Web. Par conséquent, pour sécuriser, vous devez prendre en compte tous les composants qui l'entourent et sécuriser l'ensemble de l'environnement de l'application Web.
Un environnement de base pour l'hébergement et l'exécution d'applications Web comprend le système d'exploitation (Linux, Windows), le logiciel du serveur Web (Apache, Nginx), un serveur de base de données. Si l'un de ces composants est cambriolé, les attaquants pourraient y accéder et exécuter tous les actions malveillantes ils veulent.
Un premier conseil de base pour sécuriser un environnement tel que celui décrit ci-dessus est de lire les consignes de sécurité et la liste des meilleures pratiques pour chacun des composants. Cela étant dit, passons en revue un certain nombre de consignes de sécurité de bon sens qui s'appliquent à presque tous les environnements d'applications Web.
The firewall demystified
Vous serez peut-être tenté de vérifier rapidement cet élément, en pensant: "Heureusement, j'ai déjà un pare-feu protégeant mon réseau." Mais tu ferais mieux de tenir tes chevaux.
Votre pare-feu peut-être prendre soin des frontières de votre réseau, empêcher les méchants d'entrer et les gentils, mais c'est sûr que cela laisse une porte grande ouverte pour que les attaquants pénètrent dans votre serveur d'applications Web.
Comment s’y prendre?
Simple: votre pare-feu réseau doit au moins autoriser le trafic entrant sur les ports 80 et 443 (c'est-à-dire HTTP et HTTPS), et ne sait pas qui ou quoi passe par ces ports.
Ce dont vous avez besoin pour protéger votre application est un Firewall d'applications Web (WAF) qui analyse spécifiquement le trafic Web et bloque toute tentative d'exploitation de vulnérabilités telles que les scripts intersites ou l'injection de code. Un WAF fonctionne comme un antivirus et un antimalware typiques: il recherche les modèles connus dans le flux de données et le bloque lorsqu'il détecte une requête malveillante.
Pour être efficace, le WAF doit avoir sa base de données constamment mise à jour avec de nouveaux modèles de menaces, afin de pouvoir les bloquer. Le problème avec la prévention des attaques basée sur des modèles est que votre application Web peut être l'une des premières cibles d'une nouvelle menace dont votre WAF n'a pas encore connaissance.
Pour ces raisons, votre application Web a besoin de couches de protection supplémentaires en plus du pare-feu réseau.
Scan for web-specific vulnerabilities
Encore une fois, ne pensez pas que votre serveur d'applications Web est exempt de vulnérabilité simplement parce que votre scanner de sécurité réseau le dit.
Les scanners réseau ne peuvent pas détecter les vulnérabilités spécifiques aux applications. Pour détecter et éliminer ces vulnérabilités, vous devez soumettre les applications à une série de tests et d'audits, tels que des tests de pénétration, l'analyse des boîtes noires et l'audit du code source. Aucune de ces méthodes n'est cependant à l'épreuve des balles. Idéalement, vous devriez en effectuer autant que possible pour éliminer toutes les vulnérabilités.
Par exemple, les scanners de sécurité, comme invicti, assurez-vous qu'aucun code exploitable ne parvient dans l'environnement de production. Mais il peut y avoir des vulnérabilités logiques qui ne peuvent être détectées que par un audit de code manuel. L'audit manuel, en plus de coûter cher, est une méthode humaine et donc sujette aux erreurs. Une bonne idée de faire ce type d'audit sans gaspiller beaucoup d'argent est de l'intégrer dans le processus de développement, principalement en éduquant vos développeurs.
Educate your developers
Les développeurs ont tendance à penser que leurs applications fonctionnent dans des mondes idéaux, où les ressources sont illimitées, les utilisateurs ne font pas d'erreurs et il n'y a pas de personnes aux intentions impitoyables. Malheureusement, à un moment donné, ils doivent faire face à des problèmes du monde réel, en particulier ceux concernant la sécurité de l'information.
Lors du développement d'applications Web, les codeurs doivent connaître et mettre en œuvre des mécanismes de sécurité pour s'assurer qu'il est exempt de vulnérabilités. Ces mécanismes de sécurité doivent faire partie du guide des meilleures pratiques que l'équipe de développement doit respecter.
Audit de la qualité des logiciels est utilisé pour garantir le respect des meilleures pratiques. Les meilleures pratiques et l'audit sont les seuls moyens de détecter les vulnérabilités logiques, telles que (par exemple) le passage de paramètres non chiffrés et visibles à l'intérieur d'une URL, qu'un attaquant pourrait facilement modifier pour faire ce qu'il veut.
Turn off unnecessary functionality
En supposant que les applications Web sont aussi exemptes d'erreurs que possible et que la ferme Web est sécurisée, voyons ce qui peut être fait sur le serveur lui-même pour le protéger des attaques.
Une astuce de base et de bon sens consiste à réduire le nombre de points d'entrée potentiellement vulnérables. Si des attaquants peuvent exploiter l'un des composants du serveur Web, l'ensemble du serveur Web pourrait être en danger.
Faites une liste de tous les ports ouverts et des services ou démons en cours d'exécution sur votre serveur et fermez, désactivez ou éteignez ceux qui ne sont pas nécessaires. Le serveur ne doit pas être utilisé à d'autres fins que l'exécution de vos applications Web. Pensez donc à déplacer toutes les fonctionnalités supplémentaires vers d'autres serveurs de votre réseau.
Use separate environments for development, testing, and production
Les développeurs et les testeurs ont besoin de privilèges sur les environnements sur lesquels ils travaillent et qu'ils ne devraient pas avoir sur le serveur d'applications en direct. Même si vous leur faites confiance aveuglément, leurs mots de passe pourraient facilement fuir et tomber entre des mains indésirables.
Outre les mots de passe et les privilèges, dans les environnements de développement et de test, il existe généralement des portes dérobées, des fichiers journaux, du code source ou d'autres informations de débogage qui pourraient exposer des données sensibles, telles que les noms d'utilisateur et les mots de passe de la base de données. Le processus de déploiement de l'application Web doit être effectué par un administrateur, qui doit s'assurer qu'aucune information sensible n'est exposée après l'installation de l'application sur le serveur actif.
Le même concept de ségrégation doit être appliqué aux données de l'application. Les testeurs et les développeurs préfèrent toujours travailler avec des données réelles, mais ce n'est pas une bonne idée de leur donner accès à la base de données de production, ni même à une copie de celle-ci. Outre des problèmes de confidentialité évidents, la base de données peut contenir des paramètres de configuration qui révèlent les paramètres internes du serveur, tels que les adresses des points de terminaison ou les chemins, pour n'en nommer que quelques-uns.
Keep your server software updated
Aussi évident que cela puisse paraître, c'est l'une des tâches les plus négligées. SUCURI a constaté que 59% des applications CMS étaient obsolètes, ce qui est risqué.
De nouvelles menaces apparaissent chaque jour, et le seul moyen de les empêcher de mettre en péril votre serveur est de toujours installer les derniers correctifs de sécurité.
Nous avons mentionné précédemment que les pare-feu réseau et les scanners de sécurité réseau ne sont pas suffisants pour empêcher les attaques sur les applications Web. Mais ils sont nécessaires pour protéger votre serveur contre les menaces de cybersécurité courantes, comme Les attaques DDoS. Assurez-vous donc que ces applications sont toujours mises à jour et qu'elles protègent efficacement votre application métier.
Restrict access and privileges
Une mesure de sécurité de base consiste à maintenir le trafic d'accès distant - tel que RDP et SSH - chiffré et tunnelisé. Il est également judicieux de conserver une liste réduite d'adresses IP à partir desquelles l'accès à distance est autorisé, en vous assurant que toute tentative de connexion à distance à partir de toute autre adresse IP est bloquée.
Les administrateurs accordent parfois aux comptes de service tous les privilèges possibles, car ils savent que, ce faisant, «tout fonctionnera». Mais ce n'est pas une bonne pratique car les attaquants peuvent utiliser des vulnérabilités dans les services pour pénétrer le serveur. Si ces services fonctionnent avec des privilèges d'administrateur, ils peuvent saisir l'ensemble du serveur.
Un bon équilibre entre sécurité et praticité nécessite que chaque compte - à la fois les comptes de connexion et les comptes de service - dispose des privilèges nécessaires pour effectuer son travail, et rien d'autre.
Par exemple, vous pouvez définir différents comptes pour qu'un administrateur effectue différentes tâches: un pour effectuer des sauvegardes, un autre pour nettoyer les fichiers journaux, d'autres pour modifier la configuration des services, etc. Il en va de même pour les comptes de base de données: une application n'a généralement besoin que des autorisations pour lire et écrire des données, et non pour créer ou supprimer des tables. Par conséquent, il doit fonctionner avec un compte avec des privilèges limités pour effectuer les tâches dont il a besoin.
Keep an eye on server logs
Les fichiers journaux sont là pour une raison.
Les administrateurs doivent les surveiller régulièrement pour détecter tout comportement suspect avant qu'il ne cause des dommages. Par analyse des fichiers journaux, vous pouvez découvrir de nombreuses informations pour vous aider à mieux protéger l'application. Si une attaque devait se produire, les fichiers journaux pourraient vous montrer quand et comment elle a commencé, contribuant ainsi à mieux contrôler les dégâts.
Vous devez également disposer d'une procédure automatisée pour supprimer les anciens fichiers journaux ou pour élaguer les informations obsolètes, afin de les empêcher de consommer tout l'espace de stockage disponible sur le serveur.
Conseil bonus: tenez-vous informé
Il existe de nombreuses informations gratuites et utiles sur Internet que vous pouvez utiliser au profit de votre application Web. Ne manquez aucun nouvel article sur des blogs de sécurité réputés (comme celui-ci) et restez informé de ce qui se passe dans l'industrie de la sécurité et du Web.
Tutoriels, cours, les vidéos et les livres sont également des sources de connaissances utiles. Entraînez-vous à passer une ou deux heures par semaine juste pour rester informé des nouvelles de l'industrie - Cela vous donnera la tranquillité d'esprit de savoir que vous faites ce qu'il faut pour protéger vos applications.
