Xss et injection sql:XSS

From aldeid
Jump to navigation Jump to search

Cross Site Scripting

Définition

Le site Comment Ca Marche (http://www.commentcamarche.net) définit le XSS comme suit :

Les attaques de type Cross-Site Scripting (noté XSS) sont des attaques visant les sites web affichant dynamiquement du contenu utilisateur sans effectuer de contrôle et d'encodage des informations saisies par les utilisateurs. Les attaques Cross-Site Scripting consistent ainsi à forcer un site web à afficher du code HTML ou des scripts saisis par les utilisateurs. Le code ainsi inclus (le terme « injecté » est habituellement utilisé) dans un site web vulnérable est dit « malicieux ».

Comme nous allons l'étudier, le XSS est un type d'attaque permettant à un attaquant de récupérer du contenu saisi par ses victimes. L'exemple le plus médiatisé est celui du lien envoyé par mail par un attaquant qui se fait passer pour une banque (Phishing). Il existe aussi l'introduction de code malveillant par un attaquant sur un serveur via un forum par exemple.

Exemples

Prenons un exemple simple :

<?php echo("Bienvenue {$_GET['nom']}"); ?>

Ces quelques lignes permettent d'afficher la chaîne "Bienvenue {NOM}" où {NOM} est remplacé par la variable récupérée en GET (via l'URL).

Dans le cadre d'une utilisation normale, l'exemple peut être exploité de la manière suivante : Dans l'URL, entrer l'adresse suivante : http://localhost/xss.php?nom=sebastien

a pour effet d'afficher le contenu suivant :

Si aucune protection n'est active, la chaîne peut être de tout type et donc contenir des portions de code JavaScript. Dans l'URL, entrer l'adresse suivante : http://localhost/xss.php?nom=<script>window.location='http://www.google.com</script>

a pour effet d'afficher le contenu suivant :

Il est donc aisé pour un attaquant d'utiliser un site mal protégé à des fins malveillantes. La longueur d'une chaîne passée en GET dans l'URL étant limitée à 255 caractères, l'attaquant utilisera très probablement un script distant par l'attribut SRC d'un JavaScript (<script src="source_exterieure">). D'où l'appellation Cross Site Scripting, "cross-site" signifant en anglais "entre sites".

Les risques liés au XSS

Vol de session :
Un attaquant peut usurper l'identité d'une personne authentifiée par cookie sur un site de paiement en ligne.
Anti-sites :
Une application du XSS peut être la création d'anti-sites. Par exemple, le portail de Steria n'est pas protégé contre cette faille de sécurité comme on peut le constater :

Liste des résultats de la recherche (recherche par injection dans l'URL de la chaîne "unilog") Liste des résultats de la recherche (recherche par injection dans l'URL de la chaîne " %3Cscript%3Edocument.getElementById('header').innerHTML='%3Cimg%20src=\'http://www.logicacmg.com/img/interface/Unilog-logo-fr.gif\'%20style=\'height:100px\'%3E'%3C/script%3E")

Méthodes de protection

Utlisation de librairies dédiées :

L'utilisation de librairies dédiées (par exemple HTML Purifier, disponible à l'adresse suivante : http://htmlpurifier.org) permet de sécuriser sans surcoût une application Web. Un exemple d'utilisation de HTML Purifier est présenté ci-dessous :

<?php

// Inclusion de la librairie
require_once 'htmlpurifier/library/HTMLPurifier.auto.php';

// Instanciation de la classe HTMLPurifier
$purifier = new HTMLPurifier();

// Assainissement de la variable reçue du formulaire
If(isset($_GET["var"])) {
    $var = $purifier->purify($_GET["var"]);
} else {
    $var = null;
}
?> 

<?php
// Affichage de la variable assainie
if(isset($var)) {
    echo "Variable reçue : ".$var;
}
?>

<form method="GET" action="<?php PHP_SELF ?>">
    <input type="text" name="var" />
</form>

Vérification du format des données saisies :

Il est indispensable de vérifier le format des données saisies dans les formulaires :

  • Appliquer des limitations de longueurs de chaînes
  • Appliquer des contrôles sur les formats attendus (une date doit être au format JJ/MM/AAAA, un montant ne doit pas accepter de caractères alphabétiques, etc.).

Doubles contrôles :

Oublier que le JavaScript seul permet de s'assurer que les données saisies sont correctes car un attaquant peut soit désactiver le JavaScript à partir de son navigateur, soit créer son propre formulaire et rediriger ses données vers l'URL spécifiée dans l'attribut ACTION du formulaire afin d'outrepasser les prétendus contrôles. Garder à l'esprit que le JavaScript s'exécute sur les clients (navigateurs) et non sur le serveur. C'est pourquoi JavaScript est utile pour filtrer les éventuelles erreurs de saisies avant de transmettre les données au serveur, mais que toute transaction sur base de ces données doit faire l'objet d'un contrôle de deuxième niveau côté serveur.





 
Préambule
Injection SQL