Exploit o altri rischi per la sicurezza con il caricamento di SVG?

Could an SVG be constructed in such way, that when reading meta data it makes the server unresponsive. and could be used as DoS attack on the server?

Che cosa intendi per metadati? Se si ha bisogno di larghezza e altezza, è necessario analizzare i file SVG almeno parzialmente per ottenerlo; non c'è scorciatoia di leggere alcuni byte dall'intestazione come se ci fosse con molti formati bitmap. Ciò comporta i soliti rischi dell'analisi XML, come ad esempio:

• attacchi di inclusione di entità esterna / sottoinsieme DTD a file remoti, risorse sensibili della rete locale, file sensibili alla macchina locale e file di dispositivo
• bombe ad espansione di entità nidificate
• le strutture di tag nidificate patologicamente potrebbero raggiungere i limiti delle risorse di ricorsione

come precauzione standard disabiliteresti tutte le elaborazioni DTD, XInclude, XSL, XSI e la risoluzione delle entità.

Could an SVG be constructed in such way, that when rendering the SVG on the client, the client becomes unresponsive and potentially makes every users browser on my site crash?

Forse, ma è possibile che ciò possa accadere con un formato bitmap. Vedi ad esempio le vulnerabilità dei file PNG corrotti di un po 'di tempo fa.

Un altro motivo di preoccupazione per i file SVG è che possono includere JavaScript, che funzionerà nel contesto di sicurezza del sito di hosting, quindi è necessario preoccuparsi degli script cross-site.

In realtà tutti i tipi di file caricati sono vulnerabili a questo, anche se non in modo diretto e facile da sfruttare. In alcuni casi i browser (in particolare IE) li sniffano, e se vedono cose che assomigliano a tag potrebbero potenzialmente reinterpretarli come HTML, incluso JavaScript. Inoltre ci sono alcuni problemi secondari nel trattare i file caricati come applet Java e file di policy di Flash.

La mitigazione standard per tutti questi problemi è di servire le risorse non affidabili, sia bitmap, SVG o qualsiasi altra cosa, da un dominio diverso al tuo sito principale: un dominio che non ha informazioni sensibili di sessione (cookie / auth) in esso e nessuna possibilità di script nel dominio del tuo sito principale.

Also, would it be good practice to generate a small (200x200px) PNG for a thumbnail, or is it better to just manipulate the SVG itself with a zoom factor or something?

Sarebbe un bel tocco, ma dovresti trascinare alcune dipendenze per renderizzare in bitmap, ad esempio Batik se stai usando Java. Portare naturalmente in una nuova libreria complessa aumenta la superficie di attacco; potrebbe essere una buona idea lanciare il thumbnailer come attività demone a bassa priorità con account a basso privilegio separato.

Qualsiasi azione eseguita dalla tua applicazione web è potenzialmente pericolosa. Il caricamento di file è una delle funzionalità più pericolose perché può portare all'esecuzione di codice in modalità remota.

Il problema con il caricamento di qualsiasi file sul server è che potrebbe non essere effettivamente il file che desideri. Non so quale piattaforma o metodologia si sta utilizzando, ma ho ingannato i sistemi di upload di file molte volte per caricare un file .php o .asp ed eseguirlo. Non sembra che tu stia facendo SVG sul lato server (sarebbe comunque strano), quindi il raw XML all'interno di SVG non ha importanza per il tuo server.

In termini di # 2, sì le vulnerabilità di corruzione della memoria di svg sono comuni e io Sono fiducioso che più esiste. Ma ancora una volta questo sarà vero per quasi tutti i file che carichi. Le immagini SVG sono un po 'più recenti e la maggior parte delle vulnerabilità nelle immagini SVG trovate nel 2011.

SVG mascheramento viene utilizzato per iframe oscuri in un attacco clickjacking . Ma non penso che questo vettore di attacco si applichi al tuo sistema di upload svg.