- Shipped
- 23 settembre 2026 alle ore 10:10 UTC
- Author
- Kamo
- Commit
- d8971bc
Ho sempre risposto con la risposta. Contenuti-Tipo da upload, no Content-Disposition, no X-Content-Type-Options e nessun CSP. ChatAttachmentService's upload consent-list ammette l'immagine/* compreso l'immagine/svg+xml, e un documento SVG può trasportare un <script> - così un allegato memorizzato come immagine/svg+xml e aperto da URL eseguito come il documento della risposta, sull'host di kamo-internal dove il *** cookie è httpOnly:false (prod già tenuto tre allegati di chat SVG). La chat la propria <img> della bolla si rifiuta già di inline SVG Percio' questo era solo... raggiungibile aprendo l'URL dell'allegato direttamente, non attraverso il normale chat view - ma l'URL è esattamente ciò che un "download"/"open" offre su una chip di attacco non immagine deve collegarsi a. Il punto finale invia sempre X-Content-Type-Opzioni: nosniff e un restrittiva Content-Security-Policy (default-src 'none'; sandbox; ...), e aggiunge Content-Disposition: allegato per qualsiasi cosa al di fuori di una piccola lista di tipi di immagini raster più audio/* e video/* (che tramite Range-stream questo stesso endpoint e deve rimanere in linea per continuare a giocare). Niente nel consent-list cambiato - SVG, PDF e qualsiasi altro caricamento a forma di documento ancora successo, non possono più rendere come una pagina quando qualcuno apre il URL dell'allegato. il relè di kamo-internal di questo percorso E' solo un'anticipazione. Percio'... attualmente spoglia queste nuove intestazioni prima che raggiungano un browser - per il coordinatore da risolvere da quella parte; questo impegno è il mediaservice metà. Coperto da ImagingProxyContentSecurityTest (mutazione-controllata: ritorsione nuovo blocco intestazione gira tutte e quattro le affermazioni rosse).