Implantation de logiciel de gestion (ERP): ne pas confondre rigidité et rigueur

Sécurité Web : petit tour d'horizon

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ésent
er 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).

Petit tour d'horizon sur la sécurité Web

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 = ’$userAND 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.

injection SQL dans la vie de tous les jours

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 :

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 :

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 :

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).

Article original de Germain BAUVIN, consultant en sécurité Informatique.

Facebook Twitter Google LinkedIn

Merci de vos partages!

Michel Campillo Michel Campillo, consultant d'entreprise
Logiciels de Gestion
06 89 56 58 18   
contact par email

Je peux vous aider?


🎯 Autres options: l'actualité du BTP, ma newsletter, choisir un logiciel de gestion BTP, voir le plan du site.

Copyright © 2018 Michel Campillo, tous droits réservés

eXTReMe Tracker