Comment sécuriser votre site web ?

Des conseils professionnels pour optimiser la sécurité de votre site et éviter les désastres de piratage.

Vous ne pensez peut-être pas que votre site a quelque chose qui mérite d’être piraté, mais les sites Web sont compromis tout le temps. La majorité des violations de sécurité de sites Web ne visent pas à voler vos données ou à dégrader votre site Web, mais plutôt à utiliser votre serveur comme relais de courrier indésirable ou pour configurer un serveur Web temporaire, normalement pour servir des fichiers illégaux.

Le piratage est régulièrement effectué par des scripts automatisés écrits pour parcourir Internet afin d’exploiter les problèmes connus de sécurité de sites Web dans les logiciels. Voici nos 10 meilleurs conseils pour vous aider à vous protéger, vous et votre site, en ligne.

01. Garder le logiciel à jour

Cela peut sembler évident, mais il est essentiel de veiller à ce que tous les logiciels soient à 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 utilisez sur votre site Web, tel qu’un CMS ou un forum. Lorsque des failles de sécurité du site Web sont détectées dans un logiciel, les pirates tentent rapidement d’en abuser.

Si vous utilisez une solution d’hébergement gérée, vous n’avez pas à vous préoccuper autant de l’application des mises à jour de sécurité pour le système d’exploitation que la société d’hébergement doit en prendre soin.

Si vous utilisez un logiciel tiers sur votre site Web, tel qu’un CMS ou un forum, vous devez veiller à 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é de site Web.

WordPress, Umbraco et de nombreux autres CMS vous avertissent 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 paquet dont vous dépendez sans y prêter attention sont l’un des moyens les plus faciles de se faire prendre.

Assurez-vous de garder vos dépendances à jour, et utilisez des outils comme Gemnasium pour obtenir des notifications automatiques lorsqu’une vulnérabilité est annoncée dans l’un de vos composants.

02. Injection SQL

Les attaques par injection SQL sont 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 le standard Transact SQL, il est facile d’insérer sans le savoir un code malveillant dans votre requête, ce 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 il est facile à implémenter.

03. XSS

Les attaques XSS (Cross-Site Scripting) injectent des scripts JavaScript malveillants dans vos pages, qui s’exécutent ensuite dans les navigateurs de vos utilisateurs, et peuvent 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 JavaScript, qui pourraient être lancés dans le navigateur de tous les autres utilisateurs et voler leur cookie de connexion, permettant à l’attaque de prendre le contrôle de chaque utilisateur qui a consulté le commentaire.

Vous devez vous assurer que les utilisateurs ne peuvent pas injecter du contenu JavaScript actif dans vos pages.
Cela est particulièrement préoccupant dans les applications web modernes, où les pages sont maintenant construites principalement à partir du contenu de l’utilisateur, et qui dans de nombreux cas génèrent du HTML qui est ensuite interprété par des frameworks frontaux comme Angular et Ember. Ces frameworks fournissent de nombreuses protections XSS, mais le mélange des rendus serveur et client crée aussi de nouvelles et plus complexes attaques: non seulement injecter du JavaScript dans le HTML, mais aussi 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. Lorsque vous générez dynamiquement du HTML, utilisez des fonctions qui apportent explicitement les changements que vous recherchez (par exemple, utilisez element.set Attribute et element.text Content, qui seront automatiquement échappés par le navigateur, plutôt que de définir manuellement element.inner HTML), ou utilisez des fonctions dans votre outil de création de modèle qui fait automatiquement l’échappement approprié plutôt que de concaténer des chaînes ou de définir du contenu HTML brut.

Un autre outil puissant dans la boîte à outils du défenseur XSS est CSP (Content Security Policy). CSP est un en-tête que votre serveur peut renvoyer et qui indique au navigateur de limiter et exécuter JavaScript sur la page, par exemple pour interdire l’exécution de scripts non hébergés sur votre domaine, interdire JavaScript inline ou désactiver eval (). Mozilla a un excellent guide avec quelques exemples de configurations. Cela rend plus difficile le fonctionnement des scripts d’un attaquant, même s’ils peuvent les intégrer dans votre page.

04. 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, afin de vous assurer qu’ils ne fuient pas les secrets présents sur votre serveur (par exemple, les clés API ou les mots de passe de la base de données). Ne fournissez pas non plus de détails d’exception, car ceux-ci peuvent faciliter les attaques complexes comme l’injection SQL. Conservez des erreurs détaillées dans les journaux de votre serveur et montrez aux utilisateurs uniquement les informations dont ils ont besoin.

05. Validation côté serveur / validation de formulaire

La validation doit toujours être effectuée du côté du navigateur et du serveur. Le navigateur peut détecter des échecs simples tels que les champs obligatoires vides et lorsque vous entrez du texte dans un champ numérique uniquement. Ceux-ci peuvent toutefois être contournés, et vous devez vous assurer que vous vérifiez ces aspects de validation et de validation plus approfondie du serveur car cela pourrait conduire à l’insertion de code malveillant ou de code de script dans la base de données ou causer des résultats indésirables sur votre site.

06. Mots de passe

Tout le monde sait qu’ils devraient 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 votre serveur et la zone d’administration du site Web, mais il est également important d’insister sur de bonnes pratiques de mot de passe pour vos utilisateurs afin de protéger la sécurité de leurs comptes.

Même si les utilisateurs ne l’apprécient pas, l’application des exigences relatives aux mots de passe, comme un minimum de huit caractères, y compris une lettre majuscule et un numéro, 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 cryptées. Pour une sécurité supplémentaire sur le site Web, il est recommandé de mettre les mots de passe au goût du jour, en utilisant un nouveau mot de passe par mot de passe.

En cas de piratage et de vol de vos mots de passe, l’utilisation de mots de passe hachés pourrait contribuer à limiter les limitations, car il est impossible de les décrypter. Le meilleur que quelqu’un peut faire est une attaque de dictionnaire ou une attaque de force brute, devinant essentiellement chaque combinaison jusqu’à ce qu’il 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 supposition doit être hachée séparément pour chaque mot de passe sel + qui est très coûteux en termes de calcul.

En cas de piratage et de vol de vos mots de passe, l’utilisation de mots de passe hachés pourrait contribuer à limiter les limitations, car il est impossible de les décrypter. Le meilleur que quelqu’un peut faire est une attaque de dictionnaire ou une attaque de force brute, devinant essentiellement chaque combinaison jusqu’à ce qu’il 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 supposition doit être hachée séparément pour chaque mot de passe sel + qui est très coûteux en termes de calcul.

