1) Modifier les ports par défaut
La majorité des serveurs web fonctionnent sur les ports 80 et 443. Si votre application PHP est exposée sur l’un de ces ports, vous devez les changer dès que possible en quelque chose comme : 1141 (443) et 1142 (80). Il y a plusieurs raisons de changer ces ports. Premièrement, il est beaucoup plus difficile pour un intrus d’y accéder, car la plupart des gens supposent que ces deux numéros ont déjà été utilisés. Deuxièmement, cela évite les conflits avec d’autres services fonctionnant sur ces ports. Enfin, certains fournisseurs d’accès peuvent bloquer les ports 80/443 s’ils ne sont pas déjà utilisés, mais pratiquement tous les fournisseurs d’accès autorisent le trafic sur les ports 1143 ou plus sans restriction. Le fait de changer vos ports par défaut ne signifie pas que vous ne devez pas mettre en place de mesures de sécurité ; elles doivent toujours être mises en œuvre, mais sur des canaux HTTP/HTTPS non standard.
2) Utilisez HTTPS à tout moment
De nombreux sites Web n’utilisent pas le protocole HTTPS, alors qu’ils devraient le faire. Il est important que votre site web soit sécurisé à tout moment en vous assurant que vous utilisez HTTPS au lieu de HTTP. Cela permettra de protéger vos données et vos informations personnelles en les cryptant afin qu’elles ne puissent pas être lues par d’autres personnes via une connexion non sécurisée. Le protocole HTTPS est particulièrement important pour les sites qui traitent des données sensibles, comme les numéros de carte de crédit ou les informations médicales ; si quelqu’un intercepte votre trafic, vos données peuvent facilement être compromises.
3) Utilisez des mots de passe forts
Il n’y a aucune raison de ne pas utiliser des mots de passe forts qui contiennent un mélange de chiffres, de lettres et de caractères spéciaux. Un bon mot de passe doit être long (idéalement plus de 12 caractères) et contenir au moins un chiffre et un symbole. Et n’oubliez pas : De nos jours, il est souvent plus sûr d’utiliser deux mots de passe différents que d’utiliser une phrase de passe. Veillez à utiliser des mots de passe différents pour vos différentes connexions. Si quelqu’un découvre vos informations de connexion pour un site, il peut facilement compromettre toute votre vie numérique en quelques clics. Pensez aux gestionnaires de mots de passe comme LastPass et KeyPass, qui vous permettent de stocker tous vos mots de passe dans une base de données chiffrée qui se synchronise sur tous vos appareils.
4) Désactiver l’exécution de code à distance
Si l’exécution de code à distance est activée, les attaquants peuvent exécuter du code arbitraire sur votre serveur. Cette fonction doit être désactivée à tout moment. En raison de ses conséquences potentielles, l’exécution de code à distance doit être l’une de vos principales priorités lorsque vous sécurisez une application Web. Assurez-vous que vous avez correctement configuré les paramètres pour la désactiver. Désactivez-la pour tous les fichiers Si possible, ne la désactivez pas uniquement pour les fichiers .php, mais pour tous les types de fichiers, afin que les attaquants ne puissent pas utiliser d’autres types de fichiers comme portes dérobées sur votre site. En prime, la désactivation de l’exécution de code à distance réduira votre exposition aux téléchargements à distance et à d’autres types de scripts malveillants chargés à partir de sources non fiables sur votre site Web. Évaluez les plugins tiers Les plugins tiers sont connus pour être truffés de failles de sécurité, car ils ne sont pas soumis aux mesures habituelles de contrôle de la qualité. Par conséquent, si vous ne développez pas vous-même des fonctionnalités personnalisées, les plugins tiers sont très susceptibles de contenir des erreurs qui pourraient causer des problèmes de sécurité sur votre site. Envisagez d’utiliser uniquement des modules de haute qualité ayant des antécédents de maintien d’un code sécurisé ou un code propriétaire développé en interne par des développeurs expérimentés ayant un haut niveau d’expertise en matière de sécurité des applications Web. Vérifiez les options de configuration du serveur Web Bien qu’elles ne soient pas nécessairement liées directement aux vulnérabilités de PHP, certaines options de configuration d’Apache constituent de bonnes pratiques générales en termes de sécurité, car elles limitent ce que les différents processus exécutés sur votre système sont autorisés ou non à faire.
5) Activez ModSecurity ou un autre WAF
Même si vous n’êtes pas un développeur d’applications Web, l’une de vos principales responsabilités en tant que professionnel de la sécurité de l’information est d’aider les développeurs à mettre en œuvre des pratiques de codage sécurisées. C’est pourquoi il est si important que vous vous familiarisiez avec les WAF, ou pare-feu d’applications Web, et que vous appreniez à les activer pour votre organisation. Même un petit peu de connaissance peut contribuer à rendre votre organisation plus sûre. Par exemple, en activant ModSecurity sur tous vos serveurs Web (et vos équilibreurs de charge Apache), vous augmentez considérablement la sécurité – et la tranquillité d’esprit – de toutes les personnes concernées.
6) S’appuyer sur les fonctions de sécurité intégrées
De safe_mode à open_basedir, il existe de nombreuses façons d’améliorer la sécurité de votre site en tirant parti des fonctionnalités intégrées. Par exemple, si vous créez une nouvelle fonction de téléchargement de fichiers, utilisez validate_file_name() plutôt que de le faire vous-même. En cas de doute, voyez ce que fait WordPress ou un autre framework populaire. Si leur code ne présente pas de vulnérabilité évidente, le vôtre n’en présentera probablement pas non plus. Ne réinventez pas ce qui a déjà été écrit. Utilisez les fonctions intégrées : Il y a tellement de fonctions disponibles pour chaque langage ! Assurez-vous de les apprendre et de les utiliser ! Gagnez du temps en essayant d’écrire quelque chose de compliqué alors que quelqu’un l’a déjà résolu pour vous.
7) Ne pas exécuter les outils d’administration sur les serveurs de production
Bien sûr, l’utilisation de certains outils d’administration peut être pratique sur votre serveur de développement, mais elle ne peut que vous attirer des ennuis si vous les utilisez sur un serveur de production. Des outils comme phpMyAdmin et Adminer offrent aux pirates potentiels une voie d’attaque qui, avec suffisamment de connaissances et de persistance, peut mener directement à votre base de données. Ne le faites pas. Si vous avez besoin d’un accès distant à votre base de données à des fins de développement ou de débogage, utilisez plutôt un tunnel SSH. Pour les utilisateurs de MySQL qui souhaitent un accès à l’interface graphique, consultez les offres de la pile LAMP telles que PhpMyAdmin Lite ou Adminer ; toutes deux sont des alternatives solides qui offrent de bonnes pratiques de sécurité des données. Ou mieux encore, conservez l’accès en ligne de commande afin de protéger complètement vos données contre toute intention malveillante en plaçant les connexions cruciales en dehors d’un environnement Web. Réfléchissez bien avant d’autoriser les comptes sans mot de passe : Il peut sembler pratique pour un développeur de configurer un compte root sans mot de passe sur son poste de développement local, mais c’est exactement la raison pour laquelle de nombreux professionnels de la sécurité mettent en garde contre leur utilisation dans des environnements de production. Lorsque les bases de données ne sont pas correctement sécurisées, toute personne disposant d’informations de connexion peut facilement exploiter les vulnérabilités d’injection SQL et exécuter des commandes en tant qu’utilisateur de son choix (même en tant que root). Pire encore, ces mêmes personnes peuvent potentiellement se frayer un chemin à travers les permissions sudo jusqu’à root, une fois l’accès accordé via les informations de connexion.
8) Vérifiez les bibliothèques de tiers avant de les utiliser
Si vous utilisez des bibliothèques tierces dans votre application, comme celles qui analysent les fichiers téléchargés, il est extrêmement important que vous vérifiiez d’abord si ces bibliothèques présentent des vulnérabilités connues. Bien qu’il puisse être plus facile d’utiliser une bibliothèque pré-écrite que de passer du temps à écrire votre propre code d’analyse, nous ne pouvons jamais garantir que nous n’introduirons pas de nouvelles vulnérabilités de sécurité en nous appuyant sur du code externe et nous n’améliorerons la sécurité de notre application que si nous vérifions tout avant de l’intégrer à notre projet. Pour en savoir plus : Comment vérifier la présence de failles de sécurité dans les bibliothèques tierces.
9) Déplacer les fichiers de configuration hors de la racine Web
Ces fichiers peuvent contenir toutes sortes de données sensibles, notamment les mots de passe MySQL. Si un pirate obtient l’accès à ces fichiers par le biais d’une vulnérabilité dans votre application, il lui suffit de modifier quelques lignes de code et d’exécuter une seule commande. Gardez les fichiers de configuration hors de la racine du site Web en les plaçant en dehors du répertoire de documents de votre site Web – dans wp-content/config , par exemple. Mieux encore, placez-les sur un tout autre serveur. Si vous utilisez des outils d’intégration continue comme Gitlab CI ou Github, placez les fichiers de configuration dans un dépôt privé et ne poussez pas ces dépôts vers des serveurs publics. Ensuite, mettez en place un processus automatisé qui met à jour les fichiers de configuration chaque fois que vous déployez un nouveau code.
10) Maintenez PHP à jour
Maintenir votre code à jour est un moyen infaillible de vous assurer que vous n’êtes pas vulnérable aux vulnérabilités connues. Si vous construisez quelque chose à partir de zéro, essayez d’utiliser Composer pour la gestion des dépendances ; il peut être intégré à GitLab CI pour des déploiements automatisés. Si vous travaillez sur un projet existant ou si vous souhaitez ajouter une ligne de code à la fois, n’oubliez pas git diff et git pull requests ; ces fonctionnalités permettent de s’assurer facilement que chacun sait ce qu’il fait lorsqu’il met à jour ses environnements ou fichiers locaux. Vous pouvez également envisager de créer un processus exigeant que les personnes révisent et approuvent les modifications. En fin de compte, le fait de savoir qui a apporté des modifications et quand (et comment) vous aidera à détecter les vulnérabilités plus tôt que tard. N’attendez pas que quelqu’un vous dise qu’il y a un problème, prenez des précautions de manière proactive ! Et en parlant de notifications : ne les ratez plus jamais avec les notifications de problèmes de GitLab ou les notifications de Mattermost.
