Comment sécuriser son site et éviter les failles php ?

Dernière mise à jour le par pijaku .

Comment sécuriser son site et éviter les failles php ?

Introduction

J'initie ce Tutoriel sur le piratage et l'exploitation possible des failles de sécurité de vos sites en PHP, le but étant de rassembler la liste la plus exhaustive possible des problèmes. A ceux qui lisent ce thread dans le but d'apprendre à savoir utiliser les failles de sécurité, passez votre chemin, vous ne trouverez ici aucune information pour vous. (Enfin, cherchez toujours.. ;-)

Je vous invite à ajouter des failles possibles en réponse à ce sujet, j'éditerais le mien, vous pouvez également poser vos questions relatives ici.

Variables a l'air, gaffe aux courrants d'air

Par Juliian

Un script est potentiellement exploitable quand un visiteur lambda peut agir librement sur vos variables, soit quand elles passent par une URL, comme suit : http://www.site.com/admin?login=1.

Pourquoi ?
Même si cela peut sembler évident à la pluspart des codeurs, cette faille de sécurité se retrouve parfois sur le net, voir (et là c'est plus grave) dans des scripts installables sur vos sites. Il faut donc veiller à ce qu'aucune variable sensible ou contrôlant l'accès à une page protégée ne se trouve dans vos URLs.

Comment y remédier ?
L'utilisation des sessions ou des cookies est fortement recommandée dans ce cas. Elle vous évitera d'avoir à trainer une variable "sensible" dans vos URLs, et vos connexions à vos pages protégées se feront de façon transparente.
Suivre les liens "sessions" et "cookies" pour avoir une explication plus étendue.

La redirection ? Pas une solution

Par Juliian

Lorsque vous mettez à la disposition de vos membres un accès privé, ces derniers doivent se connecter. Une personne mal intentionnée peut tout de même accéder à vos espaces protégés si la seule protection est la redirection automatique.

Quels genre de codes sont infectés ?

If ($password != "Pouletgrille")  { print'
Exemple : <meta name="robots" content="index, follow"> '; }

Pourquoi?
Que va il se passer quand le "piratin" va rentrer un mauvais mot de passe ? Il va arriver sur votre page protégée, et va être aussitôt redirigé vers une page d'erreur. C'est là l'erreur : Le visiteur pourra toujours bloquer son navigateur, ou enregistrer votre page, et il verra l'intégralité de votre espace "protégé", et pourra y accomplir ses méfaits.

Comment y remédier ?
C'est simple. Il faut de toute façon que le contenu de votre espace protégé n'apparaisse jamais sur la page de vos visiteurs, même pas une micro-seconde, le moyen le plus simple de réparer ce problème est d'agir comme suit :

If($password != "Pouletgrille")  { Print'Insérez ici le contenu de votre section admin'; } else { print'Erreur de connexion !'; }

La célèbre faille Include()

Par Juliian

Célèbre car très utilisée, la faille include permet au "pirate" de prendre le contrôle entier de votre site. Ajouter, supprimer ou modifier des fichiers, en voir le contenu (password, attention), ou même pire, stocker des programmes malveillants sur votre espace web. Si votre code se présente dans cette configuration, inquiétez vous :

<? include ($page) ?>

Si votre URL est sous la forme suivante : http://www.votresite.com/index.php?page=accueil.php

Pourquoi ?
De cette façon, vous intégrez une page à une autre page, par exemple, via ce lien : http://www.votresite.com/index.php?page=accueil.php.
Cette méthode remplit son rôle, vous avez bien le fichier demandé sur votre page, et les moutons sont bien gardés. Eh bien non ! Les moutons ne sont pas bien gardés. Regardez, il y en a déjà un KO, et les autres vont bientôt se faire attaquer.

Comment ?
Le pirate peut également intégrer ses pages malveillantes (comme cela: http://www.jesuisunpirate.com/script.php,' target='_blank'>http://www.votresite.com/?page=http://www.jesuisunpirate.com/script.php, (PS pour les "pirates", cette méthode ne marche pas, n'essayez même pas. ;-), et comme le PHP est un langage merveilleux, il pourra TOUT faire.

Comment y remédier ?
C'est très simple, et pas très contraignant :

$page=preg_replace("/[^a-z0-9_ ]/i", "", $page);
if(!@include("includes/$page.php"))die("Cette page n'existe pas sur le serveur, merci d'informer le webmaster du site si ce problème venait à se reproduire.");

Si c'est du chinois pour vous, soyez assuré que cette méthode remplira son rôle.

Quelques explications : Ce mini code inclut votre page en enlevant les caractères spéciaux, les "/" (slash) par exemple, et affiche un message d'erreur si votre include échoue. Pourquoi est-ce efficace ? Car le piratin a obligatoirement besoin d'utiliser "/" pour taper "[http://]", il ne pourra donc pas intégrer son script, et se verra renvoyer un message d'erreur. De plus, le code oblige l'extension .php pour vos scripts. Hors, rien n'est possible avec un fichier .php (enfin, pas grand chose, l'exploitation d'une faille XSS tout au plus, je développerais en dessous.)

Update : Pour ceux qui se demandent pourquoi l'utilisation d'un fichier php distant rend impossible l'exécution de codes malveillants, je vais expliquer la situation brièvement. Quand le pirate tentera d'include son script, qui contiendra par exemple une commande pour supprimer votre fichier index.php (à savoir unlink("index.php"), le script s'exécutera dans un premier temps sur son serveur puis, ensuite, sera inclus sur votre page. Ainsi, si son code ne contient que la commande de suppression de la page index.php, cela reviendra à include un fichier vierge, il lui sera simplement impossible d'exécuter un code PHP sur votre serveur..

La faille XSS ? Ça me donne de l'herpès !

Par Juliian

Si vous proposez à vos visiteurs un livre d'or, un forum (Premières versions de phpBB concernées, vérifiez vos mises à jour !) ou un espace où ils peuvent afficher des messages librement sur votre site, cet espace est potentiellement dangereux. Si en entrant ce code dans l'espace où les visiteurs peuvent poster un message, un pop-up s'ouvre, inquiétez vous.

Pourquoi ?
Vous êtes victimes d'une faille XSS. Mais qu'est-ce donc que cette bestiole là ? C'est l'exploitation d'un bug de sécurité permettant à vos visiteurs d'exécuter des scripts javascript, par exemple. Que peut on faire avec ça ? Voler le contenu de vos cookies de connexion (yabon, on va pouvoir se connecter à votre forum sous votre compte, ou à votre site dans la partie administration), ouvrir de la publicité librement sur votre site, rediriger le visiteur par des pages infectées par des virus, que de bonnes choses pleines de fer et de calcium.

Comment y remédier ?
Il y a un grand nombre de solutions pour pallier à ce problème. Definir votre texte comme étant une entité HTML, ou empêcher l'emploi de javascript. Pour se faire, il faut procéder comme suit :

$message=str_replace("javascript:","",$message)

C'est une méthode que je qualifierais de "barbare". Elle supprimera juste le mot javascript des messages postés (et comme il est nécessaire d'ouvrir une balise de type <script="javascript">{code}</script>..).
La méthode la plus sûre et la plus couramment utilisée restant la définition de vos messages comme des entités html :

htmlentities ($message)

La faille cookies ? Que nenni !

Par Juliian

Une faille cookies permet, dans une configuration bien spéciale, d'utiliser un cookie de connexion pour le transformer en celui de quelqu'un d'autre.

Pourquoi ?
Si à la connexion à la section membre, l'individu se logue avec ses identifiants, reçoit donc son petit cookie (et ne le reçoit que si il a entré des identifiants corrects) et voit donc son nom d'utilisateur dans son cookie, et seulement son nom d'utilisateur apparaitre, le script remplit son rôle, vos pages vérifient que le cookie existe, et utilise son nom d'utilisateur pour ses droits d'accès. Mais il y a un problème. L'utilisateur mal intentionné peut tout de même déjouer votre sécurité. Certes, il a bien utilisé des identifiants, il a donc reçu un cookie automatiquement généré, et tout ça, mais une fois qu'il a le cookie ? Il change son nom, et hop hop hop, ni une ni deux, il se retrouve avec votre nom d'utilisateur, et peut faire ce qu'il lui plait.

Comment pallier à ce probleme ?
En stockant le nom d'utilisateur et le mot de passe dans les cookies, ainsi, même si la personne change le nom d'utilisateur, le mot de passe ne conviendra toujours pas.

La faille urldecode() dans les requetes SQL

Par Savory

[En cours de refonte]

La faille require()

par Savory

[En cours de refonte]

Configuration de apache et mod_php

par Juliian

Il serait bien trop long de vous guider pas à pas dans cette manoeuvre. Certains sites développent cette manoeuvre sur des dizaines de pages, la configuration des apache étant quelque chose de très fastidieux, je ne retracerai que les erreurs courantes à ne pas commettre.

Je recommande vivement aux personnes qui n'ont jamais mis le nez dans le fichier de configuration de PHP (php.ini, entre autre) de ne toucher qu'aux paramètres dont ils sont absolument sûrs.

Le paramètre "Safe_Mode"

Le safe_mode doit toujours être activé, il ajoute tout un lot de sécurités non négligeables pour la gestion et le traitement de vos fichiers. Celui-ci intervient principalement dans les droits de lecture, d'écriture et de suppression des fichiers contenus sur votre machine. Il contrôle également la légitimité du manipulateur des fichiers, en vérifiant que le propriétaire du script est également le propriétaire des fichiers manipulés, par exemple.

Le paramètre "Register_Globals"

Ce paramètre joue principalement sur les variables, il permet de contrôler la provenance des variables intervenant sur votre site. Il est extrêmement important de conserver ce paramètre sur off tant que vous ne maîtrisez pas toutes les subtilités de la manipulation de variables. Ce paramètre vous oblige à définir vous même le contenu de vos variables, et empêche les visiteurs de le faire pour vous.

Vérifier la sécurité de son site sans lever le petit doigt

Par Juliian

Cette méthode est très simple, elle se compose de trois étapes, comme suit :

  • Trouver un pirate talentueux et renommé.
  • L'insulter copieusement.
  • Lui donner par inadvertance l'adresse de votre site.
  • Attendre, et regarder le résultat.

Résultat final : Si votre site est encore en vie au bout d'une heure, félicitations ! Votre site est protégé.

Pour finir, n'oubliez pas que les failles de sécurité ne sont pas obligatoirement de votre faute. Elles peuvent se trouver dans les scripts pré-créés que vous installez, et elles sont d'autant plus dangereuses qu'un pirate peut connaitre le code source exact de ces scripts. Vérifiez donc tout ce qui entre dans votre FTP. ;-)

A voir également
Ce document intitulé « Comment sécuriser son site et éviter les failles php ? » issu de CodeS SourceS (codes-sources.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.
Broadcast encryption
Formulaire de recherche
Rejoignez-nous