Heureusement, de nombreux CMS fournissent une gestion des utilisateurs prête à l’emploi avec beaucoup de ces fonctionnalités de sécurité, bien que certains modules de configuration ou supplémentaires puissent être nécessaires pour utiliser des mots de passe salés (pré 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’appartenances car ils sont très configurables, fournissent une sécurité de site intégrée et incluent des contrôles readymade pour la réinitialisation et la réinitialisation du mot de passe.

07. Importations de fichiers

Permettre aux utilisateurs de télécharger des fichiers sur votre site Web peut être un gros risque pour la sécurité des sites Web, même si c’est simplement pour changer leur avatar. Le risque est que tout fichier téléchargé aussi innocent que cela puisse paraître, pourrait 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 beaucoup de suspicion. Si vous autorisez les utilisateurs à télécharger des images, vous ne pouvez pas vous fier à l’extension du fichier ou au type MIME pour vérifier que le fichier est une image, car ces images peuvent facilement être truquées. 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 une preuve complète. La plupart des formats d’images permettent de stocker une section de commentaire qui pourrait contenir du code PHP qui pourrait être exécuté par le serveur.

Alors, que pouvez-vous faire pour éviter cela? En fin de compte, vous voulez empêcher les utilisateurs d’exécuter n’importe quel fichier qu’ils téléchargent. Par défaut, les serveurs Web ne tenteront pas d’exécuter des fichiers avec des extensions d’image, mais il n’est pas recommandé de se fier uniquement à la vérification de l’extension de fichier sous la forme d’un fichier portant le nom image.jpg.php.

Certaines options consistent à renommer le fichier lors du téléchargement pour garantir l’extension de fichier correcte ou pour modifier les autorisations de 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 (voir ci-dessous) qui ne permettra que l’accès à des fichiers d’ensemble empêchant l’attaque à double extension mentionnée plus haut.

En fin de compte, la solution recommandée est d’empêcher l’accès direct aux fichiers téléchargés tous ensemble. De cette façon, tous les fichiers téléchargés sur votre site Web sont stockés dans un dossier en dehors du site Web ou dans la base de données sous forme de blob. Si vos fichiers ne sont pas directement accessibles, vous devrez créer un script pour extraire les fichiers du dossier privé (ou un gestionnaire HTTP dans .NET) et les envoyer au navigateur. Les balises d’image prennent en charge un attribut src qui n’est pas une URL directe d’une image. Votre attribut src peut donc pointer vers votre script de distribution de fichiers si vous avez défini le type de contenu correct dans l’en-tête HTTP.

La plupart des fournisseurs d’hébergement 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 bloquez 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 du monde extérieur. Cela peut ne pas être possible si vous n’avez pas accès à votre serveur depuis un réseau interne, car vous devrez ouvrir des ports pour autoriser 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, n’utilisez que des méthodes de transport sécurisées sur 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, ce qui minimise le risque d’exposition de vos données.

Enfin, n’oubliez pas de restreindre l’accès physique à votre serveur.

08. HTTPS

HTTPS est un protocole utilisé pour assurer la sécurité sur Internet. HTTPS garantit aux utilisateurs qu’ils parlent au serveur auquel ils s’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 seulement HTTPS pour le livrer. Cela signifie bien sûr des cartes de crédit et des pages de connexion (et les URL auxquelles elles sont soumises) mais généralement beaucoup plus de votre site. Un formulaire de connexion va souvent définir un cookie par exemple, qui est envoyé avec toutes les autres demandes à votre site qu’un utilisateur connecté fait, et est utilisé pour authentifier ces demandes. Un attaquant qui aurait volé ceci serait capable d’imiter parfaitement un utilisateur et de prendre en charge sa session de connexion. Pour vaincre ce genre d’attaques, vous souhaitez presque toujours utiliser HTTPS pour l’ensemble de votre site.

Ce n’est plus aussi difficile ou coûteux que c’était autrefois. Let’s Encrypt fournit des certificats totalement gratuits et automatisés, dont vous aurez besoin pour activer HTTPS, et il existe des outils communautaires disponibles pour un large éventail de plates-formes et de frameworks communs afin de les configurer automatiquement pour vous.

Notamment Google a annoncé qu’ils vous stimuleront dans les classements de recherche si vous utilisez HTTPS, ce qui donne également un avantage SEO. Mais il y a toujours un problème avec cette carotte: Chrome et les autres navigateurs prévoient de mettre en place des avertissements de plus en plus importants sur tous les sites qui ne le feront pas, à partir de janvier 2017. HTTP incertain est sur le point de disparaître. améliorer.

Vous utilisez déjà HTTPS partout? Allez plus loin et regardez la configuration de HTTP Strict Transport Security (HSTS), un en-tête facile que vous pouvez ajouter aux réponses de votre serveur pour interdire le HTTP non sécurisé pour l’ensemble de votre domaine.

09. Outils de sécurité du site Web

Une fois que vous pensez que vous avez fait tout ce que vous pouvez alors il est temps de tester la sécurité de votre site Web. Le moyen le plus efficace de le faire est l’utilisation de certains outils de sécurité de site Web, souvent appelés tests de pénétration ou test de stylo pour faire court.

Il existe de nombreux produits commerciaux et gratuits pour vous aider avec cela. Ils fonctionnent de la même manière que les scripts que les hackers utiliseront en ce 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 la peine d’être regardés :

  • Netsparker (édition communautaire gratuite et version d’essai disponible). Bon pour tester l’injection SQL et XSS
  • OpenVAS . Revendique ê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 la fourche d’un Nessus avant qu’il ne devienne un produit commercial à source fermée.
  • SecurityHeaders.io (vérification en ligne gratuite). Un outil pour signaler rapidement les en-têtes de sécurité mentionnés ci-dessus (tels que CSP et HSTS) qu’un domaine a activés et correctement configurés.
  • Xenotix XSS Exploit Framework Un outil de OWASP (Open Web Application Security Project) qui comprend un grand choix 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 décourageants, 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 rapporté vient normalement avec une bonne explication de la vulnérabilité potentielle. Vous constaterez probablement que certaines des problématiques moyennes / faibles ne sont pas un problème pour votre site.

Si vous souhaitez aller un peu plus loin, vous pouvez prendre d’autres mesures pour tenter de compromettre manuellement 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. Une application freeware populaire appelée Fiddler est un bon point de départ.

Alors, que devriez-vous essayer de modifier à la demande? Si vous avez des pages qui ne devraient être visibles que par un utilisateur connecté, alors j’essaierais de changer les paramètres d’URL tels que l’identifiant de l’utilisateur, ou les valeurs des cookies pour essayer d’afficher les détails d’un autre utilisateur. Un autre domaine qui mérite d’être testé sont les formulaires, modifier les valeurs POST pour tenter de soumettre du code pour exécuter XSS ou pour télécharger un script côté serveur.

J’espère que ces conseils vous aideront à protéger votre site et vos informations. Heureusement, la plupart des CMS ont beaucoup de fonctionnalités intégrées de sécurité de site Web, mais c’est toujours une bonne idée d’avoir connaissance des exploits de sécurité les plus courants afin que vous puissiez vous assurer que vous êtes couvert.

Il existe également des modules utiles disponibles pour les CMS afin de vérifier votre installation pour les failles de sécurité courantes telles que Security Review pour Drupal et WP Security Scan pour WordPress.