È possibile iniettare HTML nell'immagine per provocare XSS?

Sono abbastanza sicuro che bstpierre stia parlando di una situazione in cui consente agli utenti di caricare le immagini da visualizzare in una galleria e inoltre si visualizzano i meta-dati su quell'immagine presa dai tag EXIF. Se i tag EXIF sono stati specificatamente costruiti con tag html dannosi e non ci sono stati risanamenti di input (ad esempio, caratteri di escape come < , > , & , quindi vengono visualizzati nella pagina come < > , &amp ) potresti teoricamente usarli per un attacco XSS. Ancora una volta, non è un problema se la tua app web disinfetta tutti gli input dell'utente, inclusi i tag estratti dai file di immagine.

bobince parlava di alcune cose totalmente diverse; la cosa più vicina è che qualcuno carica un file - dice fake_image.jpg ma invece di essere un'immagine, il contenuto è in realtà un file html. Con lo sniffing dei contenuti, voleva dire che alcuni browser, quando fai clic per aprire una pagina link possono capire che fake_image.jpg non è un'immagine ma invece un file html e visualizzerà la pagina html nel file. Pertanto, il file html caricato (con un nome file immagine) potrebbe essere utilizzato in un attacco XSS. Affinché questo attacco sia utile, devi avere un browser che permetta questo tipo di sniffing dei contenuti, e quindi devi andare all'URL dell'immagine (non solo avere <img src='fake_image.jpg'> incorporato nella pagina).

Purtroppo hai indovinato. Questi attacchi sono possibili, senza un bug del browser; sfruttano un difetto di progettazione in molti browser precedenti. Ti consigliamo di leggere su attacchi di sniffing di tipo contenuto MIME e attacchi correlati. Di questo c'è scritto molto:

• Protezione di sniffing MIME

• Perché dovrei limitare il tipo di contenuto dei file da caricare sul mio sito?

• Uso dell'estensione di file e del tipo MIME (come output per file -i -b) per determinare i file non sicuri?

• È sicuro servire qualsiasi file caricato dall'utente sotto i soli tipi di contenuto MIME elencati in bianco?

• X-Content-Type-Options previene realmente gli attacchi di sniffing dei contenuti?

• Come posso essere protetto dalle vulnerabilità delle immagini?

Un SVG in linea in HTML può contenere gestori di eventi e nodi di script SVG. Quindi, se riesco a specificare un'immagine SVG per la pagina da caricare, e ti faccio inline nella pagina, posso inserire lo script tramite quell'immagine.

Le specifiche HTML5

The svg element from the SVG namespace falls into the embedded content, phrasing content, and flow content categories for the purposes of the content models in this specification.

...

The semantics of SVG elements are defined by the SVG specification and other applicable specifications. [SVG]

Mario Heiderich ha sfruttato la confusione in Opera su quale dominio SVG dovrebbe essere eseguito per creare un immagine che quando caricato cross-domain attacca vari livelli e finisce per chiamare il suo telefono.

Wrap-Up

• SVGs are not just images but mini-applications
• tags can now deploy Java, PDF and Flash – and call you on Skype
• In-line SVG creates small XML islands enabling XML attacks on HTML websites
• SVG and XSLT work too, enabling DoS and other attacks
• Web-security and XML security, they meet again!
• And XXE is back – remember 2002's advisories?
• SVG is not getting enough attention in the security community
• SVG provides a lot of room for more security research

Nelle diapositive precedenti, Mario discute in modo specifico XSS e problemi con il download di file SVG da eseguire localmente e note

• Allowing SVG for upload == allowing HTML for upload

È possibile scrivere poliglotti - i file che sono validi in più lingue come un file che è sia una pagina HTML sia un'immagine JPEG GIF e un programma JavaScript . Questa seconda pagina spiega:

the image above is a perfectly valid GIF file just as it is a perfectly valid javascript program (in fact – it’s even a valid Caja program!). An image tag expects its src attribute to point to content which parses correctly as an image, just as a script tag expects its src attribute to point to a javascript file. The tag specifies a context in which content of a particular type is expected. If the only information a browser used to render content was the context created for it by the surrounding tag, things would be simple. But things in the browser world are never simple. When a server sends a file, it also sends that file’s MIME type in a Content-Type header. All is well when the Content-Type the server asserts is consistent with the expected context in which that content gets used. What happens when the server does not send a Content-Type? What happens when a file with one Content-Type is sent when a different type is expected?

...

Browsers perform content-sniffing ostensibly in the interest of usability so even badly configured servers can continue to “work”. The problem here is that a browser gives different types of content different amounts of access. If you can fool the browser into thinking one type of content is actually another you can bypass the restrictions placed on the actual content’s access. For example, an HTML page is allowed to load external images, stylesheets and scripts. In this case the security context these resources execute in is derived from the URL of the page that these resources are embedded in. On the other hand, if the type of content being loaded is Flash or Java applet say, the security context is derived from the URL of the applet object itself. If the browser uses heuristics and gets confused between a Flash object and an image, there are real security implications! It was this type of confusion which was the source of the GIFAR attack.