Encore aujourd’hui, j’ai lu des choses aberrantes sur la sécurité des applications Web.

En effet il est courant d’entendre «mon site est https donc sécurisé». Faux, cela signifie seulement que le transit des données est lui sécurisé, crypté sur le réseau si vous préférez. Mais cela ne vous met strictement pas à l’abri d’autres failles de sécurité!

Je vais essayer de vous présenter, simplement, les 3 failles les plus courantes que l’on rencontre :

  • le XSS ou Cross Site Scripting
  • le CSRF ou Cross Site Request Forgery
  • et la bien connue Injection SQL

Le XSS ou Cross Site Scripting

C’est la faille la plus courante. Son fonctionnement est simple et repose sur des failles contre les entrées des utilisateurs. Je suis sur un forum ou un guestbook. Si mon commentaire n’est pas du tout filtré alors je peux faire exécuter du code arbitraire.

Si dans mon formulaire de forum, par exemple, je venais saisir <script>alert(’un script arbitraire’)</script>.

Alors le prochain visiteur de la page du forum aurait le droit à une belle petite fenêtre d’alerte Javascript lui expliquant que l’on vient d’exécuter du code sur sa machine sans qu’il le sache. Hé oui, Javascript c’est du coté client !!! Maintenant, il suffit de connaître un peu JS pour être capable d’imaginer ce que l’on peut faire avec ce genre de faille.

En fait on peut considérer qu’il existe 2 types de ces failles :

  • La première locale permettrait par exemple de faire afficher des champs d’un formulaire auquel je ne suis pas supposé avoir accès;
  • La seconde, elle reprend l’exemple donné au dessus. Si cette faille est enregistrée en base de données, alors tous les visiteurs sont susceptibles d’être affectés par ce code malicieux. On peut aussi être confronté à ce genre de problème avec des moteurs de recherche qui auraient stocké ce genre d’url.

Les risques

Ce genre de faille permet à l’attaquant de faire à peu près n’importe quoi que Javascript ou HTML seraient capable de faire :

  • Afficher un contenu non autorisé sur la page
  • Voler des informations de cookie ou de session (du calme, maintenant la plupart des banques ne se basent plus que sur ça pour donner accès à votre compte);
  • Rediriger l’internaute sur une autre page à son insu (voir le CSRF !);
  • Voir un plantage simple et pur du navigateur par l’ouverture en boucle de popup.

Le CSRF ou Cross Site Request Forgery

Pour que le XSS fonctionne, il faut que l’on amène à vous rendre sur la bonne page avec les bons paramètres. Avec un minimum de bon sens, on peut éviter cela. Le CSRF est lui par contre plus vicieux.

Le principe général est d’exploiter à partir d’un site piégé le fait que vous êtes connecté sur un autre site pour effectuer des choses sur ce site à votre place. OK, pas très simple à comprendre la de suite.

Un exemple

Je suis connecté sur mon webmail car j’attends un mail de ma blonde, pendant ce temps, M. X que je connais à peine m’envoie un lien en disant que ce site est super. Bien évidemment ma curiosité piquée, je clique sur le lien. Mais voilà, ce site est en fait un piège. Celui va profiter du fait que je suis connecté (ou plutôt mon navigateur) sur mon webmail pour envoyer une requête correspondant à un envoi de mail de rupture à ma blonde. Hummm je viens de me faire usurper mon identité là.

Les risques

Et bien d’abord et avant tout l’usurpation d’identité, mais cela peut aussi être la préparation d’une attaque plus concrète, comme par exemple la re-configuration de votre routeur via son interface Web d’administration.

L’injection SQL

Cette faille est aussi très commune malheureusement. Elle vient exploiter des faiblesses dans la programmation d’une application. Par exemple, un formulaire de connexion de type:

[code="html"]

[/code]

On s’authentifie sur cette page, et en général admin.php fait une requête qui ressemble à

[code="php"]SELECT id FROM users WHERE user='.$_POST['user'].' AND passwd='.$_POST['pass'];[/code]

Jusque là tout va très bien, maintenant il se passe quoi si dans mon champs user je saisis quelque chose du genre qui amène admin.php à faire :

[code="php"]SELECT id FROM users WHERE user = ’nimporte_quoi’ AND passwd = ’1' or '1'='1’ ;[/code]

Et bien comme cette requête est toujours vrai (1=1) alors le résultat va être le premier utilisateur de la base de données. ET donc je suis connecté avec cet utilisateur !

Maintenant encore mieux, si je connais un nom d’utilisateur administrateur, et si admin.php fait :

[code="php"]SELECT id FROM users WHERE user = ’monAdmin'; -- ’ AND passwd = 'on se fout du passwd'' ;[/code]

Et bien cette fois, grâce au – la vérification du mot de passe est commentée, et donc je viens d’avoir un accès ADMINISTRATEUR !

Heu avec tout ça que faire ?

Commençons par faire preuve de bon sens, et arrêtons de cliquer sur tous les liens qui passent !!

Votre ami MSN qui ne vous parle jamais vous envois un lien avec de superbes photos de vous … allons c’est un site piégé !

Et bien évidemment, que ça soit sur votre webmail ou bien sur votre site bancaire, ne restez connecté que le temps nécessaire et assurez vous d’être bien déconnecté.

Messieurs les développeurs, faites preuve de rigueur … et arettons de croire que HTTPS veut dire à l’abri des failles de sécurité !