Les failles des sites web

failles sites web vulnerabilite site internet crlf xee xss rfi lfi upload
4.9/5 - (62 votes)

Qu’est-ce qu’une faille de sécurité  ?

 

Dans le domaine du web, de la sécurité informatique, une faille (vulnérabilité) de sécurité est une faiblesse du système permettant à un pirate de porter atteinte à l’intégrité du système (modification de l’esthétique, ajout de contenu dissimulé, récupération de données sensibles etc …). Ces failles sont la conséquences de faiblesses au niveau de la conception de l’application et plus précisément dans son développement, une simple erreur de programmation peut permettre l’intrusion d’un attaquant qui peut découler sur une attaque par cloaking ou encore sur un piratage par redirection d’urls. Dans le cas ou vous utiliseriez un CMS comme WordPress, les mises à jour ont leur importance car elles permettent justement de corriger les vulnérabilités connues.

 

 

Quelles sont les failles des sites web ?

L’injection SQL

Cette faille provient généralement des formulaires, le pirate validera une chaîne de caractères qui aura pour but de détourner la requête SQL et donc de la modifier pour récupérer des données en provenance de la base de données comme par exemple les noms d’utilisateur, les mots de passe etc…

L’injection SQL est très répandue depuis toujours, elle peut avoir un effet dramatique sur votre site, en effet, de plus en plus d’attaques par injections permettent de dissimuler du contenu et de dissimuler un site par dessus le votre sans que vous le sachiez, c’est ce que l’on appelle, le piratage par mots clés Japonais.

Il existe plusieurs types d’injection SQL,Blind based, Error based, union based, Stacked queries.

Exemple d’injection SQL :

Imaginons donc un site fait en PHP qui permettrait l’enregistrement d’utilisateur.  Admettons que l’utilisateur Thomas souhaite se connecter via son nom d’utilisateur et son mot de passe qui serait “bonjour” hashé en md5, la requête SQL d’identification pourrait être celle ci :

SELECT uid FROM Users WHERE name = 'Thomas' AND password = 'f02368945726d5fc2a14eb576f7276c0';

 

Maintenant, imaginons que le script permettant l’exécution de cette requête ne vérifie pas les données envoyées par cette requête. L’attaquant pourrait donc remplir le champ utilisateur par :

Thomas';--

 

Et le champ contenant le mot de passe par:

peu importe

 

La requête devient donc :

SELECT uid FROM Users WHERE name = 'Thomas';--' AND password = 'f02368945726d5fc2a14eb576f7276c0';

 

Les “–” (2 tirets du 6) permettent d’indiquer un commentaire et donc de ne pas interpréter la suite du code, on obtient donc la requête suivante :

SELECT uid FROM Users WHERE name = 'Thomas';

 

Le pirate peut donc se connecter sous le compte Thomas avec un mot de passe aléatoire, si Thomas est un administrateur, alors le pirate bénéficiera des droits associés au compte et donc d’accéder à des données personnelles.

Il est aussi possible d’arriver à un même résultat en jouant sur le mot de passe, on pourrait donc rentrer Thomas en nom d’utilisateur et pour le mot de passe, ceci :

' or 1 --

 

L’apostrophe indique la fin de zone du champ censé contenir le mot de passe, le “or 1” demande au script si 1 est vrai, il faut savoir que c’est toujours le cas, les 2 “-” indiquent le début du commentaire et bloquent donc le code censé être interprété dans cette requête. La requête deviendrait donc :

SELECT uid FROM Users WHERE name = 'Thomas' AND password = '' or 1 --';

 

Le script vérifiera si ce que l’utilisateur tape est vrai (True) et le pirate pourra donc se connecter via l’identifiant Thomas.

 

 

L’attaque Brute Force

Cette attaque est utilisée en cryptanalyse et est une des plus simple à exploiter techniquement parlant, elle consiste à trouver un mot de passe, qu’il soit en clair ou hashé afin de pouvoir prendre le contrôle d’un compte administrateur sur un site web, sur un serveur FTP, une base de données, une box internet  etc…

Le brute force consiste avant tout à tester toutes les combinaisons de caractères possibles jusqu’à trouver la bonne, cela peut être assez rapide si le mot de passe est “123456”, quelques secondes pourraient suffire contrairement à un mot de passe du type “Cu44Dd5e5d8d88!!?dd$***e$Rred” qui lui, pourrait ne jamais être trouvé par cette technique, il faudrait plusieurs dizaines d’années à la machine pour trouver une telle combinaison.

L’attaque par brute force est donc souvent combiné à des dictionnaires qui sont des fichiers texte de plusieurs gigaotet de noms, prénoms, mot du dictionnaire etc… ils sont généralement composés d’un mot par ligne, chaque mot sera testés.

Heureusement, il existe des méthodes de protection de l’attaque brute force.

 

 

La faille XSS (Cross-site scripting)

