Cross-Site Request Forgery: l'une des plus graves vulnérabilités des applications web

Résumé du document

De nos jours, le nombre des attaques menées contre les applications web augmente de façon phénoménale. La plupart des applications identifient correctement les utilisateurs et comprennent leurs requêtes. Cependant, certaines ont encore beaucoup de mal à vérifier les origines des requêtes et les intentions réelles des clients. En effet, la relation d'authentification entre le client et le serveur au sein d'une application web constitue un enjeu majeur et la sécurisation des applications web devient alors primordiale.
Cross-Site Request Forgery (CSRF) est l'une des plus graves vulnérabilités des applications Web (Top Ten OWASP). Elle permet au pirate d'exécuter des actions malveillantes sur un site de confiance, autorisées à partir du navigateur de l'utilisateur sans même qu'il ne le sache. L'attaque étant actionnée par l'utilisateur lui-même, celui-ci devient alors complice sans en être conscient.

Extraits

[...] Cross-Site Request Forgery (CSRF) est l'une des plus graves vulnérabilités des applications Web (Top Ten OWASP). Elle permet au pirate d'exécuter des actions malveillantes sur un site de confiance, autorisées à partir du navigateur de l'utilisateur sans même qu'il ne le sache. L'attaque étant actionnée par l'utilisateur lui-même, celui-ci devient alors complice sans en être conscient. Les CSRF existent depuis presque une décennie et sont également connues sous les appellations XSRF, Confused Deputy ou encore Session Riding etc. Ce sont des attaques spécifiques aux applications web, permettant à celui qui attaque de forcer le navigateur de l'utilisateur à effectuer des actions non désirées sur un site tiers. [...]

[...] Toutes les requêtes provenant de la même origine sont autorisées. Les requêtes POST inter-domaines sont bloquées mais toutes les requêtes GET inter-domaines (avec ou sans paramètres) sont autorisées. Cependant, les cookies et les en-têtes d'autorisation sont retirés de ces requêtes. La politique du serveur de coopération : Un serveur de coopération peut fournir de l'information contextuelle additionnelle grâce à une politique supplémentaire côté serveur. Cela permet au moteur de politique du côté client de distinguer les requêtes malicieuses de celles réellement légitimes, éliminant ainsi, en même temps, tous les faux positifs. [...]

[...] L'extension doit être capable de bloquer et/ou modifier les requêtes entrantes et sortantes. Heureusement l'architecture de Firefox permet l'accès aux requêtes via deux interfaces : nsIContentPolicy qui donne accès aux informations contextuelles nsIObserver qui permet d'observer les requêtes et les réponses HTTP lors de leur modification. L'architecture de l'extension permet de séparer l'interception et l'application des politiques, afin que celles-ci puissent être modifiées au besoin. Chaque politique est implémentée séparément et peut avoir un état spécifique. Les politiques peuvent elles-mêmes modifier une requête. [...]

[...] Cependant plusieurs attaques CSRF ont des caractéristiques communes. Une mesure de protection côté client a été implémentée. Elle pré- visualise le code HTML avant que chaque page ne soit chargée et détecte les attaques CSRF potentielles. Une autre mesure consiste à ce que l'extension soit téléchargée et intégrée avec le navigateur. Les contre-mesures existantes Il existe actuellement une panoplie de techniques permettant les attaques CSRF, qu'il s'agisse de la protection du serveur d'application ou de celle de l'utilisateur final. Cependant les mécanismes de protection côté serveur ne sont pas encore largement adoptés et les mécanismes côté client ne fournissent qu'une protection limitée et sont, pour la plupart, non adaptés aux applications web Même les plus prudents des utilisateurs, sont ainsi incapables de se protéger adéquatement contre les CSRF. [...]

[...] Utiliser des jetons de sécurité pour les transactions critiques. Restreindre le téléchargement des pièces jointes en formatant le type d'extension et la taille du fichier. Le site cible pourrait aviser les utilisateurs de l'éventuelle présence de courriels phishing et spam. etc. Détection et découragement La question qui se pose à ce stade est comment détecter les signatures CSRF et les bloquer avant que l'attaque ne commence. Cela a été longtemps considéré comme impossible à réaliser puisque le code de l'attaque est spécifique à l'application. [...]