Les failles web: identification et protection

C’est quoi une faille :

Une faille c’est en fait une faiblesse dans un code qui peut être exploitée pour détourner un site de sa fonction première. Le pirate va pouvoir récupérer des données confidentielles (comme les infos personnelles des inscrits) ou modifier le comportement du site.

La faille XSS

Explications

XSS (plus officiellement appelée Cross-Site Scripting) est une faille permettant l’injection de code HTML ou JavaScript dans des variables mal protégées. Il existe en fait deux types de XSS :

Le XSS réfléchi (non permanent)

Cette faille est la plus simple des deux. Elle est appelée non permanente car elle n’est pas enregistrée dans un fichier ou dans une base de données. Elle est donc éphémère.

Le XSS stocké (permanent)

La faille permanente est la faille XSS la plus sérieuse car le script est sauvegardé dans un fichier ou une base de données. Il sera donc affiché à chaque ouverture du site.

Comment s’en protéger

La solution la plus adaptée contre cette faille est d’utiliser la fonction htmlspecialchars() . Cette fonction permet de filtrer les symboles du type <, & ou encore « , en les remplaçant par leur équivalent en HTML.

La faille include

Explications

La faille include est également très dangereuse. Comme son nom l’indique, elle exploite une mauvaise utilisation de la fonction include() . Cette fonction est très souvent utilisée pour exécuter du code PHP se situant dans une autre page, et particulièrement pour la connexion à une base de données.

Comment s’en protéger

Cette faille est déjà plus complexe à protéger, dans la mesure où on ne peut pas complètement interdire l’inclusion sur le site (car sinon on ne pourra pas inclure nos propres fichiers). Il faut donc savoir au préalable ce que l’on veut inclure, rédiger un htaccess qui veille sur les fichiers importants.

La faille upload

Explication

La faille upload est une des failles les plus dangereuses. Vous connaissez sûrement la balise HTML qui permet l’upload de fichier :

<input type= »file » />

Cette balise est utilisée sur de nombreux sites qui proposent à leurs utilisateurs d’avoir une photo de profil ou d’inclure une image dans un message sur le forum. Le problème, c’est que la balise upload permet d’uploader n’importe quel fichier. Un utilisateur malintentionné pourrait sans problème s’amuser à uploader un fichier PHP malveillant (web shell par exemple) qui lui permettrait de prendre le contrôle total de votre site, et même par rebond, de prendre la main sur le serveur en backoffice !.

Comment s’en protéger

Bon tout d’abord, sachez qu’il est très difficile de créer un filtre complètement fiable. Mais nous allons tout de même créer un fichier bien solide, auquel même hacker vaillant n’oserait pas s’attaquer.

Tout d’abord, j’aimerai porter à votre attention cet article (un peu vieux, certes) qui résume parfaitement les grands points à considérer pour mettre en place un script d’upload sécurisé. Pour ceux qui ne seraient pas familiers avec la langue de Shakespeare, voilà un petit résumé :

 

Les 8 règles basiques pour implémenter un système d’upload sécurisé

  1. Renommez le fichier
  2. N’enregistrez pas vos fichiers à la racine de votre site
  3. Vérifiez la taille du fichier
  4. Ne vous fiez pas aux extensions
  5. Effectuez un scan anti-malware
  6. Gardez le contrôle des permissions (CHMOD)
  7. N’autorisez l’upload qu’aux utilisateurs inscrits et authentifiés
  8. Limitez le nombre de fichiers qu’un utilisateurs peux mettre en ligne

L’injection SQL

Explication

Pour cette partie,  je travaillerai uniquement en PDO. Bien que les autres méthodes soit encore utilisables, elles sont à ce jour obsolètes.

L’injection SQL est une méthode d’attaque très connue. C’est un vecteur d’attaque extrêmement puissant quand il est bien exploité. Il consiste à modifier une requête SQL en injectant des morceaux de code non filtrés, généralement par le biais d’un formulaire.

Comment s’en protéger

