Les attaques de type [[http://fr.wikipedia.org/wiki/Cross_site_scripting|cross site scripting]] consistent en l'utilisation d'une application web pour déposer du code qui, affiché par d'autres utilisateurs du site, déclenche l'exécution de scripts plus ou moins hostiles. Pour protéger les utilisateurs de Sympa des attaques de type "cross-site scripting", David Verdin (CRU) a fait quelques recherches sur les attaques de ce type. Il synthétise dans cette page les informations glanées sur les sites : * http://ha.ckers.org/xss.html * http://www.commentcamarche.net/attaques/cross-site-scripting.php3 * http://www.cgisecurity.com/articles/xss-faq.shtml * http://www.cert.org/tech_tips/cgi_metacharacters.html **Ces informations n'ont pas la prétention d'être exhaustives**, mais nous vous les livrons car nous pensons qu'elles peuvent aider les développeurs d'applications web qui souhaitent protéger leurs applications contre ce type d'attaques. ====== Problématique ====== ===== Cross-site quoi ? ===== Si vous n'avez jamais entendu parler de cross-site scripting (XSS), lisez quelques articles de fond avant de passer à la suite. Le principe du cross-site scripting est présenté dans plusieurs pages. Une bonne présentation synthétique se trouve dans [[http://fr.wikipedia.org/wiki/Cross_site_scripting|wikipédia]]. Le site [[http://www.cgisecurity.com/articles/xss-faq.shtml|www.cgisecurity.com]] propose une FAQ claire. En résumé, on peut dire que, dans notre contexte, un XSS est un appel à un script interprété côté client, dissimulé dans une chaine de caractère. Le gros du boulot est de contrer la dissimulation. ===== Objectif et limites du présent texte. ===== Les recherche menées ici ont eu pour contexte le développement de [[http://www.sympa.org|Sympa]]. Notre objectif était principalement d'empêcher les attaques de première et troisième catégories, c'est-à-dire empêcher l'injection de code hostile dans les données stockées par Sympa. Ceci est possible via les champs de formulaire de l'interface Web, par l'intermédiaire du gecos des adresses mails et enfin dans les requêtes SOAP. On trouve facilement des exemples de XSS et la manière dont ils agissent. En revanche, certainement en raison de la grande variabilité des failles exploitées, on a du mal à trouver des expressions rationnelles permettant de les détecter. Par ailleurs, les attaques XSS étant fondées sur les exceptions (principalement, dans notre contexte, la nécessaire souplesse des navigateurs vis à vis du HTML mal formé) il est peu probable qu'une expression rationnelle puisse les intercepter toutes. Nous cherchons donc avant tout à comprendre le fonctionnement des attaques XSS pour évaluer les outils qui nous permettront de les contrer. Enfin, prenez note que ce document est un document de travail, pas une solution miracle. Nous espérons cependant qu'il vous aidera à protéger vos applications. ====== Préambule : les navigateurs ====== Lorsque vous testez la vulnérabilité de votre application au XSS, considérez que la plupart des attaques un peu raffinées exploitent un comportement particulier d'un navigateur spécifique. Tous ne présentent pas les mêmes failles. ====== Chaînes dangereuses ====== On peut synthétiser quelques informations sur les chaînes de caractères pouvant être sources de cross-site scripting (XSS dans la suite). Les XSS ont la structure suivante : * Un contexte encapsulant la chaîne, servant souvent à permettre d'écrire la chaîne sous une forme innoffensive. Dans ces cas, c'est la combinaison contexte - chaîne qui est dangereuse; * La chaîne de caractère elle-même. Sauf exceptions (présentées [[#exceptions|plus bas]]), la chaîne peut être décomposée ainsi : * "<" un chevron ouvrant de balise ; * une chaîne de caractère contenant un nom de balise HTML, pas forcément W3C ; * un ou plusieurs séparateurs ; * une chaînes de caractère introduisant le script ; * le script lui-même. ===== Contexte ===== C'est comme un médicament : il faut un principe actif et un excipient. Le principe actif est la molécule qui va agir, mais elle est inutile si elle n'est pas mélangée à l'excipient chargé de l'amener à bon port. Le rôle du contexte est de faire passer les barrières au code hostile. Exemple : une bonne vieille balise XML qui contient une section CDATA avec des balises et un script encodés en HTML. tout ça analysé par le navigateur donnera une script interprété. Mais si on se contente d'une recherche sur une chaîne genre "]]> Ça peut aussi tout simplement être des espaces vides, ou la fermeture d'une autre balise ( par exemple). ===== Chevron ouvrant ===== Les chevrons, notamment, peuvent être encodés (couramment en HTML "<") pour ne pas être repérés par les expressions rationnelles. L'auteur [[http://ha.ckers.org/xss.html|du florilège]] propose la liste suivante d'encodages différents pour le chevron ouvrant, en combinant HTML et javascript (en UTF-8). Il précise que "la plupart ne donneront rien, mais certains peuvent être correctement interprétées suivant certaines circonstances." * < * %3C * -AD4+ (dans le cadre d'un affichage en UTF-7 !) * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * < * \x3c * \x3C * \u003c * \u003C ===== Les balises ===== La liste suivante contient les balises pouvant introduire un attribut contenant un script. * SCRIPT * IMG * BODY * IFRAME * FRAMESET, FRAME * INPUT * LAYER * BGSOUND * BR * LINK (rel="stylesheet", ref="