Vous vous apprêtez à lire un tutoriel rédigé par un membre de ce site. Malgré tout le soin que ce membre a pu apporter au tutoriel, nous ne pouvons pas garantir que les informations contenues sur cette page sont exactes à 100%. Merci de garder cela en tête lorsque vous lirez cette page ;o)
Avoir son propre site internet, c'est super

. Mais si la première personne venue vous gâche votre site à cause d'une (bête ?) faille
XSS...
Les failles de ce type peuvent être très peu dangereuses, ou à l'inverse, mettre toute la sécurité de votre site en jeu !
Il est donc très important de les maîtriser, surtout qu'elles sont très simplement évitables.
Je vous donnerai donc, et nous verrons ensemble, à travers ce tuto, ce sur quoi se base une faille XSS, ce qu'on risque avec, et enfin comment les éviter.
Les failles de types XSS, vous vous demandez sûrement tous, mais qu'est-ce que ça peut donc bien être ? Comment ça marche ? Où est-ce que je risque d'en avoir ?
Pour commencer, il est nécessaire pour comprendre la puissance et le fonctionnement des XSS d'avoir quelques bases en
JavaScript/xHTML , ainsi qu'en
PHP (justes les bases, savoir faire un "Hello World" suffirait, pratiquement

).
Mais qu'est-ce qu'une faille XSS ?
Les failles XSS sont des failles qui utilisent le fait que sur certains codes, on puisse écrire directement dans le code source renvoyé, sans avoir de contraintes !
Et à partir de là découle toute la force des XSS, que nous verrons dans notre deuxième sous-partie.
Pour bien comprendre comment elles fonctionnent, nous allons faire un script PHP simple :
Code : PHP1
2
3
4
5
6 | <?php
if(isset($_GET['texte'])) // On vérifie que la variable $_GET['texte'] existe, c'est-à-dire que la page ait été appelée de cette façon : file.php?texte=valeur
{
echo $_GET['texte'] ;//On affiche la valeur de $_GET['texte'], soit pour file.php?texte=Ajax , on affichera Ajax
}
?>
|
Essayez ce script en écrivant
file.php?texte=Hello world !.
Citation : RésultatHello world !
Avec pour code source :
Code : HTML
Youpi ! On a un beau "Hello world !".
Mais où est le problème ?

Il est très bien, mon "Hello world !", et il ne fait de mal à personne !
C'est sûr... Mais imaginons qu'au lieu de mettre "Hello world !", nous mettions
file.php?texte=<script>alert('XSS')</script>...
Citation : RésultatUne boîte de dialogue s'affiche avec la mention : XSS
Et le code source :
Code : HTML1 | <script>alert('rien')</script>
|
Et c'est là que la XSS prend tout son sens... On peut maintenant afficher n'importe quelle balise html, JavaScript, CSS, etc.
Envoyer cette URL à un ami, il verra la même chose !
C'est bien beau cette boîte de dialogue, mais où est le danger ?
Nous verrons les dangers qu'elles représentent dans la deuxième sous-partie, alors patience ;).
Mais sachez déjà que l'on peut se faire passer pour le navigateur de la victime, que l'on peut faire théoriquement tout ce qu'il pourrait faire sur le site, et que l'on peut aussi récupérer de précieuses informations !
Le fonctionnement des XSS réside dans le fait que le code PHP affiche directement ce qui lui est envoyé, sans rien filtrer.
Ainsi, nous aurions pu écrire
<b>Gras</b>,
ou
<iframe src="http://www.siteduzero.com"></iframe>, etc.
Où est-ce que je risque d'en avoir ?
Le plus souvent, ces failles se trouvent dans les lieux d'affichage d'un pseudo, d'un e-mail, d'une information quelconque que le client fournit, dans les barres de recherche, dans les
shoutbox / livres d'or, dans les forums, dans le titre des pages, dans les systèmes de messagerie, etc.
La liste n'est pas du tout exhaustive, mais ce sont les lieux à vérifier en premier.
La liste des risques provoqués par des failles XSS est longue, et change pour chaque site.
Mais les risques les plus connus, et pas les moindres, restent :
- les redirections vers une page que contrôle l'attaquant :
vous pensez être sur la page officielle, mais vous êtes sur une page de l'attaquant qui ressemble comme deux gouttes d'eau à la page d'origine, sauf que celle-ci récupère le mot de passe que vous tapé...
- les frames :
même résultat que les redirections, sauf que vous voyez dans la barre URL l'adresse du site officiel, et que tout ce qui est autour de la frame est authentique, et donc même si le reste du contenu est mis à jour, la page restera toujours aussi ressemblante ;
- les fausses annonces :
pourquoi ne pas se fier à une annonce faite sur le site qui ressemble, par son aspect et par son emplacement, à toutes les autres ?
- les cookies :
eh oui, généralement le plus intéressant pour un attaquant sera de récupérer les cookies, qui contiennent très souvent le SESSID de la session de l'utilisateur. Avec cela, il pourra faire tout ce que vous faites lorsque vous êtes connectés, comme si c'était vous.
Cette liste n'est bien sûr pas exhaustive, mais vous donne un aperçu de ce que l'on peut faire avec une faille de ce type.
Les résultats sont encore pires lorsque la faille est stockée et affichée sans que l'on ait à la réinjecter. J'entends par là un script qui, se trouvant sur un livre d'or, est exécuté à chaque fois qu'une personne consulte le livre d'or (ceci est un exemple, il peut arriver la même chose dans des commentaires, des articles, etc.).
Ne sous-estimez donc jamais la puissance de ces failles, et faites toujours en sorte de les corriger !
Maintenant que vous vous y connaissez en failles XSS, là où elles risquent de se planquer, il va falloir apprendre à les éviter

