Archives: sécurité

Pour créer un site WordPress, certaines personnes installent une coquille WordPress directement en ligne. Il y apportent ensuite les ajustements nécessaires et les résultats sont visibles immédiatement.  Pourtant, il est plus sécuritaire de faire un développement en local avec un environnement comme EasyPHP puis de procéder à la mise en ligne une fois que le site est complètement fonctionnel et bien testé. Voici donc comment effectuer la mise en ligne d'un site WordPress qui a été développé localement sur votre poste de travail.

Base de données

WordPress utilise une base de données MySQL. Pour mettre en ligne cette base de données, certains hébergeurs donnent accès à une interface phpMyAdmin. D'autres hébergeurs vous demandent de téléverser un script SQL et se chargent de mettre la base de données en place. Si vous travaillez sur votre propre serveur, vous pourrez même travailler directement à la ligne de commande si vous le désirez. L'hébergeur fournit généralement une interface permettant de créer un usager MySQL n'ayant des droit que pour la base de données de votre site Web. Si ce n'est pas le cas, pensez à changer d'hébergeur car une faille sur un autre site ouvrira la porte vers votre BD...

Ajustement du script SQL

Puisque WordPress enregistre les URL absolus dans la BD (ex : <img src="http://127.0.0.1/dossierdusite/wp-content/uploads/2016/10/logo.png" alt="Compagnie XYZ" />), vous devez commencer par ajuster le script SQL en remplaçant toutes les occurences de « http://127.0.0.1/dossierdusite » par « http://nomdedomaine.com ». Généralement, le fait de modifier l'URL du site fait en sorte que certaines configurations qui étaient faites sur le site local sont perdues une fois en ligne. Pour éviter ce problème, suivez les instructions données dans l'article « Pourquoi est-ce que je perds les personnalisations de mon thème lors de la mise en ligne ? »

Ligne de commande

Si vous avez accès à la ligne de commande sur le serveur, vous faites partie des chanceux ! Il vous sera possible d'importer une base de données à l'aide d'une seule commande. Vous devez cependant vous assurer que le script commence par faire un USE sur la base de données. À l'invite de commande sur le serveur, entrez la commande suivante : Attention : cette commande est une commande à entrer à l'invite de commande du système d'exploitation (fenêtre de commande DOS) et non à la ligne de commande MySQL.

phpMyAdmin

Si votre hébergeur vous donne accès à phpMyAdmin, vous pourrez l'utiliser pour manipuler votre base de données. 

• Si la base de données n'existe pas, commencez par la créer à l'aide de l'interface fournie.
• Assurez-vous que la BD soit sélectionnée.
• Accédez à l'onglet SQL puis faites un copier-coller de votre script SQL.

Prenez note que si le script SQL est long (ce qui est généralement le cas avec un BD WordPress), il peut y avoir un délai de quelques secondes entre le moment où vous copier votre script dans la fenêtre SQL et le moment où celui-ci apparaît.

Ajustement du fichier wp-config.php

Avant d'être copié sur le serveur, le fichier wp-config.php doit être ajusté. Les informations à entrer sont fournies par l'hébergeur. Les informations à modifier sont les suivantes :

• define('DB_NAME', 'nomdelabd');
• define('DB_USER', 'usagermysql');
• define('DB_PASSWORD', 'motdepasse');
• define('DB_HOST', 'nomhotemysql');

Sécurité

Si vous avez utilisé des outils de débogage pendant le développement, assurez-vous qu'ils ne génèrent pas d'information compromettante une fois en ligne. Vous devez apporter les ajustements suivants :

