XSS un acronyme qui ne veut rien dire
Ok, bon c’est parti, je vais vous parler de mes recherches (si si ) avec une série de billets sur les XSS, le fonctionnement des attaques, l’évasion et les techniques de détection pour finir par quelques cas d’application à la marge mais pourtant super intéressants (la question de l’utilité est laissé en exercice au lecteur).
Pour commencer, on va reprendre la base XSS : Cross Site Scripting, bon déjà ils ont foutu un X et pas un C pour éviter qu’on ne confonde l’attaque par XSS avec les feuilles de style CSS (bien qu’il soit possible sous IE de faire des XSS via des feuilles de style CSS… )
Les Cross Site Scripting, c’est vieux, très vieux, pas autant que les SQLi mais pas loin. Faut dire qu’en 98 on disait qu’il fallait désactiver javascript parce-que ça faisait planter et c’était dangereux, Il y a même eu des papiers sérieux sur le sujet et des propositions de solutions. Et tout le monde trouvait ça ridicule, c’est d’ailleurs une image qui subsiste de nos jours. Pourtant 12 ans après, on en croise toujours plein dans nos sites…
Pourquoi Cross Site, parce qu’à la base, ça permet au travers du site d’ajouter ses propres scripts à une page web, et pas uniquement du JavaScript, sinon on aurait appelé ça Cross Site Javascripting. En effet, à l’époque, l’execution de code VBScript et d’Active-X dans IE était bien plus puissant que JavaScript.
Le principe de base d’un XSS c’est d’aller placer un bout de code dans la page d’un site via un paramètre dans l’url… hélas on s’arrête rapidement à ce simple exemple d’une Popup, renforçant le sentiment d’innocuité d’une telle attaque. Alors qu’on peut se servir d’une telle vulnérabilité pour effacer a distance un téléphone mobile en activant un code USSD via l’injection d’une simple iframe, ou bien encore logguer les frappes au clavier via SVG, voir de complètement pwner un navigateur réputé sur et à la pointe.
Cependant, comme vous l’aurez compris si vous avez pris la peine de jetter un oeil à ces 4 précédents liens, tout ceci est hautement dépendant d’un composant clef, essentiel, omniprésent qui remplacera (ou remplace déjà) nos bons vieux systèmes d’exploitation LE NAVIGATEUR (butineur, browser, bouffeur de ram, choisissez le terme qui vous plaira) et qui accessoirement possède un accès total à toutes nos données puisqu’elles sont en sécurité dans le cloud.
C’est pour ça qu’il est impossible voir carrément débile d’envisager une quelconque solution de sécurité anti-XSS sans étudier l’acteur majeur de cette problématique qu’est le navigateur et ses myriades de familles, versions, fonctionnalités, plugins et autres applications (et je ne vous parle même pas des problématiques d’encodage). Spécificités qui sont d’ors et déjà exploitées pour divers usages et certaines basses oeuvres.
C’est pourquoi le nombre de solutions de sécurité coté client explosent (CSP, NoScript, etc…) dont certaines s’avèrent très prometteuses et intéressantes et mériteraient un focus dédié.
Voila pour une introduction en vrac à ma thématique de recherche.
