- Verschifft
- 23. September 2026 um 10:10 UTC
- Autor
- Kamo
- Ausschuss
- d8971bc
GET/HEAD **************** Client-deklarierter Content-Type vom Upload, keine Content-Disposition, nein X-Content-Typ-Optionen und kein CSP. ChatAttachmentServices Upload-Genehmigungsliste Zulassung von image/* inklusive image/svg+xml, und ein SVG-Dokument kann eine <script> - also ein als image/svg+xml gespeicherter und geöffneter und von URL geöffnet als das eigene Dokument der Antwort, auf kamo-internal Host, wo die *** Cookie ist httpOnly:false (Prod hat bereits drei SVG-Chat-Anhänge gespeichert). Der Chat Blase's eigene <img>" weigert sich bereits, SVG inline ******************** also war das nur erreichbar durch Öffnen der URL des Anhangs direkt, nicht durch die normale Chat-Ansicht - aber die URL ist genau das, was eine "download" /"" Ermhung auf einem zu dem nicht-image attachment Chip zu verlinken muss. Der Endpunkt sendet jetzt immer X-Content-Typ-Optionen: nosniff und a restriktive Content-Security-Policy (default-src 'none'; Sandbox; ...) und fügt Content-Disposition hinzu: Anlage für alles außerhalb einer kleinen Genehmigungsliste von Raster-Bildtypen plus Audio/* und Video/* (die Range-Stream durch dieser gleiche Endpunkt und muss inline bleiben, um weiter zu spielen). Nichts in der allow-list geändert - SVG, PDF und jede andere dokumentenförmige Upload-Füllung gediene, sie können einfach nicht mehr als Seite machen, wenn jemand die Die URL des Anhangs. Kamo-internal's eigene Relais dieser Route **************** nur vorwärts **************** so es derzeit Streifen diese neuen Header wieder aus, bevor sie einen Browser erreichen - markiert für den Koordinator auf dieser Seite zu fixieren; diese Verpflichtung ist die mediaservice halb. Abgedeckt durch ImagingProxyContentSecurityTest (mutation-geprüft: rückgängig machend neuer Kopfblock färbt alle vier Behauptungen rot).