XSS qui correspond à cross-site scripting , c’est une faille de sécurité qui permet d’injecter du contenu dans une page. Pour la petite histoire cette vulnérabilité aurait dû porter le nom CSS mais ce dernier était déjà pris par les feuilles de style qui contiennent du code en cascade (Cascading Style Sheet) qui permet d’agencer les pages web et d’y mettre de la forme.

Pour tester l’existence d’une vulnérabilité XSS il suffit par exemple d’injecter une alerte Javascript dans une formulaire ou une url. Si l’alerte apparaît, alors, la faille est présente et est exploitable.

Mieux comprendre la faille XSS

Se protéger de la faille XSS

Les failles d’inclusion

 

La faille LFI (Local File Inclusion)

La vulnérabilité LFI a pour objectif de lire le contenu des fichiers présent sur le serveur de la victime car l’inclusion se fait sur les fichiers déjà présent sur le serveur contrairement à la vulnérabilité RFI qui elle, permet l’inclusion de fichiers distants. Il est donc possible via cette attaque de lire un fichier .htaccess ou encore le fichier de configuration contenant les accès à la base de données.

 

La faille RFI (Remote File Inclusion)

La vulnérabilité RFI que l’on trouve généralement sur les sites internet permet d’inclure un fichier distant, d’exécuter du code sur le serveur, de voler des données etc … Cette vulnérabilité est présente dans tous les langages scripts (PHP, ASP …), le pirate pourra inclure l’url ciblant un fichier malveillant de façon à ce qu’il soit exécuté par le serveur de la victime.

Par exemple :

if (isset($_GET['NAME'])) {
    $name= $_GET['NAME'];
}
include($name. '.php');

 

Et voici la vulnérabilité, le fichier à inclure dépend uniquement du contenu de la requête GET qui est donc manipulable directement par l’url, ce qui peut aussi permettre d’en savoir plus sur l’arborescence du serveur.

La faille Upload

La faille upload permet comme son nom l’indique d’envoyer  des fichiers avec une extension non autorisée sur le serveur ciblé, il est donc possible à l’attaquant d’uploader un fichier .PHP et de l’appeler de façon à ce qu’il soit exécuté sur le serveur. Dans le cas ou le pirate upload un shell, il peut donc aisément prendre le contrôle du serveur grâce à une interface graphique qui permet d’upload, de supprimer, de modifier les fichiers en quelques clics.

 

Comment se protéger d’une faille upload

Il suffit de contrôler les informations rentrées par l’utilisateur, dans le cas d’un formulaire qui permettrait d’envoyer des photos, il faut être certains que les extensions des fichiers qui sont envoyés soient en JPEG, PNG etc…, voici un exemple de code en PHP qui permet de vérifier l’extension du fichier.

 

if(preg_match("#jpeg|png#",$_FILES["image"]["type"])){
     echo "fichier envoyé !"; 
}else{ 
     echo "Fichier non valide.";
}

 

Il est aussi important de vérifier les droits de lecture / écriture (CHMOD) de vos fichiers sur le serveur pour éviter à un utilisateur d’accéder à certains fichiers / répertoires.

La faille XEE (XML External Entity)

L’attaque XEE permet par exemple la divulgation de données sensibles, une attaque par déni de service et … voici un exemple de vulnérabilité XEE :

 

<!ENTITY origin SYSTEM "file:///user/joe">

 

Lorsque l’entité sera référencé, elle affichera donc le contenu du fichier /user/Joe. Le pirate peut donc placer cela dans le XML de façon à pouvoir accéder à du contenu pour lequel il n’est normalement pas autorisé.

 

La vulnérabilité XEE en détails :

La faille Full Path Disclosure (F.D.P )

La faille Full Path Disclosure est la révélation du chemin d’un script sur un serveur.  Cela consiste à provoquer un bug de façon à afficher un message d’erreur qui donnerait un chemin et donc des détails sur l’arborescence du serveur. La révélation d’un chemin peut donc permettre la récupération de fichiers contenant des données sensibles comme les fichiers de configuration de base de données etc …

 

 

La faille Carriage Return Line Feed (CRLF)

CR et LF sont des caractères spéciaux (ASCII 13 et 10 respectivement, aussi appelés \ r \ n) qui sont utilisés pour signifier la fin de ligne. CRLF est utilisée dans les systèmes d’exploitation comme Windows. Dans un premier cas, le pirate modifie les entrées du fichier journal ce qui peut être utilisé pour masquer des attaques, l’injection CRLF est aussi utilisée pour ajouter des en-têtes HTTp à la réponse HTTP.

Le meilleur moyen de détecter cette faille est d’utiliser des scanners de vulnérabilités web, il est aussi possible d’y parvenir manuellement mais cela prendrait beaucoup plus de temps.

 

Se protéger de la vulnérabilité CRLF

Une des choses à faire est de supprimer les caracères de nouvelles ligne avant de transmettre le contenu ans une en-tête HTTP. Il est aussi possible d’encoder les données avant de les transmettre dans les en-têtes HTTP

Comment détecter une faille CRLF