• dans wp-config.php : define('WP_DEBUG', false);
• détruire le fichier www\votresite\wp-content\debug.log
• aucun fichier .sql ne doit être mis en ligne (ils devraient d'ailleurs tous être dans le dossier dev, qui ne sera pas copié sur le serveur)

Référencement

Avant de copier les fichiers sur le serveur, assurez-vous que le fichier robots.txt demande aux robots d'indexer votre site, à l'exception des fichiers et dossiers sensibles. Ex : Si votre client ne souhaite pas que les images qu'il ajoute dans ses pages et ses articles soient indexées sur Google, vous pourriez également ajouter le dossier /wp-contents/uploads/ à cette liste.

Copie des fichiers WordPress

Ici encore, la façon de copier les fichiers chez l'hébergeur dépend des outils que l'hébergeur met à votre disposition. Certains fournissent les informations pour que vous accédiez à vos fichiers via un utilitaire FTP. D'autres fournissent un outil intégré.

Fichiers à exclure

Il est inutile, voir nuisible, de copier les fichiers suivants sur le serveur :

• Si vous avez créé un dossier dev contenant différents fichiers utilisés lors du développement, il ne doit absolument pas être copié sur le serveur.
• Seuls les thèmes et extensions effectivement utilisés doivent être mis en ligne.
• Fichier license.txt
• Fichier readme.html
• Fichier wp-config-sample.php
• Fichier debug.log
• Si votre éditeur a créé des fichiers ou des dossiers de travail (ex : dossier .idea avec PhpStorm ou encore fichier .clpprj avec CodeLobster), ils ne doivent pas être copiés sur le serveur.

Utilitaire FTP

Il existe de nombreux utilitaires FTP gratuits. Si vous souhaitez mettre vos fichiers en ligne via FTP, vous devez en installer un à votre choix sur votre poste de travail.

• FileZilla
• Core FTP LE
• WS_FTP LE

Une fois le client FTP installé, configurez-le à l'aide des informations fournies par votre hébergeur. Dans l'interface du client FTP, faites glisser tout le contenu du dossier de votre site Web (wp-admin, wp-content, etc.), à l'exception des fichiers mentionnés plus haut, vers le dossier suggéré par votre hébergeur (ex : public_html, htdocs, etc.).

Outil intégré de gestion des fichiers

Si votre hébergeur vous fournit un outil intégré, entrez les informations demandées pour vous authentifier puis copiez tout le contenu du dossier de votre site Web, à l'exception des fichiers mentionnés plus haut, vers le dossier suggéré par votre hébergeur. Certains outils permettent de transférer un seul fichier .zip et de le décompresser automatiquement. Attention, cependant, la taille d'un tel fichier est souvent limitée. On a vu des limites allant de 5 Mo sur certains hébergeurs à 200 Mo sur d'autres. Si votre site dépasse la taille maximale allouée, vous devrez créer plusieurs petits fichiers .zip. N'oubliez pas de supprimer le fichier .zip du serveur une fois l'opération complétée.

Permissions sur les fichiers

Téléversement d'images

Si vous désirez téléverser des images à l'aide du panneau de configuration WordPress, vous devez vous assurer que le dossier wp-content/uploads dispose des droits d'écriture. Vous pouvez généralement réaliser cette opération à partir de l'interface fournie par votre hébergeur.

Ajustements futurs à la feuille de style

Une fois le site en ligne, il est possible de modifier la feuille de style directement dans le tableau de bord à l'aide du menu Apparence / Éditeur. Il faut cependant donner les droits d'écriture sur le fichier wp-content\themes\votretheme\style.css.

Droits d'écriture sur d'autres dossiers

Il est préférable de ne pas donner les droits d'écritures sur les autres fichiers et dossiers du site Web à moins d'avoir une raison valable de le faire. En effet, les hackers aiment bien trouver des endroits où déposer leurs fichiers malveillants. Ils le feront généralement à votre insu, sans même porter atteinte à votre site Web. Cependant, il pourraient publier des URL qui débutent par votre nom de domaine mais qui pointent vers des sites pornographiques ou autres. Ouch !

Un fichier .inc contient le même genre de code qu'un fichier .php. Cependant, par convention, on utilise l'extension .inc pour indiquer qu'il ne s'agit pas d'une page Web mais plutôt d'un fichier non autonome, qui sera INClus dans un autre. On pourrait par exemple avoir un fichier .inc qui contient l'information à placer au début de chaque page Web du site, un autre fichier .inc qui contient les information à placer à la fin de chacune des pages, etc.

Normalement, un fichier .inc devrait par défaut jouir des mêmes protections qu'un fichier .php. Les configurations du serveur peuvent cependant offrir des protections différentes.

(suite…)

Pendant le débogage d'un programme, plutôt que d'utiliser un débogueur, nous choisissons parfois d'afficher une variable à l'écran pour vérifier sa valeur. Mais pour nous assurer que cet affichage ne pourra pas avoir lieu lorsque le site sera en production (en cas où on oublierait d'effacer l'instruction qui l'affiche), nous utilisons notre fonction maison echo_debug().

Il serait intéressant d'appliquer la même logique aux messages d'erreur générés par PHP. En effet, lorsqu'un programme PHP rencontre du code pour lequel il a un message à envoyer, comme par exemple une erreur fatale, un avertissement ou l'utilisation d'une fonction obsolète, le message est automatiquement affiché à l'écran. Ce comportement est très pratique pendant la phase de développement. Cependant, une fois le site en production, ces messages peuvent ouvrir des trous de sécurité puisque le nom et le chemin du fichier concerné sont affichés.

(suite…)

En tant que développeur Web, vous devez être au courant des attaques qui pourraient être menées contre les sites que vous développez. Ceci vous permettra de mieux protéger votre code et vos données.

Cet article vous présente trois types d'attaques : les injections SQL, les attaques XSS et les attaques CSRF. Soyez avisé qu'il existe de nombreux autres types d'attaques. Ceci ne constitue qu'un minimum à connaître. De plus, les descriptions et exemples présentés ici ne constituent qu'une partie des techniques mises en place par les utilisateurs malveillants.

(suite…)

La validation d'un formulaire Web est une tâche complexe. Il faut en effet s'assurer que les données entrées par l'usager correspondent au format attendu, qu'elles soient valables et qu'elles ne compromettent pas la sécurité du site Web.

Normalement, une fois que l'usager a cliqué sur le bouton de soumission, les données entrées devraient être valides puisque la validation a déjà été effectuée côté client. Cependant, comme cette validation peut être désactivée, il est absolument nécessaire de refaire la validation côté serveur.

Voici les étapes permettant de bien valider les données d'un formulaire avec PHP.

(suite…)

Puisque AJAX est basé sur des technologies existantes qui comportent des vulnérabilités, les appels AJAX sont sujets à ces mêmes vulnérabilités : attaques XSS (Cross Site Scripting), attaques CSRF (Cross Site Request Forgery), injections SQL, etc. Cet article vous présente les protections de base que vous devriez mettre en place dans votre code utilisant AJAX. (suite…)

Les nonces (Number used ONCE, c'est-à-dire numéro utilisé une seule fois) sont un mécanisme permettant de valider l'origine d'une requête HTTP.

Ils permettent d'assurer, avant d'effectuer un traitement, que l'envoi du formulaire ou le clic sur le lien ayant déclenché l'action provient bel et bien de votre site et non d'un script ou d'un lien malicieux.

Ceci permet notamment de prévenir les attaques CSRF (Cross Site Request Forgery) et les attaques par rejeu (replay attack).

Si vous souhaitez mieux comprendre ce qu'est un nonce et quel est son cycle de vie, cet article est pour vous. De plus, je vous fournis ici le code de la classe Cri_Nonce, que j'ai créée pour gérer les nonces.

(suite…)

Le code Google Analytics que vous avez inséré sur vos pages Web est visible pour de tous. Il n'y a qu'à afficher le code source d'une page Web pour qu'il apparaisse en clair.

Ceci n'est pas un problème en tant que tel, sauf si des personnes mal intentionnées décident de s'en servir soit pour brouiller vos données, soit pour vous inciter à aller sur leur site malgré vous, gonflant ainsi leurs statistiques de façon artificielle.

(suite…)

Avez-vous un bon backup des données contenues sur votre ordinateur ? Moi, j'en ai une... et même plusieurs. Malheureusement, ce n'était pas le cas pour mon fils.

(suite…)

Voici une histoire vécue. J'ai développé un site WordPress pour ma mère afin qu'elle y partage ses recherches en éducation ainsi que le récit de ses voyages d'aide humanitaire.  Tout va pour le mieux jusqu'au jour où je reçois un courriel des outils Google pour Webmestre m'indiquant que mon site a probablement été piraté. (suite…)