Le magazine 01informatique vient de sortir un dossier complet sur la sécurité dans les sites AJAX (http://www.01net.com/01informatique/). Ayant entendu le teaser à la radio (les développeurs ont négligé la sécurité
!! oh mon dieu), je m’attendais à un article pour pinpins basé sur des vérités générales. Je dois avouer que j’ai été surpris de la qualité avec laquelle le dossier a été traité. Il ont même réussi à me faire peur et j’ai repassé dans ma tête tous les sites web que j’ai pu développer en me posant cette question : sont-ils sécurisés, y’a t-il des failles ?
Je me suis toutefois rassuré rapidement, ASP.NET est loin d’être un gruyère et j’ai toujours appliqué les grands principes de sécurité du Web :
- vérifier toutes les saisies utilisateurs (Cross-Site Scripting, SQL Injection, Overflow)
- faire attention à tout Cookie, les crypter si nécessaire
- limiter la surface d’exposition des API publiques (WS, Ajax, GET, etc.)
- utiliser des ID temporaires (token ou ticket), casser les séquences (IDENTITY)
Cependant, j’ai été interpellé dans l’article par une technique de piratage appelée : Cross-Site Request Forgery (CSRF ou XSRF pour les intimes). Ne connaissant pas cette technique, j’ai donc fait quelques recherches pour me documenter et je me suis monté un petit lab pour voir comment l’utiliser (et la contourner).
Je ne vais pas décrire dans le détail l’histoire et la description de cette faille donc je laisse la main a des spécialistes pour cette partie : http://www.cgisecurity.com/articles/csrf-faq.shtml
Le principe, c’est qu’une page, un site tiers, un mail, un document, etc. exécute une requête vers le site à pirater en utilisant l’identité « reconnue » de l’utilisateur. Cela paraît simple sur le papier mais bien évidemment il faut réunir de nombreuses circonstances pour réussir son coup. La principale étant que le site à pirater doit baser son authentification sur un cookie persistant.
Démonstration : Sur mon site, j’expose une fonctionnalité. On va prendre la plus simple à détourner, le GET : http://lab.djeepy1.net/CSRF/default.aspx?action=achat&article=123456. Supposons que dans le code behind, je vérifie uniquemement la présence d’un cookie pour sécuriser l’action.
if (Request.Cookies["UserId"] != null)
{
//on considère que l'utilisateur est OK
BusinessLayer.ShoppingMgr.Buy(Helper.Decrypt(Request.Cookies["UserId"].Value), Request["ArticleId"]);
}
Le site tiers a juste à faire une requête, mais comment peut-il récupèrer la bonne valeur de cookie ? Avec un Cross-Site Scripting (XSS) classique mais pour cela il doit pouvoir exécuter du Javascript sur votre site (cf. règle n° 1 plus haut). L’autre moyen est à la base du Cross-Site Request Forgery : on s’arrange pour que cette requête soit exécutée depuis le navigateur de l’utilisateur, ainsi, les cookies sont automatiquement envoyés au site à pirater avec la fausse requête. Par exemple, on vous envoie un message sur votre webmail avec une image pointant sur la fonctionnalité GET. Vous ne voyez qu’une image « cassée » et pourtant, l’action a eu lieu sur l’autre site.
<img src="http://site/?action=XX"/>
Pourquoi donc Ajax est-il pointé du doigt ? Cette faille est vieille comme le web (1998) mais très difficilement exploitable dans un monde fondé sur les Postback. Avec Ajax, de nombreuses API s’exposent sans pudeur sur le Web, bien souvent accessibles avec un simple GET.
Comment sécuriser son site ? Vérifiez toute l’API exposée et vérifiez que vous n’utilisez pas de cookie persistant pour authentifier une requête ou tout du moins que TOUTE votre sécurité ne soit pas basée sur cet unique moyen. Les Sessions ASP.NET sont protégées de cette faille car elles se basent sur un cookie dit « de session » (temporaire et lié à la navigation).
Cette faille fait la une car on assiste depuis quelques temps à un nouveau type de site Web : le site composite (ou mashup). Un site composite est un assemblage de modules provenant de différents autres sites. Exemple : mes dernières enchères depuis ebay, mes news depuis MSN, ma météo depuis meteoconsult et mon site de chat depuis googletalk. Tout étant exécuté avec le même contexte, un module peut potentiellement exploiter les fonctionnalités d’un autre (via son API Javascript).
En conclusion, ne cédez pas à la panique et suivez les conseils suivants (qui s’appliquent même au dela de l’informatique) :
- quels sont les risques (mobile du crime, conséquences) ?
- quelles sont les failles (ouvertures, exposition) ?
- comment je souhaite me protéger de ces risques ?
Pour cela, prévoyez toujours une phase d’audit de votre site web avant la mise en production.
