Se protéger des failles de sécurité XSS/cross-site scripting

Voici une courte liste ac­com­pag­née d’ex­pli­ca­tions sur les dif­fé­rentes sortes de cross-site scripting (XSS). 

Un script mal­veil­lant est envoyé à un serveur Web via le char­ge­ment d’une adresse URL manipulée ou via l’envoi d’un for­mu­laire préparé. Ce serveur Web retourne par la suite ce script au client sans vé­ri­fi­ca­tion. Le code mal­veil­lant n’est pas en­re­gis­tré sur le serveur et existe seulement de manière tem­po­raire lors du char­ge­ment de la page Web via le client. Les cibles préférées de ces scripts sont les sites Internet généraux ou les logiciels de mes­sa­ge­rie.

Exemple : le cyber agresseur dissimule son script dans un lien tout préparé. Par la suite, il essaye de le trans­fé­rer (souvent par email). Le code mal­veil­lant se déclenche seulement si l’uti­li­sa­teur clique sur le lien qu’il a reçu. S’il le fait, une page s’affichera, par exemple une imitation de la page d’accueil de sa banque en ligne. Au lieu d’envoyer les données au serveur Web de la banque, le script les transfère à l’adresse que le pirate a dé­ter­mi­née au­pa­ra­vant. 

Les scripts mal­veil­lants sont en­re­gis­trés sur le serveur Web et livrés au client à chaque char­ge­ment. C’est pour cela que certaines ap­pli­ca­tions Web en par­ti­cu­lier sont plus propices aux cy­be­rat­taques, car elles en­re­gistrent les données des in­ter­nautes côté serveur et les diffusent souvent sans codage. Les sites les plus visés par ces scripts sont les blogs et les forums.  

Exemple : Dans un forum, les posts des uti­li­sa­teurs sont en­re­gis­trés dans une base de données, souvent sans vé­ri­fi­ca­tion. Les at­ta­quants sai­sis­sent cette op­por­tu­nité pour ajouter des posts com­por­tant des scripts mal­veil­lants. Par la suite, les uti­li­sa­teurs in­sou­ciants reçoivent ce lien par email ou alors arrivent par hasard sur le post en question et cliquent dessus.

Les uti­li­sa­teurs et les ad­mi­nis­tra­teurs de sites ne peuvent sous-estimer les con­sé­quences néfastes que le cross-site scripting peut avoir. D’un côté, les uti­li­sa­teurs risquent de perdre leurs données et servent de complices aux at­ta­quants. De l’autre côté, les ad­mi­nis­tra­teurs de sites sont res­pon­sables des données de leurs clients / visiteurs et sont donc également concernés par ces attaques. Les contenus mal­veil­lants ainsi que les pannes de serveurs diminuent le nombre de visites, ce qui peut à long terme avoir un impact négatif sur le clas­se­ment dans les moteurs de re­cherches. Par ailleurs, la relation de confiance entre l’uti­li­sa­teur et le site Internet est com­pro­mise ce qui peut également mener à des pertes fi­nan­cières. En tant qu’ad­mi­nis­tra­teur de site Web mais aussi en tant qu’uti­li­sa­teur, il convient de prendre des mesures pour prévenir ces failles de sécurité de type cross-site scripting.

La meilleure des façons pour prévenir un cross-site scripting côté client est de dé­sac­ti­ver le support de Ja­vaS­cript dans votre na­vi­ga­teur. En faisant cela, les XSS basés sur le DOM qui visent Ja­vaS­cript n’ont aucun effet, étant donné que l’ap­pli­ca­tion ma­li­cieuse n’est pas démarrée. Pour certains na­vi­ga­teurs, il existe des modules qui per­met­tent de prévenir ces attaques XXS. Firefox par exemple dispose de l’extension NoScript. Par défaut, tous les contenus actifs des sites Internet tels que Ja­vaS­cripts, Java-Applets, Adobe Flash ou Microsoft Sil­ver­light y sont au­to­ma­ti­que­ment bloqués. Il est possible de lever ce blocage tem­po­rai­re­ment ou de les mettre en liste blanche si vous êtes sûr et certain de leur fiabilité. Malgré le danger que présente le cross-site scripting, il faut être sceptique à l’égard de  données externes telles que les liens et bien les vérifier avant de les utiliser.

Pour protéger vos ap­pli­ca­tions Web d’attaques XSS, il vous faut con­si­dé­rer que tous les éléments Internet ne sont pas sécurisés. Il faut les vérifier avant que le serveur Web ne puisse les recevoir. La méthode la plus sûre est de l’insérer sur une liste blanche (comme dans le module de na­vi­ga­teur NoScript). Le fait de scanner les res­sources arrivant sur votre site Internet et d’autoriser l’accès seulement aux contenus fiables constitue un excellent moyen de pro­tec­tion contre le type de faille de sécurité cross-site scripting.

En plus de ces données entrantes, il faut penser à sécuriser les données sortantes. Il est pour cela né­ces­saire de remplacer les ca­rac­tères spéciaux HTML qui posent problème par leurs référents. Ainsi, ces éléments sont in­ter­pré­tés comme normaux et les scripts mal­veil­lants ne peuvent démarrer.  La plupart des langages de pro­gram­ma­tion et de script tels que Perl, Ja­vaS­cript ou PFP disposent de fonctions déjà pré­dé­fi­nies pour subs­ti­tuer ou masquer ces ca­rac­tères que vous utilisez sans le savoir. Vous pouvez également vous défendre contre ces attaques XSS aussi en utilisant des pare-feu.

Le cross-site scripting est souvent considéré comme une première étape dans les attaques plus graves, qui peuvent com­pro­mettre la pro­tec­tion complète des données entrantes et sortantes de votre serveur Web.