Les failles XSS échappent au contrôle des développeurs
Met en garde un ingénieur de Google
Le 2011-10-05 22:22:52, par Idelways, Expert éminent sénior
Une attaque XSS découverte ? Il suffit de colmater la faille et mettre à jour l'application de production pour s'en débarrasser ?
Ce n'est plus aussi évident que cela, met un garde un ingénieur de Google contre la longévité grandissante des menaces XSS avec l'avènement des applications Web, du HTML5 et des démocratisations en masse des appareils mobiles.
Ce type d'agression numérique force un site à afficher du code HTML ou des scripts, qui sont souvent saisis par l'agresseur sur un formulaire. Si ce code malicieux est injecté dans une page non sécurisée, il peut par exemple afficher un formulaire afin de tromper l'utilisateur et lui faire saisir ses informations d'authentification, pour les dérober.
La portée du code client d'une application web est limitée par « la politique de la même origine ». Ce concept interdit au code d'interférer avec d'autres pages ouvertes dans les autres fenêtres ou onglets.
Dans le cas des attaques XSS, l'attaquant délègue son code qui va s'exécuter au sein de la page victime, dans la même origine définie par le domaine, le protocole et le port utilisé.
Michal Zalewski, un ingénieur au département sécurité de Google s'explique : « Au minimum, l'attaquant peut garder un contrôle total, aussi longtemps que le site infecté reste ouvert, dans n'importe quelle fenêtre du navigateur. Avec l'avènement des ordinateurs portables, ce n'est pas rare que les utilisateurs gardent un site régulièrement utilisé, ouvert pendant des semaines. », propose-t-il.
Durant cette période, le propriétaire légitime du site n'a pratiquement rien à faire et « il n'y a aucune manière robuste de savoir si l'infection est éliminée », s'inquiète Zalewski sur le billet de son blog personnel.
Cette situation se complique davantage, toujours d'après le blogueur, dans le cas où le contenu de la cible compromise est intégré à des pages tierces populaires. Par exemple lorsqu'une application de Webmail intègre le code infecté d'un bouton « Like » et d'un encart publicitaire.
« Avec un peu de chance [sic], le JavaScript de l'attaquant peut devenir pratiquement invincible, même après la fermeture de l'application originale et le vidage du cache du navigateur, explique Zalewski avant de conclure sa pensée : si cela ne vous donne pas à réfléchir, ça devrait ».
L'utilisation de plus en plus répandue du « localStorage » introduit par l'HTML5 exacerbe la problématique sur des applications de plus en plus autonomes et auxquelles on accorde progressivement de plus en plus de privilèges.
Source : Blog de Michal Zalewski
Et vous ?
Ce n'est plus aussi évident que cela, met un garde un ingénieur de Google contre la longévité grandissante des menaces XSS avec l'avènement des applications Web, du HTML5 et des démocratisations en masse des appareils mobiles.
Ce type d'agression numérique force un site à afficher du code HTML ou des scripts, qui sont souvent saisis par l'agresseur sur un formulaire. Si ce code malicieux est injecté dans une page non sécurisée, il peut par exemple afficher un formulaire afin de tromper l'utilisateur et lui faire saisir ses informations d'authentification, pour les dérober.
La portée du code client d'une application web est limitée par « la politique de la même origine ». Ce concept interdit au code d'interférer avec d'autres pages ouvertes dans les autres fenêtres ou onglets.
Dans le cas des attaques XSS, l'attaquant délègue son code qui va s'exécuter au sein de la page victime, dans la même origine définie par le domaine, le protocole et le port utilisé.
Michal Zalewski, un ingénieur au département sécurité de Google s'explique : « Au minimum, l'attaquant peut garder un contrôle total, aussi longtemps que le site infecté reste ouvert, dans n'importe quelle fenêtre du navigateur. Avec l'avènement des ordinateurs portables, ce n'est pas rare que les utilisateurs gardent un site régulièrement utilisé, ouvert pendant des semaines. », propose-t-il.
Durant cette période, le propriétaire légitime du site n'a pratiquement rien à faire et « il n'y a aucune manière robuste de savoir si l'infection est éliminée », s'inquiète Zalewski sur le billet de son blog personnel.
Cette situation se complique davantage, toujours d'après le blogueur, dans le cas où le contenu de la cible compromise est intégré à des pages tierces populaires. Par exemple lorsqu'une application de Webmail intègre le code infecté d'un bouton « Like » et d'un encart publicitaire.
« Avec un peu de chance [sic], le JavaScript de l'attaquant peut devenir pratiquement invincible, même après la fermeture de l'application originale et le vidage du cache du navigateur, explique Zalewski avant de conclure sa pensée : si cela ne vous donne pas à réfléchir, ça devrait ».
L'utilisation de plus en plus répandue du « localStorage » introduit par l'HTML5 exacerbe la problématique sur des applications de plus en plus autonomes et auxquelles on accorde progressivement de plus en plus de privilèges.
Source : Blog de Michal Zalewski
Et vous ?
-
Gagné ! je suis très inquiet...
Que peut on faire pour authentifier les forms : vérifier l'URL est-il assez fiable ?
Quelles précautions avant de taper ses codes de CB ou information de login ?
Quelles réclamations formuler aux éditeurs pour permettre de se protéger ou au moins d'identifier une intrusion ?
Y a-t-il des exemples de code malveillant qui pourraient au moins nous mettre la puce à l'oreille ?
J'écris pas mal de code HTML5 , que faire ?le 06/10/2011 à 11:21 -
Thes32Expert confirmé+1 pour lui, le HTML5 n'a pas que des avantages, c'est aussi une nouvelle grande porte qui s'ouvre aux attaquants...L'utilisation de plus en plus répandue du « localStorage » introduit par l'HTML5 exacerbe la problématique sur des applications de plus en plus autonomes et auxquelles on accorde progressivement de plus en plus de privilèges.le 06/10/2011 à 10:08