Comme vous avez pu le remarquer, les injections SQL bien utilisées peuvent être redoutables ! Mais heureusement pour nous, il est très simple de s’en protéger (surtout avec PDO). Il suffit d’utiliser des requêtes préparées. Notre requête devient donc :

<?php

// On récupère les variables envoyées par le formulaire

$login = $_POST[‘login’];

$password = $_POST[‘password’];

// Connexion à la BDD en PDO

try { $bdd = new PDO(‘mysql:host=localhost;dbname=bdd’,’root’, »); }

catch (Exeption $e) { die(‘Erreur : ‘ .$e->getMessage())  or die(print_r($bdd->errorInfo())); }

// Requête SQL sécurisée

$req = $bdd->prepare(« SELECT * FROM utilisateurs WHERE login= ? AND password= ? »);

$req->execute(array($login, $password));

?>

La CSRF

Explication

La faille CSRF (« Cross site request forgery ») est très souvent assimilée à la XSS alors que ces deux failles sont diamétralement opposées. Quand la XSS cherche à dérober des informations personnelles de l’utilisateur, la CSRF cherche à lui faire exécuter des actions à son insu directement sur son ordinateur. Dans la première partie, on a vu comment le pirate utilisait la XSS pour voler les cookies de l’administrateur, pour pouvoir prendre le contrôle du site. Si le hacker décidait d’utiliser la CSRF, il ferait exécuter l’action directement sur l’ordinateur de la victime.

Comment s’en protéger

Authentification pat jeton (token)

Comme je l’ai dit précédemment, il n’existe malheureusement pas de protection parfaite contre la CSRF. La façon la plus rependue étant l’utilisation d’un jeton unique qui sera vérifié à chaque modification. Beaucoup d’internautes préconisent d’utiliser la fonction uniqid(), mais c’est en fait une erreur. Elle génère un identifiant unique basé sur le temps en microsecondes, et contrairement à ce que l’on pourrait penser, sa valeur n’est pas impossible à deviner. Il est donc, à mon gout, plus sécurisé d’utiliser ceci :

<?php $token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM)); ?>

Demande de confirmation

Bon pour cette technique pas besoin d’épiloguer. Il s’agit simplement de demander à l’administrateur de confirmer l’action avec un pop-up de confirmation ou même mieux, une confirmation par mot de passe. Ainsi, on réduit encore plus le risque de suppression involontaire.

Un petit captcha

Une autre technique consiste à demander à l’administrateur de valider l’action en remplissant un captcha. C’est tout bête et très efficace, mais pas très adapté si l’action est répétitive…

La CRLF

Explication

La faille CRLF (Carriage Return Line Feed) permet – comme son nom l’indique – d’effectuer un retour chariot dans un champ du type input ou textarea. Elle est le plus souvent utilisée pour récupérer le mot de passe de quelqu’un, grâce à la fonction mail() de la page « mot de passe oublié » présent sur un très grand nombre de sites. Il nous suffit de connaitre l’adresse mail de la victime et d’utiliser la faille pour nous mettre en copie de ce mail.

Comment s’en protéger

Pas de grande surprise pour cette partie, le moyen le plus efficace pour s’en protéger est tout bonnement de supprimer les retours à la ligne lors du traitement

<?php

// On récupère la valeur du input

$chaine_utilisateur = $_POST[‘mail’];

// On supprime les retour à la ligne

$chaine_secure = str_replace(array(« \n », »\r »,PHP_EOL), »,$chaine_utilisateur);

?>

Vous pouvez également vérifier que la chaine de caractères entrée par l’utilisateur est bien une adresse mail. Utilisez par exemple un filtre

<?php

$email = $_POST[‘mail’];

if(filter_var($email, FILTER_VALIDATE_EMAIL)){

    // Valide

}

else {

    // Non valide

}

?>

L’attaque par force brute

Cette partie est une peu différente des autres dans la mesure où nous apprendrons à nous protéger contre les attaques par force brute (plus couramment appelées « bruteforce »). Le but n’est donc pas de se protéger contre une faille, mais de rendre ce type d’attaque inefficace.

Comment s’en protéger

  • Le bannissement d’IP
  • La vérification par captcha

Laisser un commentaire

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