Problèmes de sécurité liés aux programmes CGI - côté client
-
Les scripts CGI sont généralement conçus pour traiter
les données provenant de formulaires correspondants. L'auteur d'un
script conçoit donc son programme en ayant en tête le format
des données telles qu'elles sont normalement transmises par un butineur.
Par exemple, si un formulaire contient un champ de saisie de texte et que l'utilisateur y tape le texte <script src="UrlDUnScriptJavascriptDangereux"></script>, le script CGI recevra la chaîne de caractères suivante: %3Cscript+src%3D%22...%22%3E%3C%2Fscript%3E (on voit que tous les caractères non-alphabétiques ont été remplacés par des séquences %xy, où xy représente le code hexadécimal du caractère tapé).
-
Beaucoup de scripts renvoient dans leur réponse une partie des
données reçues en entrée et supposées provenir
du formulaire correspondant, par exemple pour confirmer que ces données
ont bien été enregistrées. D'autres scripts archivent
les données reçues et ces archives sont accessibles sur le
Web (p.ex. forums de discussions).
-
Si l'auteur du script ne prend pas en compte le fait que les données
pourraient provenir d'une autre source que le formulaire prévu, il/elle
risque de limiter le traitement des données au format supposé
que ces données doivent avoir lorsqu'elles proviennent effectivement
du formulaire.
Par exemple, le programme fera la substitution des %3C (représentant le caractère <) en < et des %3E (représentant le caractère >) en >. L'auteur a ainsi la conviction que si des balises HTML sont tapées dans un des champs du formulaire, cela n'influencera pas la réponse envoyée par le script CGI car une chaîne de caractères telle que <script ...> dans le code HTML de la réponse ne fait qu'afficher du texte à l'écran, sans avoir aucun effet potentiellement dangereux.
-
Si, toutefois, le script CGI était activé par autre chose que
le formulaire prévu (p.ex. un programme accédant directement
au serveur, ou un lien du genre <a
href="http://.../cgi-bin/LeScriptMalProtégé?ChampTexte=<script
src=...></script>"> dans un document), les caratères
spéciaux tels que < et > ne
seront pas transformés et risquent donc d'être inclus tels quels
dans la réponse. Le butineur qui recevra cette réponse va alors
interpréter les chaînes de caractères telles que
<script src=...></script> comme des balises
HTML et va donc exécuter le code Javascript.
-
Pour éviter ce genre de problèmes, un script CGI devrait
systématiquement encoder tout ce qui doit être envoyé
dans la réponse, en remplaçant tous les caractères
spéciaux d'HTML par les entités correspondantes:
caractère < > & " entité < > & " Une approche encore plus défensive consiste à filtrer de chaque champ de saisie d'un formulaire tous les caractères qui ne sont à priori pas autorisés pour ce champ. Par exemple, pour un champ numérique, on ôtera tout caractère qui n'est pas dans l'intervalle 0-9.
-
Les sites particulièrement vulnérables sont par exemple les
sites servant de forums de discussion. Un utilisateur mal intentionné
peut y déposer un message qui contiendra un appel à du code
Javascript qui va alors s'exécuter sur les machines des autres personnes
venant visiter le forum de discussion et visualisant le message
piégé.
- D'une manière similaire, il est possible de piéger un site qui utilise des "cookies" pour générer dynamiquement un document. En effet, si un script Javascript arrive à modifier le contenu d'un cookie de telle manière que l'inclusion dynamique du contenu de ce cookie dans un document provoquera l'exécution d'un autre script malveillant, le cookie en question va ainsi servir en quelque sorte de bombe à retardement qui agira à chaque fois que le site mal protégé essayera d'utiliser le contenu du cookie piégé.
- CERT® Coordination Center: Understanding Malicious Content Mitigation for Web Developers
- CERT® Coordination Center: Frequently Asked Questions About Malicious Web Scripts Redirected by Web Sites
Bertrand Ibrahim 