- Inscription
- 22 Octobre 2011
- Messages
- 14 706
- Réactions
- 8 492
- Points
- 32 425
Voir la pièce jointe 95911Le code PHP & HTML
Salut à tous , vous avez peut-être entendu parler de failles barbares telles que CSRF, XSS, d'injections SQL mais vous aimeriez en apprendre plus sur ces failles mais surtout comment les combler , et bien sachez que vous êtes sur le bon chemin.
Voir la pièce jointe 95912
Commençons si vous le voulez bien, une faille que je qualifierai de classique mais trop répandue malheureusement : la faille XSS (Cross-Site Scripting).
Le principe de cette faille de sécurité est d'injecter du code comme de l'HTML ou du JavaScript sur une page par le biais de champs comme des barres de recherche, un nom d'utilisateur, vraiment n'importe quoi tant que le champs ou le paramètre par lequel la faille est exploitée, affiche la valeur qu'on essaye de modifier pour afficher ce fameux code, prenons un exemple pour que vous compreniez mieux.
PHP:<!DOCTYPE html> <html> <head> <title>Un magnifique site faillible !</title> </head> <body> <h1>Nous aimons la sécurité, soyez en sûr !</h1> <form action method="POST"> <span>Veuillez saisir une recherche:</span> <input style="padding:10px" name="recherche" type="text" placeholder="Entrez votre recherche..."/> </form> <?php if($_POST) { echo $_POST['recherche']; } ?> </body> </html>
Je vais vous expliquer brièvement ce que ce code permet. Dans un premier temps il va générer un formulaire avec un champs qui permettra à un utilisateur potentiel de saisir une recherche (partie HTML ). Dans un deuxième temps lorsque le formulaire aura été soumis, il va afficher ce qui a été rentré tout simplement et bêtement (partie PHP ).
Voir la pièce jointe 95914Il existe plusieurs types de failles XSS que je ne présenterai pas car je ne trouve pas cela particulièrement utile, le but est de corriger ce type de failles.
(nous entrons dans la barre de recherche : "J'entre une recherche tout à fait banale !")
Voir la pièce jointe 95915
(après soumission du formulaire, le texte apparaît bel et bien)
Jusqu'ici tout va pour le mieux, l'utilisateur est un simple internaute. Maintenant, passons du côté obscur de la force et essayons de modifier la page en y insérant du code HTML (avec du CSS ) via le champs de recherche et voyons ce qu'il se passe.
Voir la pièce jointe 95916
(nous entrons dans la barre de recherche du code qui permettrait de modifier la couleur de la page, du body en rouge)
Voir la pièce jointe 95917
Comme vous pouvez le constater le code s'est exécuté, notre page est devenue rouge et ce n'est pas un comportement que l'on souhaiterait. Sachez qu'il est possible d'insérer du JavaScript et donc de voler des cookies très facilement, imaginez qu'un internaute malicieux vole les cookies d'un administrateur, se serait catastrophique .
Voir la pièce jointe 95918
Comme vous pouvez le voir c'est une faille dangereuse et pourtant elle est très présente sur beaucoup de sites. Cette faille n'est dangereuse que si l'élément ayant l'injection, c'est à dire dans notre cas le champs de recherche affiche la valeur qui est saisie par l'utilisateur il faudrait donc trouver un moyen d'afficher cette valeur en toute sécurité, je vous laisse chercher !
Non, je suis gentil et je vais vous mâcher le travail il existe une fonction PHP (comme l'affichage est exécutée par du PHP) appelée htmlspecialchars qui comme l'indiqueVous devez être inscrit pour voir les liens ! Inscrivez-vous ou connectez-vous ici.que je vous indique à consulter régulièrement si vous recherchez une fonction spécifique , convertir les caractères spéciaux (&, ", ', <, >) en entités HTML (leur équivalent : &, ", ',
<, >), ainsi l'injection ne sera plus exécutée par la page, essayons !
La version sécurisée PHP:<!DOCTYPE html> <html> <head> <title>Un magnifique site faillible !</title> </head> <body> <h1>Nous aimons la sécurité, soyez en sûr !</h1> <form action method="POST"> <span>Veuillez saisir une recherche:</span> <input style="padding:10px" name="recherche" type="text" placeholder="Entrez votre recherche..."/> </form> <?php if($_POST) { echo htmlspecialchars($_POST['recherche']); } ?> </body> </html>Voir la pièce jointe 95920
La faille a été corrigée , dorénavant la page est affichée avec les entités HTML .
Vous devez être inscrit pour voir les liens ! Inscrivez-vous ou connectez-vous ici.
Une requête MySQL
Voir la pièce jointe 95922
Nous avons vu la faille XSS, passons à la faille SQL qui d'autant plus dangereuse que la précédente. Cette faille a pour but d'outrepasser (le plus souvent) des espaces de connexion avec diverses techniques variées comme la manipulation des requêtes SQL directement avec des valeurs saisies comme un identifiant et un mot de passe (Vous devez être inscrit pour voir les liens ! Inscrivez-vous ou connectez-vous ici.). Ces failles sont possibles car les valeurs sont directement injectées dans la requête SQL, vous pouvez en voir un exemple ci-dessous.
Code:SELECT * FROM xf_users WHERE username = $_POST['username'] AND password = $_POST['password'];Une requête préparée MySQL
Voir la pièce jointe 95921
Pour combler cette faille problématique est tout aussi dangereuse que la XSS. Nous avons vu précédemment que le problème était dû aux variables implantées directement dans la requête , pour combler ce problème il est recommandé (car il y a d'autres solutions) d'utiliser des requêtes préparées. Ces requêtes permettent de traiter les paramètres d'une différente façon, en effet la requête va être "stockée en mémoire" afin d'être re-utilisée à chaque fois que vous l'utiliserez avec différents paramètres ainsi vous gagnez en performance et vous comblez une faille de sécurité MySQL.
PHP:<?php $bdd = new PDO('mysql:host=127.0.0.1;dbname=', 'user', 'mdp'); $request = $bdd->prepare('SELECT * FROM xf_users WHERE username = ? AND password = ?'); $request->execute(array($_POST['username'], $_POST['password'])); $users = $request->fetchAll();
Cette faille est naturellement corrigée sur le forum.
Voir la pièce jointe 95923
Nous terminerons ce tutoriel par la faille CSRF (Cross-Site Request Forgery) qui a pour principe de faire exécuter à une personne ayant des droits de modération, d'administration une requête qu'il n'a jamais voulu envoyer. Prenons un exemple, imaginons que je sois un internaute du côté obscur de la force et que je veuille bannir un membre de la shoutbox de RealityGaming.
Pourquoi la shoutbox me direz-vous ? Car j'ai eu accès à cet addOn grâce à internet, j'ai analysé le code et je sais qu'il y a une faille au niveau de la fonctionnalité. Cette faille est due au manque de vérification de la méthode HTTP demandée, en effet le bannissement s'effectue via la méthode POST puisque l'on passe par un formulaire qui utilise cette méthode. Dans le code source j'ai vu que toutes les méthodes étaient acceptées , et le plus simple pour faire exécuter une action à un utilisateur sans qu'il le sache est la méthode GET puisqu'elle se transmet facilement par le biais d'un lien (camouflé par un raccourcir d'URL ou autre), ainsi il suffit de passer en URL les paramètres requis dans mon cas ça va être un identifiant de message récupérable via inspecter élément que je vais ajouter à la requête qui permet le bannissement dans mon cas je n'aurai qu'à transmettre cette URL : https://reality-gaming.fr/taigachat/10489955/ban.
Dans le un cas différent, même si l'utilisateur ne connaît pas le code source de mon site il va tout de même chercher à remettre la sécurité en jeu.
Voir la pièce jointe 95924
Nous avons vu il y a quelques instants que la faille était notamment due à un manque de vérification du côté serveur (backend), il faut donc que nous optons pour des vérifications accrues afin de garantir que la requête effectuée par l'utilisateur est bien voulue par celui-ci. Pour se faire je vous recommande d'utiliser des jetons de sécurité et de vérifier la méthode utilisée lorsqu'il s'agit de soumettre, supprimer, modifier des informations .
Chaque utilisateur possèdera un jeton de sécurité stocké en base de données que vous pouvez inclure dans votre formulaire avec un champs caché qui possèdera une propriété "hidden" ce qui le rendra invisible aux yeux de notre utilisateur , ainsi il possèdera en valeur notre jeton et lorsque l'utilisateur soumettra un formulaire nous devrons vérifier si le token de sécurité et bien existant et si il est propre à l'utilisateur courant, de plus nous vérifierons si la méthode utilisée est bien POST.
Pour générer un token de sécurité, libre à vous d'utiliser la méthode que vous souhaitez par exemple XenForo utilise la méthode suivante pour générer un token.
Code:$userId . ',' . XenForo_Application::$time. ',' . sha1(XenForo_Application::$time . $csrfToken); // $userId = l'identifiant du membre // XenForo_Application::$time = le temps actuel en timestamp // sha1(XenForo_Application::$time = il crypte ce temps en sha1 // $csrfToken = un token plus faible
Un formulaire sous le CMS XenForo
Cacher la hiérarchie de vos fichiers
C'est quelque chose que je vois très fréquemment, un utilisateur peut se rendre dans vos dossiers (assets, style, img etc.) et voir la liste de vos fichiers et ce n'est pas un comportement que l'on souhaite.
Pour combler ce comportement, vous pouvez ajouter un fichier index (HTML ou PHP) dans vos dossiers.
Vous pouvez également ajouter un fichier .htaccess avec la ligne suivante : Options -Indexes
Ne jamais faire confiance aux données qui vous sont transmises
En effet, vous auriez peut-être l'envie par exemple de vérifier si l'utilisateur provient d'un site particulier avec le header HTTP : HTTP_REFERER. Mais sachez que tous les headers sont modifiables via des extensions notamment.Toujours vérifier les méthodes utilisées
Il n'y a aucune solution à cela, dites vous que chaque information transmise par le navigateur de l'utilisateur est théoriquement modifiable, vous ne pouvez pas lui faire confiance.
Dans ce tutoriel, je n'ai pas présenté toutes les failles connues car ça reviendrait à écrire un livre. Par exemple il existe une faille permettant d'outrepasser une demande d'authentification par .htaccess si celui-ci accepte toutes les requêtes possibles.
Il faut toujours vérifier la méthode de la requête demandée, c'est réellement une règle d'or.
Ne jamais se sentir en sécurité
Mon dernier conseil est de ne jamais se sentir en sécurité, car en effet cela pourrait-être votre plus grande faille et ce conseil est valable pour tout domaine.
[teams]43[/teams]
Bower GTP
Excellente rédaction !! La faille SQL elle fait mal si t'as une grosse base de donnée, elle est grave répandue sur le net
