11 astuces pour protéger votre site et serveur web

Nous prêtons souvent attention à la conception de sites Web, au référencement, au contenu, et nous négligeons la sécurité de ces sites web et des serveurs qui les hébergent. En tant que webmaster, blogueur, amateur d’internet, vous devriez savoir que la sécurité de vos infrastructures web et internet sont plus importants que tout.

Il y avait beaucoup de questions notamment  comment analyser la sécurité du site Web, les vulnérabilités des applications mobiles alors voilà. Dans cet article, je vais énumérer quelques  méthodes afin de garantir un minimum de sécurité et aussi quelques outils gratuits pour analyser votre site pour les failles de sécurité, les logiciels malveillants.

 

Mesures de sécurité

 

1- Garder le logiciel à jour

Cela peut sembler évident, mais il est essentiel de veiller à ce que tous les logiciels (de votre serveur et de votre site web) 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 informent des mises à jour système disponibles lorsque vous vous connectez.

 

2- Sauvegardez vos données en ligne et en local

 

3- Vérifiez vos fichiers journal régulièrement pour découvrir toute anomalie

Soyez attentifs aux informations que vous recevez dans vos messages d’erreur. Aussi, ne fournissez que des erreurs minimales à vos utilisateurs, pour 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 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.

 

4- Protéger contre les attaques 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.

Un autre outil puissant dans la boîte à outils du défenseur XSS est la politique de sécurité du contenu (CSP). 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.

 

5- Attention à l’injection SQL

Une attaque par injection SQL est 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.

Considérez cette requête:

"SELECT * FROM table WHERE column = '" + parameter + "';"

Si un attaquant a changé le paramètre d’URL pour passer en ‘ou’ 1 ‘=’ 1, la requête ressemblera à ceci:

"SELECT * FROM table WHERE column = '' OR '1'='1';"

Puisque ‘1’ est égal à ‘1’ cela permettra à l’attaquant d’ajouter une requête supplémentaire à la fin de l’instruction SQL qui sera également exécutée.

Vous pouvez corriger cette requête en la paramétrant explicitement. Par exemple, si vous utilisez MySQLi en PHP, cela devrait devenir:

$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value');
$stmt->execute(array('value' => $parameter));

 

6- Utiliser HTTPS

HTTPS est un protocole utilisé pour assurer la sécurité sur Internet. HTTPS garantit que les utilisateurs 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é, 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 de chez APPATAM (Côte d’Ivoire) 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. HTTP non sécurisé est sur le point de sortir, et il est temps de se mettre à jour.

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.

 

 

7- Vérifiez vos 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.

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 les fournisseurs d’appartenances car ils sont très configurables, fournissent une sécurité de site Web intégrée et incluent des contrôles readymade pour la réinitialisation de mot de passe et de connexion.

 

8- En cas d’utilisation de bases de données sur le serveur même, pensez à restreindre son accès aux utilisateurs locaux

 

9-É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é 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, 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 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 infaillibles. 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 n’essaieront pas d’exécuter des fichiers avec des extensions d’image, mais ne se fient pas 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 autorisera uniquement l’accès à des fichiers d’ensemble empêchant l’attaque à double extension mentionnée plus haut.

Utiliser un antivirus aussi s’avère très utile

 

10- Utiliser un pare-feu

 

11- Obtenir des outils de sécurité de 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 sur une base similaire à celle des scripts hackers 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 SQL Injection.

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

Vous pouvez prendre d’autres mesures pour tenter 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. 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 doivent être visibles que pour un utilisateur connecté, essayez de modifier les paramètres d’URL tels que l’ID utilisateur ou les valeurs de cookie pour tenter d’afficher les détails d’un autre utilisateur. Un autre domaine qui mérite d’être testé sont les formulaires, en modifiant les valeurs POST pour tenter de soumettre du code pour exécuter XSS ou en téléchargeant un script côté serveur.

 

 

Liste des outils pour scanner votre site web et votre serveur

• Scan My Server
• SUCURI
• Qualys SSL Labs, Qualys FreeScan
• Quttera
• Detectify
• SiteGuarding
• Web Inspector
• Acunetix
• Asafa Web
• Netsparker Cloud
• UpGuard Web Scan
• Tinfoil Security

 

En cas de besoin, Je suis joignable +225 57629503 ou à admin@monastuce.net

Mina-Yefien Alex Cédric COULIBALY