.
Il y a plusieurs façons de se protéger des failles XSS. La plus courante, et celle que j'utilise personnellement se résume à un
htmlentities() sur les variables. Simple et efficace.
Pour notre ancien code, cela nous donnerait :
Code : PHP1
2
3
4
5
6
7 | <?php
if(isset($_GET['texte'])) // On vérifie que la variable $_GET['texte'] existe, c'est-à-dire que la page ait été appelée de cette façon : file.php?texte=valeur
{
$texte = htmlentities($_GET['texte']); //On filtre la variable $_GET['texte']
echo $texte ;//On peut maintenant afficher la valeur de la variable sans aucun risque.
}
?>
|
La fonction
htmlentities() remplacera toutes les ouvertures de balises, les apostrophes, etc. par leur valeur "<couleur nom="verte">gentille</couleur>"

( " =>
" , ... ).
Vous pouvez aussi filtrer les requêtes contenant "<" et ">", utiliser la fonction
addslashes() pour empêcher de sortir d'un champ de type texte par exemple, etc. (chacun sa méthode

).
Voici maintenant une liste des erreurs à ne surtout pas faire :
- passer toutes ses variables en POST :
passer vos variables en POST ne changera rien, mis à part le fait que la faille sera moins apparente et non utilisable depuis une URL, mais toujours présente !
- remplacer des <script> et </script> : l'attaquant peut très facilement contourner une protection de ce type, par exemple avec
<scri<script>pt>
- ne pas filtrer les variables qui se trouvent dans un lien :
dans un lien, le script ne sera pas exécuté tout de suite. Mais l'attaquant peut quitter le lien en rajoutant "> devant sa requête (idem pour toutes variables entre " ", comme les src d'images, etc.). En effet, un script contenant une balise dans le style : value="valeur" pourra devenir, suite à une attaque, value=""script ;
- croire qu'on ne peut exécuter du code JavaScript que par l'intermédiaire de balise <script> :
un script de type JavaScript peut très bien être exécuté par l'intermédiaire d'une balise Onclick=javascript, etc. dans une image, ou autre.
Il faut savoir que la plupart des webmestres sous-estiment la puissance des XSS. C'est ainsi que l'on peut (ou l'on pouvait) en trouver sur de gros sites tel que Yahoo, Nasa, Google, et j'en passe et des meilleurs...
Ne les sous-estimez donc jamais, et ce sera ça de moins à vous soucier.
Si néanmoins il subsiste quelques questions, ou si vous voulez être sûrs ou quasiment que votre site n'est pas sujet à ce genre de faille, vous pouvez me contacter en m'envoyant un MP sur le SdZ.
Ajax