Exploits ou autres risques de sécurité avec le téléchargement SVG?
J'ai un site, où les gens peuvent télécharger des graphiques, vous pourriez y penser comme un hébergeur d'images ou un forum pour les photos.
Maintenant, j'autorise le téléchargement de graphiques raster à une certaine taille, mais pas encore de graphiques vectoriels. Je voudrais également autoriser le téléchargement de SVG, mais il y a deux problèmes autour de ma tête:
- Un SVG pourrait-il être construit de telle manière que lors de la lecture des métadonnées, le serveur ne réponde pas. et pourrait être utilisé comme attaque DoS sur le serveur?
- Un SVG pourrait-il être construit de telle manière que, lors du rendu du SVG sur le client, le client ne répond plus et fait potentiellement planter le navigateur de chaque utilisateur sur mon site?
En outre, serait-il une bonne pratique de générer un petit PNG (200x200px) pour une miniature, ou est-il préférable de simplement manipuler le SVG lui-même avec un facteur de zoom ou quelque chose?
Dans le cas où ces exploits SVG sont possibles, comment puis-je me protéger contre eux?
Un SVG pourrait-il être construit de telle manière que, lors de la lecture des métadonnées, le serveur ne réponde pas. et pourrait être utilisé comme attaque DoS sur le serveur?
Qu'entendez-vous par métadonnées? Si vous recherchez la largeur et la hauteur, vous devrez analyser les fichiers SVG au moins partiellement pour les obtenir; il n'y a pas de raccourci pour lire quelques octets de l'en-tête comme c'est le cas avec de nombreux formats bitmap. Cela présente les risques habituels de l'analyse XML, tels que:
- attaques d'inclusion d'entité externe/sous-ensemble DTD contre des fichiers distants, des ressources sensibles au réseau local, des fichiers sensibles à la machine locale et des fichiers de périphérique
- bombes d'extension d'entité imbriquée
- les structures de balises imbriquées pathologiquement peuvent atteindre les limites des ressources de récursivité
par mesure de précaution standard, vous désactivez tous les traitements DTD, XInclude, XSL, XSI et la résolution d'entité.
Un SVG pourrait-il être construit de telle manière que, lors du rendu du SVG sur le client, le client ne répond plus et fait potentiellement planter le navigateur de chaque utilisateur sur mon site?
Peut-être, mais c'est tout aussi possible que cela puisse arriver avec un format bitmap. Voir par exemple les vulnérabilités des fichiers PNG corrompus il y a quelque temps.
Plus préoccupant pour les fichiers SVG, c'est qu'ils peuvent inclure JavaScript, qui fonctionnera dans le contexte de sécurité du site d'hébergement, de sorte que vous devez vous soucier des scripts intersites.
En fait, tous les types de fichiers téléchargés sont vulnérables à cela, mais pas de manière aussi directe et facile à exploiter. Dans certains cas, les navigateurs (en particulier IE) les renifleront de contenu, et s'ils voient des choses qui ressemblent à des balises, ils peuvent potentiellement les réinterpréter en HTML, y compris JavaScript. Il existe également des problèmes secondaires avec le traitement des fichiers téléchargés en tant que Java et fichiers de stratégie Flash.
L'atténuation standard pour tous ces problèmes est de servir vos ressources non fiables, qu'elles soient bitmap, SVG ou autre, d'un domaine différent à votre site principal: un domaine qui ne contient aucune information de session sensible (cookie/auth) et aucune capacité pour créer un script dans le domaine de votre site principal.
De plus, serait-il une bonne pratique de générer un petit PNG (200x200px) pour une miniature, ou est-il préférable de simplement manipuler le SVG lui-même avec un facteur de zoom ou quelque chose?
Ce serait une bonne idée, mais vous devriez faire glisser certaines dépendances pour effectuer un rendu sur bitmap, par exemple Batik si vous utilisez Java. Naturellement, l'introduction d'une nouvelle bibliothèque complexe augmente la surface d'attaque; il peut être judicieux d'exécuter la vignette en tant que tâche démon distincte à faible priorité de compte à faible privilège.
Toute action effectuée par votre application Web est potentiellement dangereuse. Le téléchargement de fichiers est l'une des fonctionnalités les plus dangereuses car elle peut conduire à l'exécution de code à distance.
Le problème avec le téléchargement de n'importe quel fichier sur le serveur est qu'il peut ne pas s'agir du fichier que vous souhaitez. Je ne sais pas quelle plateforme ou méthodologie vous utilisez, mais j'ai trompé plusieurs fois les systèmes de téléchargement de fichiers pour télécharger un fichier .php ou .asp et l'exécuter. Il ne semble pas que vous rendiez le SVG côté serveur (ce serait un peu étrange de toute façon), donc le XML brut dans le SVG n'a pas vraiment d'importance pour votre serveur.
En termes de # 2, oui les vulnérabilités de corruption de mémoire svg sont courantes et je suis convaincu qu'il en existe d'autres. Mais encore une fois, cela va être vrai pour à peu près n'importe quel fichier que vous téléchargez. Les images SVG sont un peu plus récentes et la majeure partie des vulnérabilités des images SVG ont été trouvées en 2011.
Le masquage SVG est utilisé pour masquer les iframes dans une attaque de détournement de clics . Mais je ne pense pas que ce vecteur d'attaque s'applique à votre système de téléchargement de svg.