- Navios
- 23 de setembro de 2026 às 10:10 UTC
- Autor
- Kamo
- Enviar
- d8971bc
GET/HEAD ************* sempre respondeu com o tipo de conteúdo declarado pelo cliente do upload, sem Disposição de Conteúdo, não X-Content-Type-Options e sem CSP. ChatAttachmentService's upload allow- list admite imagem/* incluindo imagem/svg+xml, e um documento SVG pode <script> - então um anexo armazenado como image/svg+xml e aberto por URL executado como o próprio documento da resposta, no host do kamo-internal onde o cookie *** é httpOnly:false (prod já tinha três anexos de chat SVG). A conversa o próprio <img> da bubble já se recusa a inserir SVG Então isto foi apenas... alcançável abrindo diretamente o URL do anexo, não através do normal chat view - mas o URL é exatamente o que um "download" / "abre" O chip de fixação não-imagem tem de se ligar. O endpoint agora sempre envia opções tipo X-Content: nosniff e a Conteúdo-Segurança-Política restritiva (padrão-src 'nenhum'; sandbox; ...), e adds Content-Disposition: anexo para qualquer coisa fora de uma pequena lista de permissões de tipos de imagem raster mais áudio/* e vídeo/* (que Range-stream através este mesmo endpoint e deve permanecer em linha para continuar jogando). Nada no allow-list changed - SVG, PDF e qualquer outro envio em forma de documento sucesso, eles apenas não podem mais renderizar como uma página quando alguém abre o URL do anexo. O relé interno de kamo desta rota Apenas para a frente. ********************** atualmente tira estes novos cabeçalhos de volta antes de alcançar um navegador - sinalizado para que o coordenador fixe nesse lado; este commit é o meio serviço de comunicação social. Coberto por ImagingProxyContentSecurityTest (mutação-checked: revertendo o o novo bloco de cabeçalho torna as quatro asserções vermelhas).