6 étapes indispensables pour sécuriser votre site web

Clem's Web http://theclemsweb.free.fr/

La sécurité des sites web c’est un peu comme la sécurité de nos données : tant qu’on n’a pas perdu toutes ses photos sur le disque dur, on s’en fout un peu ! Il est communément admis qu’un informaticien obtient ses lettres de noblesses le jour où il a perdu toutes ses données (et qu’il a survécu :D)…

Nous nous sommes récemment lancé dans l’aventure « Je n’ai jamais », la fleur au fusil, assez sûr de nous. Nous avons mis en place un certain nombre de protections connues. Et lorsque l’on a diffusé l’adresse auprès de nos camarades, ils se sont fait un malin plaisir à trouver la moindre faille. C’est ce que nous leur avions demandé ! Mais ça fait toujours quelque chose d’avoir un mail d’un ami qui vous montre qu’il a eu accès à la moitié de votre code, qu’il a réussi à voler votre session admin et qu’il détient une ébauche de la structure de la base de données.

Je vais essayer ici de résumer quelques pratiques importantes. N’étant pas un expert de la sécurité, je ne présente ici que les bases… Libre à tous de commenter, et d’ajouter des précisions.

Etape n°1 : Les fichiers temporaires

Certains éditeurs génèrent des fichiers temporaires de la forme « fichier.php~ ». De base, lorsqu’un internaute demande une page PHP (via l’URL), celle-ci est « traduite » par le serveur en code HTML. Il est donc impossible de voir le code PHP, qui recèle des informations parfois capitales. Cependant, si malencontreusement, vous avez uploadé un fichier temporaire, l’utilisateur pourra y accéder via l’URL et celui-ci ne sera pas traduit. Il aura donc accès au code source PHP. Pensez à tous les supprimer.

Etape n°2 : Listing de dossiers

En général, de base, si vous entrez l’URL d’un dossier, le serveur web vous donne la liste des fichiers présents dans ce dossier. Ceci peut-être très dangereux car on a potentiellement accès aux noms de vos fichiers, à leur type, à leur emplacement. Pour empêcher le listing des dossiers, il faut créer un fichier « .htaccess » et le placer à la racine de chaque dossier. Dans ce fichier, placez simplement la ligne « OptionsIndexes ».

Etape n°3 : Dévoiler vos structures et protections

D’une manière générale, il faut essayer de ne pas dévoiler l’architecture du site, la version du serveur ou encore les mécanismes de protection. Je me le permets ici car ceux-ci sont des mécanismes de base, que tous les spécialistes connaissent bien.

Etape n°4 : Eviter les injections SQL

Le principe est très simple. Vous demandez dans un formulaire le nom de l’utilisateur. Ensuite vous avez un script qui écrit gentiment l’information dans la base de données. Le problème, c’est que si vous ne vérifiez pas la structure du champ, vous pouvez vous retrouvez avec un nom d’utilisateur du type  » ‘ or 1=1″. Ainsi, lorsque vous ajoutez le champ à la requête SQL, le guillemet simple ferme une éventuelle condition et ajoute une condition toujours vraie. L’internaute obtient donc potentiellement un résultat différent de ce que vous avez programmé. La commande PHP mysql_real_escape_string peut vous aider à vous protéger des données entrées par les utilisateurs.

Etape n°5 : Colmatez des failles XSS

Une faille XSS existe lorsque vous ne vérifiez pas le format des paramètres passés dans votre URL. Ainsi, l’utilisateur va pouvoir être en mesure de passer des scripts en paramètres, et les exécuter sur la page. Par exemple, un paramètre id de votre url pourrait être transformé en : www.siebmanb.com?id=%3Cscript%3Ealert%281%29%3C/script%3E. Ici, l’accès à la page provoquera l’affichage d’une alerte javascript. Mais les scripts peuvent être plus dangereux. Pour se protéger, il faut au moins utiliser la fonction PHP htmlentities (et ses paramètres).

Etape n°6 : Ne pas barricader la porte si la fenêtre est ouverte

Protéger son site web, c’est bien. Mais si on peut deviner votre mot de passe de messagerie par simple social engineering ça ne sert à rien. Le social engineering, c’est l’art d’utiliser les failles inhérentes à l’être humain. Dans notre cas, si votre mot de passe correspond à votre date de naissance ou le nom de votre chien, ce sera facile. C’est encore plus facile si dans votre messagerie, vous avez choisi une « Question » vous permettant de récupérer votre mot de passe… Une question trop simple, et votre blog/Facebook trop précis sur votre vie, et il est facile de récupérer votre mot de passe. Donc assurez vous que vous êtes couvert, de tous les côtés :D. Il faut être un peu parano, mais ça aide quelques fois.

Voilà. Je pense pas avoir dit d’énormes bêtises. Sinon, je vous fais confiance pour rectifier la vérité ! Merci à Clément et Luc pour les conseils.

Illustration Illustration

2 réponses à “6 étapes indispensables pour sécuriser votre site web”

  1. Nhat Minh dit :

    #1, #2 et #3 relèvent de la sécurité par l’obscurité[1], qui peut se défendre, mais qui n’est pas non plus indispensable (c’est débattu), et parfois tout simplement incompatible avec ce que l’on fait (p.ex. de l’OpenSource). Mon avis personnel sur la question est que c’est bien d’OpenSourcer son code (même de site/app Web), à moins qu’il y ait derrière des algorithmes confidentiels à haute valeur ajoutée (p.ex. un algo de recherche révolutionnaire). Mais c’est mon avis.

    #4 et #5 relèvent de la même famille de failles, à savoir des bugs soit d’inattention (mais ça peut faire mal…), soit de conception (là, faut se poser des questions) qui permettent à l’utilisateur d’injecter du code. On n’est jamais à l’abri, mais utiliser les bibliothèques et frameworks modernes aide grandement. Les fonctions mysql_* sont obsolètes depuis quelques années déjà. Tu devrais utiliser/conseiller PDO[2], et l’usage des requêtes préparées lorsque cela est possible.

    Le point #6 à mon avis est très important et souvent oublié.

    Dernière chose, à propos de #1, le fait que tu aies des fichiers temporaires sur le site en production ne présage rien de bon ; tu devrais avoir une version de développement d’un côté, avec un script d’installation qui permette de déployer/mettre à jour la version de production. D’une part, cela permet de faire des tests sur des versions de pré-prod (en déployant un faux site), d’autre part, ça évite ce genre de désagrément, ou les fameux « oups, erreur de syntaxe PHP sur mon site en prod » qui ne font pas très pro…

    [1] http://en.wikipedia.org/wiki/Security_through_obscurity
    [2] http://php.net/pdo

  2. Siebmanb dit :

    Très bonnes remarques… Tout est dit je pense. Je n’ai conseillé que ce que je connaissais. Je ne connais pas (encore) PDO mais tu as bien fait d’en parler.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *