FLASH INFORMATIQUE FI



Sécurité des applications Web


L’audit de sécurité informatique (voir page 11) ayant révélé de nombreux problèmes dans des applications Web aux quatre coins de l’EPFL, cet article a pour but de rappeler les principes de base en ce domaine et de donner quelques pointeurs pour en savoir plus.



A recent security audit of our computer infrastructure found many vulnerable websites in our network. The aim of this article is therefore to give a few basic security tips and pointers to additional resources to help developpers create more secure Web applications.


Martin OUWEHAND


Un bon point de départ est sans doute le document Les dix risques de sécurité des applicatifs Web les plus critiques de l’OWASP.
Cet Open Web Application Security Project est une association de développeurs qui a décidé de réagir contre les problèmes de sécurité omniprésents sur le Web et qui commencent à avoir un impact économique conséquent (dans un incident célèbre, des pirates ont exploité une telle faille pour mettre la main sur les codes de plus de cent millions de cartes de crédit !)
Alors que le site de l’OWASP regorge de documents, de conseils et de bouts de code très utiles (c’est donc une bonne idée d’y faire une visite), il faut bien dire qu’on s’y perd un peu, et j’invite plutôt les développeurs Web de l’EPFL à commencer par lire les dix pages du document mentionné concernant chacune un type de faille et à réfléchir si les applications qu’ils ont écrites ou qu’ils maintiennent ne sont pas vulnérables... Ces pages sont très bien faites, nous emmenant tout de suite au coeur du problème : une description, quelques exemples, comment l’éviter et enfin des pointeurs pour en savoir plus. Parmi ceux-ci, j’ai trouvé dans les cheat sheets (ce qu’écolier j’appelais donc une feuille de triche) un bon équilibre entre la concision et l’étendue des problèmes couverts.
Comme le traitement donné dans ce document est assez concret et axé sur la pratique, je vais dans la suite de l’article parler des failles traitées (numérotées, comme dans le document, de A1 à A10) selon les points forts qui s’en dégagent.

Validation des données

Tout appel à une application est entièrement sous le contrôle d’un éventuel attaquant, qui peut glisser des caractères imprévus dans les paramètres. Il est donc indispensable de les valider tout au début du code applicatif, et selon la logique liste blanche (par exemple, dans un nom d’utilisateur, seuls les caractères alphabétiques sont permis) plutôt que selon la logique échappement (où on essaye de traiter spécialement les caractères dangereux qui ont une signification spéciale pour le langage de programmation utilisé). Si dans de très rares cas cette dernière est réellement nécessaire, elle doit toujours suivre l’approche liste blanche.
Un manquement à ces pratiques donne lieu aux failles du type A1 (injection), où par exemple un paramètre externe directement utilisé pour construire une requête SQL permet à un pirate de lire la base de données, ou même de la modifier. Dans les cas les plus graves, ces failles permettent l’exécution de commandes sur le serveur hébergeant l’application, avec peut-être même la possibilité d’en prendre complètement le contrôle.
Les failles de type A2 (XSS ou cross-site scripting) appartiennent aussi à cette catégorie. Les développeurs les traitent souvent à la légère, parce qu’elles ne mettent pas en péril l’application ou le serveur, mais l’utilisateur final : il s’agit de données externes qui sont utilisées directement dans la page Web renvoyée par l’application, un pirate peut donc y glisser un appel vers un site externe qui attaquera le browser de la victime ou lui subtilisera ses données d’authentification (cookie — notons que l’application peut empêcher cette subtilisation en donnant l’attribut HTTPonly à tous ses cookies). Il est possible d’éviter le cross-site scripting dans la génération de code HTML simple (balises et texte) en substituant dans les données sous contrôle externe les caractères <, >, &, ’’, ‘ et / par, respectivement, <, >, &, ",  et F;. Par contre, il semble extrêmement difficile de construire du code javascript en utilisant ces paramètres sous contrôle externe, tant les possibilités de passes multiples d’interprétation sont nombreuses. À éviter donc ! Enfin, certaines failles de type A10 (redirections non validées) suivent le même principe et permettent par exemple à un pirate de rediriger la victime vers un site dangereux (par exemple, il exploite une vulnérabilité de son browser). Quand l’application construit une URL de redirection, elle doit toujours, pour éviter ce type de faille, préfixer ce qui dépend des données externes par le chemin complet du site.

