C'est avec grand plaisir que je laisse pour une fois la parole à quelqu'un d'autre ! Germain va vous parler d'un sujet que je ne connais que pas assez, et qui pourtant se révèle très important lors de la conception d'une application (riche ou non !) : la sécurité. Je remercie donc Germain pour sa participation et vous souhaite bonne lecture.
Introduction
La sécu 2.0
Bonjour à tous ! Je m'appelle Germain BAUVIN, je suis consultant en sécurité Informatique chez Apogée communications (groupe Devoteam), et j'ai eu l'opportunité de travailler de nombreuse fois avec Fabien, l’auteur émérite de ce blog, pendant nos études communes à EPITA.
Depuis plusieurs mois que je le lis ce blog, je me dis qu'il pourrait être intéressant de faire un article de sensibilisation sur le sujet de la sécurité des applications Web.
Le but de cet article est donc de vous présenter les 3 principales failles qui touchent les applications Web : les injections SQL, le cross site scripting (XSS) et le cross site request forgery (CSRF, prononcé C-surf).
La fin d'une idée fausse
Tout d'abord je voudrais tordre le cou à une idée reçue complètement fausse. Il m'est arrivé d'entendre des concepteurs de site web me dire : "De toute façon, mon site est en HTTPS, donc il est sécurisé.". Il faut savoir que le https n'est qu'une version chiffrée de HTTP, c'est à dire qui ne protège que la confidentialité des données. Mais si l'application en elle-même n'est pas sécurisée, le chiffrement ne sert à rien. Il faut penser la sécurité dès la conception d'une application, qu'elle soit en statique avec un soupçon d’AJAX, en PHP/MySQL ou une RIA complète. Tenez vous le pour dit =).
Injection SQL
C’est d’après moi le type de failles des applications web la plus simple à exploiter et qui permet de faire le plus de choses. Heureusement, il est aussi extrêmement simple de s’en protéger.
Présentation
Prenons un exemple simple. Imaginons que vous possédez un blog. Pour vous connecter sur la page d'administration, vous remplissez un simple formulaire avec un identifiant et mot de passe. En HTML ça donne quelque chose comme ça :
<form method="post" action="http://example.net/blog/admin.php">
<input name="user" type="text" id="user">
<input name="pass" type="password" id="pass">
</form>
Vous vous authentifiez donc sur la page. Le formulaire envoie ensuite les données à admin.php, qui fait une requête SQL qui ressemble à ça :
SELECT id FROM logins WHERE username = ’$user’ AND password = ’$pass’ ;
L'essence de l'injection SQL consiste à entrer certains caractères spéciaux dans les champs du formulaire. Typiquement, ici, si vous remplissez le champ de mot de passe avec la séquence 1’ or ’1’=’1 et le champ utilisateur avec n'importe quoi, la requête SQL devient :
SELECT id FROM logins WHERE username = ’nimporte_quoi’ AND password = ’1' or '1'='1’ ;
Cette requête est toujours vraie, et elle retournera le premier champ de la table logins. Résultat, vous êtes authentifié sur le site, sans connaître de login utilisateur ou de mot de passe. Pas bête hein ?
Mais encore plus fort, si vous connaissez un nom d’utilisateur (au hasard : admin), il suffit de rentrer la chaîne admin' ; -- dans le champ qui va bien, de remplir le champ de mot de passe par ce que vous voulez pour que ça donne :
SELECT id FROM logins WHERE username = ’admin'; -- ’ AND password = 'loutre' ;
Que se passe-t-il ? La vérification du mot de passe se retrouve commentée (à cause du – qui commente la fin de la ligne), vous voilà connecté en tant qu'admin.
Risques
Au-delà d’usurper l’identité d’un utilisateur, quelles sont les limites d'une telle faille ? Et bien, tout dépend de la base de données utilisée. Mais pour simplifier, un internaute mal intentionné tombant sur ce genre de faille peut faire ce qu'il veut de votre contenu, se faire passer pour vous, créer des comptes, pendre le contrôle du serveur sur lequel est hébergé votre site... Et ce ne sont que quelques exemples.
Il existe de nombreuses façons de se protéger contre ce genre de faille et ses conséquences. Je ne vous les présenterai pas ici, mais google est votre ami.
Cross Site Scripting (XSS)
Alors, je sens venir la question : pourquoi X pour Cross dans l’acronyme de ce genre de faille ? Tout simplement pour ne pas être confondu avec les feuilles de style CSS.
Ce point étant éclairci, entrons dans le vif du sujet.
Présentation
La base d'une attaque exploitant une faille XSS, c’est de pouvoir injecter des données arbitraires dans un site web. Un attaquant peut par exemple poster un commentaire sur un blog, écrire un message dans un livre d’or ou encore modifier des paramètres directement dans une URL. Si ces données arrivent telles quelles dans la page web transmise au navigateur (par les paramètres d'URL, un message posté, etc.) sans avoir été vérifiées et assainies, alors il existe une faille : on peut s'en servir pour faire exécuter du code malveillant via un langage de script (du JavaScript le plus souvent).
Prenons le cas d'une page d'aide qui affiche le message passé en paramètre dans une page html :
Si au lieu de bonjour à tous on entrait un script JavaScript comme <script>alert('bonjour')</script> (qui provoque l'affichage d'une boîte de dialogue), ça donne :
On distingue trois types de failles XSS :
– Type 0 (local) : Ce cas arrive quand un script JavaScript écrit à la volée une partie de la page avec des paramètres utilisateurs non vérifiés. Cela permet par exemple d’afficher des entrées de formulaires qui ne devraient pas apparaître en temps normal. C’est ce qui arrive lorsqu’on ne vérifie pas que l'utilisateur a le droit d'effectuer telle ou telle action sous prétexte qu'on ne lui propose pas.
– Type 1 (non permanent) : Ce cas arrive quand l’entrée utilisateur est affichée telle quelle sur le site. Cela peut arriver par exemple quand un moteur de recherche affiche la requête. Si on peut faire suivre un lien spécial à une victime, on peut voler son cookie de session par exemple. (C'est le type de l'exemple ci-dessus)
– Type 2 (persistant) : Ce cas arrive quand le serveur enregistre dans un fichier ou une base de données l’entrée utilisateur sans la vérifier, donc le code injecté est visible par tous les visiteurs.
Risques
Ce genre de faille peut permettre à un attaquant de faire à peu près tout ce que peut faire un script ou du HTML, comme par exemple :
- Afficher un contenu non interne au site (publicité, faux article)
- Rediriger l'utilisateur vers un site frauduleux (parfois même de manière transparente).
- Voler des informations comme une session ou un cookie.
- Actions sur le site faillible, à l'insu de la victime et sous son identité (envoi de messages, suppression de données, etc.)
- plantage de la page (boucle infinie de pop-up par exemple), et souvent du navigateur.
Exemples
Les erreurs HTML 404 (Page not found) et 403 (Unauthorized) des sites reprennent souvent l'url demandée dans le texte de la page. Sans les protections adéquates, ces pages sont vulnérables. Google par exemple à été victime d'une telle faille. La technique consistait à jouer sur l'encodage de la page pour contourner certains mécanismes de défenses. Pour plus d'information, vous pouvez lire cet article (en anglais).
Cross Site Request Forgery (CSRF)
Un nom bien barbare mais qui ,contrairement aux XSS, exprime bien l’idée de la faille. Suivez le guide…
Principe
Pour qu'un pirate profite d'une faille XSS, il doit amener l'utilisateur à se rendre sur le site compromis avec les bons paramètres ou sur la bonne page. Dans le cas d'une vulnérabilité de type Cross Site Request Forgery, l'attaque est bien plus fourbe.
L'idée générale consiste à utiliser un site tiers. Imaginons le cas suivant : John est connecté sur son webmail préféré, authentifié par un cookie. Tout en laissant sa boite de réception ouverte (il attend un mail de sa petite amie Julie), il surfe à droite à gauche. De son côté, Robert, pirate à ses heures et jaloux du couple, envoie un lien vers un site piégé à John. Celui-ci, naïf, clique joyeusement sur le lien. Et c'est là que les choses sérieuses commencent.
Le site piégé profite du fait que John (ou tout du moins son navigateur) est authentifié sur le site de mail et fait une requête correspondant à un envoi de mail de rupture à Julie... Une superbe démonstration d'usurpation d'identité.
Un autre exemple ? Remplacez "webmail" par "banque en ligne" et "envoi de mail" par "virement". Et le tour est joué.
Risques
Maintenant que vous connaissez le principe imaginez :
- Tout ce que vous pouvez faire en usurpant une identité (banque, diffamation, ...)
- Du vol d'informations (voir le cas de google ci après)
- Préparation d'une attaque plus lourde (en modifiant la configuration de votre routeur par exemple)
- Imprimer des pages de test sur l'imprimante du bureau (ce qui, fait en boucle, peut être assez immobilisant)
Exemples
Google, via son service Gmail, a été touché pendant le mois de septembre par de nombreuse failles appelées 0-Day (c'est à dire rapidement corrigées et exploitables sur une très petite fenêtre de temps), dont certaines exploitaient des CSRF. Une simple visite sur un site tout en étant logué dans Gmail permettait de récupérer la liste de vos contacts ou d'ajouter un filtre, pour faire suivre tout votre courrier vers la boite mail du pirate par exemple.
Quelques conseils en vrac
J’aimerais finir cet article par quelques conseils :
- HTTPS ne veut pas dire « site sécurisé » ;
- Si vous utilisez des programmes "prets-à-l'emploi" (blog, wiki, CMS) gardez un oeil sur les mises à jour. Cela vous évitera de mauvaises surprises ;
- Si on a vu que le choix du mot de passe ne fait pas tout (il est parfois simple de passer outre), mais ne facilitez pas pour autant la vie d’un attaquant en mettant votre prénom comme mot de passe, que ce soit sur le web ou sur des applications lourdes. (En passant, quelle est la force de votre mot de passe ?) ;
- Idem pour les questions permettant de récupérer votre mot de passe. Ne mettez pas « quelle est ma date de naissance » quand votre CV traîne sur le net avec cette information ;
- Les commentaires dans les pages HTML c’est bien, mais ce n’est pas une raison pour y inscrire le mot de passe de votre application =) (oui, c’est du vécu) ;
- Ne faites pas confiance aux technologie client pour la gestion des accès. Utiliser javascript pour une authentification n'est pas fiable, dans le sens où l'attaquant a la maitrise de sa machine et donc de ce qui se passe dessus. Un simple controle des données est toutefois très envisgeable (pour verifier les champs avant envois par exemple), tant que l'authentification est vérifié ensuite coté serveur ;
- Ne laissez jamais les valeurs par défaut sur une application web que vous installez. Les mots de passe et logins par défaut sont connus, et c’est en général la première chose que testera un attaquant.
Conclusion
Gardez à l’esprit que pour bien se protéger, il faut connaître la menace. Cet article n’est pas un mode d’emploi d'attaque mais une simple sensibilisation. Sachez que si l’envie vous prend de tester ces techniques d’attaque et que par chance (ou pas) vous arrivez à vos fins, vous risquez entre 2 et 5 ans d’emprisonnement et de 20 000€ à 75 000€ d’amende (articles 323-1 à 323-7 et 434-23 du code pénal).
J’espère que cet article vous a intéressé, j’attends vos commentaires avec impatience !
, thermo 
6 commentaires - 
pas de trackback
