Envoyer/recevoir. Tous les
messages stockés sur le serveur arrivent l'un après
l'autre dans la boîte aux lettres de l'utilisateur.
D'un revers de sécurité saine, celui-ci
écarte les e-mails avec des pièces jointes
aux formats susceptibles de contenir des codes malicieux.
Vient alors la lecture d'un message incitant à
ouvrir un lien d'apparence innocente. A priori, impossible
de savoir à l'avance si derrière ce lien
peut se cacher un risque, car celui-ci pointe vers un
formulaire Web signé d'un site très en vue.
Résultat, à l'insu de l'utilisateur, la
requête ne glisse pas un mot dans le champ de saisie
du formulaire mais un code JavaScript malicieux. Une fois
envoyée sur le serveur vulnérable, la séquence
contenue dans la requête se sert alors de l'environnement
d'éxécution non protégé pour
renvoyer la réponse au poste client.
Scénario
possible ensuite ? Ouverture de multiples fenêtres
sur l'écran de l'utilisateur, transfert des mots
de passe des cookies stockés sur le disque dur,
écriture d'informations dans la base de registre
(nombreuses exploitations possibles selon une
alerte de Securiteam), ou même introduction
d'un ver. En fait, il serait fastidieux de lister
toutes les opportunités néfastes qu'offrent
JavaScript et même VBScript aux malveillants, qui
peuvent également glisser l'url fautive sur la
page d'un site ou derrière une image. "Je
sais qu'il est possible de lancer une boucle d'ouverture
de la commande Telnet provoquant 50 connexions au
serveur FBI.gov, lequel reçoit l'IP de la personne
qui en est victime", explique Aurelien Cabezon, consultant
sécurité chez Asséphira
à Sophia-Antipolis.
Au
moins des dizaines d'applications concernées
"Le
terme Cross Site Scripting désigne une faille qui
touche à peu près tous les éléments
dynamiques d'un serveur web, comme un cgi, une page php,
un module, une page d'erreur interne au serveur...",
décrit Grégory Duchemin, consultant chez
Neurocom
au Canada. Selon ce spécialiste de ce type de vulnérabilités,
des "publications de failles CSS concernant divers
produits apparaissent régulièrement sur
les forums spécialisés en sécurité.
[Elles] sont, je crois, le fait de la méconnaissance
du problème par les développeurs de logiciels
qui n'ont reçu aucune formation adéquate
en sécurité, ou bien sont tout simplement
sous pression. Cela est regrettable, car ce sont eux qui
pourraient limiter la casse. Au lieu de cela, d'un côté
les développeurs introduisent de nouveaux risques,
de l'autre les experts en sécurité auditent
et remontent des alarmes, et au centre l'utilisateur-victime
ne comprend pas grand chose à cela."
Pour saisir l'ampleur du phénomène, voici
une liste non-exhaustive des logiciels qui ont un jour
été concernés: citons les navigateurs
Explorer,
Netscape et Opera côté client, puis les
serveurs web IIS
et Apache,
les serveurs d'applications IBM WebSphere,
Tomcat (open source) et Macromedia JRun
(ex-Allaire), le proxy Squid,
le serveur ITS
de SAP et certains serveurs spécifiques de Microsoft.
La plupart de ces produits, sauf si les correctifs ne
sont pas appliqués, ne sont plus concernés
par les failles décrites précisément
en suivant les liens ci-dessus. Mais d'autres vulnérabilités
du même type peuvent parfois subsister en leur sein.
Développements spécifiques,
exploitation côté serveur
Apparues de manière obscure et non
médiatisées en 1997, les attaques utilisant
des failles de Cross Site Scripting ont fait l'objet d'une
première mention officielle dans un communiqué
du Cert (navigateurs et serveurs web) daté
de février 2000. Depuis, leur exploitation a connu
une accélération. En témoignent les
découvertes à répétition des
détournements possibles des services Hotmail et
Yahoo (alerte
de juin parmi d'autres). Alors que le premier des
deux a fait l'objet d'une vague d'articles la semaine
dernière pour une troisième
faille, le portail français du second a été
notifié en même temps d'une autre vulnérabilité
CSS non médiatisée, heureusement vite corrigée.
Or, dans le cas de la "troisième faille",
les risques ne visent pas que des applications du commerce.
Le développement propriétaire est aussi
touché par beaucoup de failles CSS, rendant le
nombre de sites visés encore plus incalculable.
L'alerte cite les services de type Webmail, enchères
en ligne, les forums et "chats" en HTML entre
autres. "Les langages interprétés côté
serveur ont permis un nouveau type d'exploitation du Cross
Site Scripting", dévoile Gregory Duchemin.
"La personne attaque directement le serveur en lui
injectant du script PHP, Server Side Include... par le
biais d'un forum par exemple, ce qui permet d'éxécuter
dessus à peu près n'importe quelle commande
système. L'exploitation est toujours en trois phases : 1.injection
du code dans le forum sous la forme d'un message; 2.ouverture
du nouveau message, interprétation du code par
le serveur; et 3.visualisation du message et donc du résultat
de l'éxécution du code par le serveur."
Ceci permet entre autres à un pirate de s'infiltrer
à l'aide d'informations renvoyées.
Contrer
ces failles par des filtres clients ou serveurs ?
Face à
une telle famille de vulnérabilités exploitables
par de simples programmeurs sans avoir aucun recours à
des outils de hackers, les systèmes de protection
automatisés n'existent pas. Côté client,
"la première démarche serait d'évacuer
JavaScript (et VBScript)", indique Aurélien
Cabezon. "La deuxième serait pour les développeurs
de vérifier tous les codes dans les scripts. L'une
des solutions serait aussi d'intervenir avec des filtres
au niveau client avant la validation du remplissage des
champs ouverts."
Pour Gregory Duchemin, "il est nécessaire
de toujours utiliser la dernière version d'un logiciel
destiné a un usage public et de vérifier
si des mises à jour sont disponibles. Mais cela
reste très insuffisant puisque nombre d'éditeurs
n'interviennent qu'après la découverte d'une
faille dans une optique très 'stratégie
commerciale'. L'audit reste la solution la plus sûre
pour l'ensemble des éléments dynamiques
qui acceptent en entrée des données saisies
par l'utilisateur, pour ensuite les afficher même
partiellement. Il est important de filtrer le flux de
sortie pouvant être dangereux, et préférable
d'utiliser les codes d'échappement spécifiques
du langage utilisé plutôt qu'un système
de filtre propriétaire comportant des oublis ici
et là."
"Dans certains types de services, continue-t-il,
il convient d'autoriser quelques commandes à l'utilisateur.
Aussi dans ce cas, je crois que la meilleur devise est
' tout est interdit sauf ' en dressant une liste
des commandes autorisées pour diminuer les risques
d'erreurs fatales. L'audit devrait être fait sur
les sources de toutes pages avec du code dynamique, tous
les cgi/scripts intervenant dans le processus interactif,
et bien sûr le serveur web lui-même en le
connaissant bien pour éviter les erreurs de configuration.
J'ajouterais qu'il est toujours préférable,
quand cela est possible, d'utiliser des logiciels dont
les sources sont accessibles. Cela améliore grandement
la qualité de l'audit."
|