Authentification et gestion de session

C’est le point A3, qui concerne l’authentification de l’utilisateur de l’application, la manière dont elle est maintenue au cours d’une session, la durée qu’il convient de lui donner, etc. C’est là un sujet très vaste, nous y reviendrons sans doute et nous nous contenterons donc pour l’instant de rappeler qu’à l’EPFL, la solution recommandée pour l’authentification est Tequila.

Contrôle d’accès

Lorsqu’une URL donne accès à une ressource précieuse ou déclenche une action importante, l’application doit très tôt contrôler que l’utilisateur authentifié a les privilèges nécessaires pour le faire. Ceci devrait, dans la logique de l’application, venir juste après la validation des paramètres. Quand ce n’est pas fait, des failles telles qu’A4 (références directes non sécurisées) ou A8 (manque de restriction d’accès URL) apparaissent. Un exemple simple de ce dernier cas serait une application qui restreint l’accès à la partie administrative du site en ne montrant dans le menu de navigation que le lien site.ch/user.php aux simples utilisateurs, et le lien site.ch/admin.php aux seuls administrateurs. Elle n’a donc pas prévu le cas d’un pirate malin qui devine son existence (il lui suffit d’entrer cette URL dans son browser pour devenir administrateur).

Contexte

C’est la faille A5 (falsification de requête intersite), très subtile (comprenez : certaines applications de l’auteur de cet article y étaient vulnérables avant qu’il ne lise le document de l’OWASP...), où le développeur n’arrive pas à imaginer que les URL de son application puissent être utilisées en dehors du contexte d’une séance normale de navigation à travers son site. Un exemple illustrera son principe : la victime vient de visiter le site de sa banque pour effectuer un versement généreux : mabanque.com/versement ?somme=1000CHF&pour=compte_Unicef, et la banque a utilisé, après authentification, un cookie pour savoir à qui elle avait affaire. Le pirate envoie alors un mail en HTML à la victime contenant ce lien : mabanque.com/versement ?somme=10000CHF&pour=compte_pirate, qui sera suivi par le browser de la victime (par exemple le pirate le donne comme source d’une balise ). Le cookie de la session précédente sera utilisé pour authentifier la victime et la banque effectuera le transfert ! La banque pourra dire, non sans raison, que la victime aurait dû invalider le cookie en se déconnectant du site de la banque, mais elle pourrait prévenir ce genre d’accident en ajoutant aux URL de son site des chaines pseudo-aléatoires que le pirate ne peut deviner, liées à chaque utilisateur et chaque session.

Bonnes pratiques

Ce sont les points relevant du bon sens. En premier lieu (faille A6), il faut initialiser correctement l’infrastructure utilisée par l’application (changer les mots de passe par défaut, empêcher l’accès à distance de la base de données, etc.) puis la tenir à jour. En particulier, n’oubliez pas que très peu d’applications Web sont incluses dans les mises à jour automatiques des systèmes, et que si vous en installez une, il faut vous abonner à la mailing-list qui annoncera les trous de sécurité et la parution de correctifs. On ne compte plus le nombre de sites de l’EPFL qui ont été piratés par oubli de cette précaution.
Ensuite, le point A9 : toute transmission de données confidentielles et précieuses (mot de passe, cookie, jetons de session, etc.) doit passer par un canal chiffré par TLS/SSL (les URL impliquées doivent débuter par https://, avec le s de sécurité). Pour ce faire, vous aurez besoin d’un certificat de serveur, que vous pouvez obtenir en suivant les indications du site rauth.epfl.ch (la registration authority locale dans le cadre de SwitchPKI.
Enfin la faille A7 : utiliser la cryptographie quand c’est nécessaire, et l’utiliser correctement. Par exemple, l’application n’a pas besoin de connaître les mots de passe en clair pour réaliser l’authentification, il suffit de stocker des hachages (de nos jours, SHA a détrôné MD5 pour ça) des mots de passe : quand l’utilisateur présente son mot de passe, il suffit de le passer par le même hachage et de comparer le résultat avec le hachage stocké (mais bien sûr, dans cet exemple précis, la bonne solution est d’utiliser Tequila, comme mentionné ci-dessus).



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.