Des conseils de pro pour optimiser la sécurité de votre site Web et éviter les catastrophes de piratage.
Vous pensez peut-être que votre site ne vaut pas la peine d’être piraté, mais les sites Web sont constamment compromis. La majorité des failles de sécurité des sites Web ne visent pas à voler vos données ou à perturber la mise en page de votre site Web, mais plutôt à tenter d’utiliser votre serveur comme relais de messagerie pour le spam, ou de configurer un serveur Web temporaire, normalement pour servir des fichiers de nature illégale.
D’autres moyens très courants d’abuser des machines compromises incluent l’utilisation de vos serveurs dans le cadre d’un botnet ou l’extraction de Bitcoins. Vous pourriez même être touché par un ransomware.
Le piratage est régulièrement effectué par des scripts automatisés écrits pour parcourir Internet dans le but d’exploiter les problèmes de sécurité connus des sites Web dans les logiciels.
Voici nos neuf meilleurs conseils pour vous aider à assurer votre sécurité et celle de votre site en ligne.
- 01. Gardez le logiciel à jour
- 02. Attention à l’injection SQL
- 03. Protégez-vous contre les attaques XSS
- 04. Attention aux messages d’erreur
- 05. Valider des deux côtés
- 06. Vérifiez vos mots de passe
- 07. Évitez les téléchargements de fichiers
- 08. Utiliser HTTPS
- 09. Obtenez des outils de sécurité de site Web
01. Gardez le logiciel à jour
Cela peut sembler évident, mais il est essentiel de maintenir tous les logiciels à jour pour assurer la sécurité de votre site. Cela s’applique à la fois au système d’exploitation du serveur et à tout logiciel que vous exécutez sur votre site Web, tel qu’un CMS ou un forum. Lorsque des failles de sécurité de sites Web sont découvertes dans un logiciel, les pirates informatiques tentent rapidement d’en abuser.
Si vous utilisez une solution d’hébergement géré, vous n’avez pas à vous soucier autant de l’application des mises à jour de sécurité pour le système d’exploitation, car la société d’hébergement doit s’en occuper.
Si vous utilisez un logiciel tiers sur votre site Web, tel qu’un CMS ou un forum, vous devez vous assurer d’appliquer rapidement les correctifs de sécurité. La plupart des fournisseurs ont une liste de diffusion ou un flux RSS détaillant les problèmes de sécurité du site Web. WordPress , PrestaShop et de nombreux autres CMS vous informent des mises à jour système disponibles lorsque vous vous connectez.
De nombreux développeurs utilisent des outils tels que Composer, npm ou RubyGems pour gérer leurs dépendances logicielles, et les vulnérabilités de sécurité apparaissant dans un package dont vous dépendez mais auxquelles vous ne prêtez aucune attention sont l’un des moyens les plus simples de se faire prendre. Assurez-vous de garder vos dépendances à jour et utilisez des outils comme Gemnasium pour recevoir des notifications automatiques lorsqu’une vulnérabilité est annoncée dans l’un de vos composants.
02. Attention à l’injection SQL
Les attaques par injection SQL surviennent lorsqu’un attaquant utilise un champ de formulaire Web ou un paramètre d’URL pour accéder à votre base de données ou la manipuler. Lorsque vous utilisez Transact SQL standard, il est facile d’insérer sans le savoir du code malveillant dans votre requête qui pourrait être utilisé pour modifier des tables, obtenir des informations et supprimer des données. Vous pouvez facilement éviter cela en utilisant toujours des requêtes paramétrées, la plupart des langages Web ont cette fonctionnalité et elle est facile à mettre en œuvre.
03. Protégez-vous contre les attaques XSS
Les attaques de script intersite (XSS) injectent du code JavaScript malveillant dans vos pages, qui s’exécute ensuite dans les navigateurs de vos utilisateurs, et peut modifier le contenu de la page ou voler des informations à renvoyer à l’attaquant. Par exemple, si vous affichez des commentaires sur une page sans validation, un attaquant pourrait soumettre des commentaires contenant des balises de script et du JavaScript, qui pourraient s’exécuter dans le navigateur de tous les autres utilisateurs et voler leur cookie de connexion, permettant à l’attaque de prendre le contrôle du compte de chaque utilisateur qui a consulté le commentaire. Vous devez vous assurer que les utilisateurs ne peuvent pas injecter de contenu JavaScript actif dans vos pages.
C’est une préoccupation particulière dans les applications Web modernes, où les pages sont désormais construites principalement à partir du contenu de l’utilisateur et qui, dans de nombreux cas, génèrent du HTML qui est ensuite également interprété par des frameworks frontaux comme Angular et Ember. Ces frameworks fournissent de nombreuses protections XSS, mais mélanger le rendu serveur et client crée également de nouvelles avenues d’attaque plus compliquées : non seulement l’injection de JavaScript dans le HTML est efficace, mais vous pouvez également injecter du contenu qui exécutera du code en insérant des directives Angular ou en utilisant Ember. aides.
La clé ici est de se concentrer sur la façon dont votre contenu généré par l’utilisateur pourrait échapper aux limites que vous attendez et être interprété par le navigateur comme quelque chose d’autre que ce que vous vouliez. Ceci est similaire à la défense contre l’injection SQL. Lors de la génération dynamique de HTML, utilisez des fonctions qui effectuent explicitement les modifications que vous recherchez (par exemple, utilisez element.setAttribute et element.textContent, qui seront automatiquement échappés par le navigateur, plutôt que de définir element.innerHTML à la main), ou utilisez des fonctions dans votre outil de création de modèles qui effectuent automatiquement l’échappement approprié, plutôt que de concaténer des chaînes ou de définir du contenu HTML brut.
La politique de sécurité du contenu (CSP) est un autre outil puissant de la boîte à outils du défenseur XSS. CSP est un en-tête que votre serveur peut retourner qui indique au navigateur de limiter comment et quel JavaScript est exécuté dans la page, par exemple pour interdire l’exécution de tout script non hébergé sur votre domaine, interdire JavaScript en ligne ou désactiver eval(). Mozilla a un excellent guide avec quelques exemples de configurations. Cela rend le travail des scripts d’un attaquant plus difficile, même s’il peut les faire entrer dans votre page.
04. Attention aux messages d’erreur
Soyez prudent avec la quantité d’informations que vous donnez dans vos messages d’erreur. Ne fournissez que des erreurs minimales à vos utilisateurs, pour vous assurer qu’ils ne divulguent pas de secrets présents sur votre serveur (par exemple, des clés API ou des mots de passe de base de données). Ne fournissez pas non plus de détails complets sur les exceptions, car ceux-ci peuvent rendre les attaques complexes telles que l’injection SQL beaucoup plus faciles. Conservez les erreurs détaillées dans les journaux de votre serveur et montrez aux utilisateurs uniquement les informations dont ils ont besoin.
05. Valider des deux côtés
La validation doit toujours être effectuée à la fois côté navigateur et côté serveur. Le navigateur peut détecter des échecs simples, tels que des champs obligatoires vides et lorsque vous saisissez du texte dans un champ uniquement numérique. Ceux-ci peuvent cependant être contournés, et vous devez vous assurer de vérifier ces validations et une validation plus approfondie côté serveur, car à défaut de le faire, un code malveillant ou un code de script pourrait être inséré dans la base de données ou pourrait entraîner des résultats indésirables sur votre site Web.
06. Vérifiez vos mots de passe
Tout le monde sait qu’ils doivent utiliser des mots de passe complexes, mais cela ne veut pas dire qu’ils le font toujours. Il est crucial d’utiliser des mots de passe forts pour la zone d’administration de votre serveur et de votre site Web, mais il est tout aussi important d’insister sur les bonnes pratiques en matière de mots de passe pour vos utilisateurs afin de protéger la sécurité de leurs comptes.
Même si les utilisateurs peuvent ne pas l’aimer, l’application d’exigences de mot de passe telles qu’un minimum d’environ huit caractères, y compris une lettre majuscule et un chiffre aidera à protéger leurs informations à long terme.
Les mots de passe doivent toujours être stockés sous forme de valeurs cryptées, de préférence en utilisant un algorithme de hachage à sens unique tel que SHA. L’utilisation de cette méthode signifie que lorsque vous authentifiez des utilisateurs, vous ne comparez que des valeurs chiffrées. Pour une sécurité supplémentaire du site Web, il est judicieux de saler les mots de passe, en utilisant un nouveau sel par mot de passe.
Dans le cas où quelqu’un piraterait et volerait vos mots de passe, l’utilisation de mots de passe hachés pourrait aider à limiter les dommages, car leur décryptage n’est pas possible. Le mieux que quelqu’un puisse faire est une attaque par dictionnaire ou une attaque par force brute, essentiellement en devinant chaque combinaison jusqu’à ce qu’elle trouve une correspondance. Lors de l’utilisation de mots de passe salés, le processus de craquage d’un grand nombre de mots de passe est encore plus lent, car chaque estimation doit être hachée séparément pour chaque mot de passe salé + mot de passe, ce qui est très coûteux en calcul.
Heureusement, de nombreux CMS fournissent une gestion des utilisateurs prête à l’emploi avec de nombreuses fonctionnalités de sécurité de site Web intégrées, bien que certaines configurations ou modules supplémentaires puissent être nécessaires pour utiliser des mots de passe salés (avant Drupal 7) ou pour définir la force minimale du mot de passe. Si vous utilisez .NET, cela vaut la peine d’utiliser des fournisseurs d’adhésion car ils sont très configurables, fournissent une sécurité de site Web intégrée et incluent des contrôles prêts à l’emploi pour la réinitialisation de la connexion et du mot de passe.
07. Évitez les téléchargements de fichiers
Permettre aux utilisateurs de télécharger des fichiers sur votre site Web peut être un gros risque pour la sécurité du site Web, même s’il s’agit simplement de changer leur avatar. Le risque est que tout fichier téléchargé, aussi innocent qu’il puisse paraître, puisse contenir un script qui, lorsqu’il est exécuté sur votre serveur, ouvre complètement votre site Web.
Si vous avez un formulaire de téléchargement de fichiers, vous devez traiter tous les fichiers avec une grande méfiance. Si vous autorisez les utilisateurs à télécharger des images, vous ne pouvez pas vous fier à l’extension de fichier ou au type mime pour vérifier que le fichier est une image, car ils peuvent facilement être falsifiés. Même l’ouverture du fichier et la lecture de l’en-tête, ou l’utilisation de fonctions pour vérifier la taille de l’image ne sont pas infaillibles. La plupart des formats d’images permettent de stocker une section de commentaires pouvant contenir du code PHP pouvant être exécuté par le serveur.
Alors, que pouvez-vous faire pour empêcher cela? En fin de compte, vous voulez empêcher les utilisateurs de pouvoir exécuter n’importe quel fichier qu’ils téléchargent. Par défaut, les serveurs Web n’essaieront pas d’exécuter des fichiers avec des extensions d’image, mais ne vous fiez pas uniquement à la vérification de l’extension de fichier car un fichier portant le nom image.jpg.php est connu pour passer.
Certaines options consistent à renommer le fichier lors du téléchargement pour garantir l’extension de fichier correcte ou à modifier les autorisations du fichier, par exemple, chmod 0666 afin qu’il ne puisse pas être exécuté. Si vous utilisez *nix, vous pouvez créer un fichier .htaccess qui n’autorisera l’accès qu’aux fichiers définis empêchant l’attaque à double extension mentionnée précédemment.
En fin de compte, la solution recommandée est d’empêcher complètement l’accès direct aux fichiers téléchargés. De cette façon, tous les fichiers téléchargés sur votre site Web sont stockés dans un dossier en dehors de la racine Web ou dans la base de données en tant que blob. Si vos fichiers ne sont pas directement accessibles, vous devrez créer un script pour récupérer les fichiers du dossier privé (ou un gestionnaire HTTP dans .NET) et les livrer au navigateur. Les balises d’image prennent en charge un attribut src qui n’est pas une URL directe vers une image, de sorte que votre attribut src peut pointer vers votre script de livraison de fichier à condition que vous définissiez le type de contenu correct dans l’en-tête HTTP.
La plupart des hébergeurs s’occupent de la configuration du serveur pour vous, mais si vous hébergez votre site Web sur votre propre serveur, il y a peu de choses que vous voudrez vérifier.
Assurez-vous d’avoir une configuration de pare-feu et de bloquer tous les ports non essentiels. Si possible mettre en place une DMZ (Zone Démilitarisée) permettant uniquement l’accès aux ports 80 et 443 depuis le monde extérieur. Bien que cela puisse ne pas être possible si vous n’avez pas accès à votre serveur à partir d’un réseau interne, car vous devrez ouvrir des ports pour permettre le téléchargement de fichiers et vous connecter à distance à votre serveur via SSH ou RDP.
Si vous autorisez le téléchargement de fichiers à partir d’Internet, utilisez uniquement des méthodes de transport sécurisées vers votre serveur telles que SFTP ou SSH.
Si possible, faites fonctionner votre base de données sur un serveur différent de celui de votre serveur Web. Cela signifie que le serveur de base de données n’est pas accessible directement depuis le monde extérieur, seul votre serveur Web peut y accéder, minimisant ainsi le risque d’exposition de vos données.
Enfin, n’oubliez pas de restreindre l’accès physique à votre serveur.
08. Utiliser HTTPS
HTTPS est un protocole utilisé pour assurer la sécurité sur Internet. HTTPS garantit que les utilisateurs parlent au serveur qu’ils attendent et que personne d’autre ne peut intercepter ou modifier le contenu qu’ils voient en transit.
Si vous avez quelque chose que vos utilisateurs pourraient vouloir privé, il est fortement conseillé d’utiliser uniquement HTTPS pour le livrer. Cela signifie bien sûr les pages de carte de crédit et de connexion (et les URL auxquelles elles se soumettent), mais généralement beaucoup plus de votre site. Un formulaire de connexion définira souvent un cookie par exemple, qui est envoyé avec chaque autre demande à votre site qu’un utilisateur connecté fait, et est utilisé pour authentifier ces demandes. Un attaquant qui le volerait serait capable d’imiter parfaitement un utilisateur et de reprendre sa session de connexion. Pour vaincre ce type d’attaques, vous souhaitez presque toujours utiliser HTTPS pour l’ensemble de votre site.
Ce n’est plus aussi compliqué ou coûteux qu’avant. Let’s Encrypt fournit des certificats totalement gratuits et automatisés, dont vous aurez besoin pour activer HTTPS, et il existe des outils communautaires existants disponibles pour un large éventail de plates-formes et de frameworks courants pour les configurer automatiquement pour vous.
Notamment, Google a annoncé qu’il vous augmenterait dans les classements de recherche si vous utilisez HTTPS, ce qui lui confère également un avantage pour le référencement. Le HTTP non sécurisé est en voie de disparition, et il est maintenant temps de le mettre à niveau.
Vous utilisez déjà HTTPS partout ? Allez plus loin et examinez la configuration de HTTP Strict Transport Security (HSTS), un en-tête simple que vous pouvez ajouter aux réponses de votre serveur pour interdire le HTTP non sécurisé pour l’ensemble de votre domaine.
09. Obtenez des outils de sécurité de site Web
Une fois que vous pensez avoir fait tout ce que vous pouvez, il est temps de tester la sécurité de votre site Web. Le moyen le plus efficace d’y parvenir consiste à utiliser certains outils de sécurité de site Web, souvent appelés tests de pénétration ou tests d’intrusion en abrégé.
Il existe de nombreux produits commerciaux et gratuits pour vous aider avec cela. Ils fonctionnent sur une base similaire aux pirates de scripts en ce sens qu’ils testent tous les exploits connus et tentent de compromettre votre site en utilisant certaines des méthodes mentionnées précédemment, telles que l’injection SQL.
Quelques outils gratuits qui valent le détour :
- Netsparker (édition communautaire gratuite et version d’essai disponible). Bon pour tester l’injection SQL et XSS
- OpenVAS prétend être le scanner de sécurité open source le plus avancé. Bon pour tester les vulnérabilités connues, scanne actuellement plus de 25 000. Mais il peut être difficile à configurer et nécessite l’installation d’un serveur OpenVAS qui ne fonctionne que sur *nix. OpenVAS est un fork d’un Nessus avant qu’il ne devienne un produit commercial à code source fermé.
- SecurityHeaders.io (vérification en ligne gratuite). Un outil pour signaler rapidement quels en-têtes de sécurité mentionnés ci-dessus (tels que CSP et HSTS) un domaine a activé et correctement configuré.
- Xenotix XSS Exploit Framework Un outil d’OWASP (Open Web Application Security Project) qui comprend une vaste sélection d’exemples d’attaques XSS, que vous pouvez exécuter pour confirmer rapidement si les entrées de votre site sont vulnérables dans Chrome, Firefox et IE.
Les résultats des tests automatisés peuvent être intimidants, car ils présentent une multitude de problèmes potentiels. L’important est de se concentrer d’abord sur les problèmes critiques. Chaque problème signalé est normalement accompagné d’une bonne explication de la vulnérabilité potentielle. Vous constaterez probablement que certains des problèmes moyens/faibles ne sont pas une préoccupation pour votre site.
Vous pouvez prendre d’autres mesures pour essayer manuellement de compromettre votre site en modifiant les valeurs POST/GET. Un proxy de débogage peut vous aider ici car il vous permet d’intercepter les valeurs d’une requête HTTP entre votre navigateur et le serveur
Alors, que devriez-vous essayer de modifier sur la demande ? Si vous avez des pages qui ne devraient être visibles que par un utilisateur connecté, essayez de modifier les paramètres d’URL tels que l’identifiant de l’utilisateur ou les valeurs des cookies pour tenter d’afficher les détails d’un autre utilisateur. Un autre domaine à tester sont les formulaires, la modification des valeurs POST pour tenter de soumettre du code pour exécuter XSS ou le téléchargement d’un script côté serveur.
Besoin d’aides ? n’hésitez pas à nous contacter.
