Propriedade de Domínio do Polyfill.io e Responsabilidade de Sites

Resumo

Um site que carregavacdn.polyfill.iofez mais do que citar um projeto de código aberto. Ele permitiu que um serviço remoto ao vivo selecionasse JavaScript e o retornasse para execução no contexto do navegador do site. O objeto de confiança, portanto, incluía o domínio, operador, roteamento e caminho de resposta, não apenas o código-fonte que poderia ser inspecionado em outro lugar. [15][16][17]
O controle do domínio Polyfill.io e da presença associada do projeto mudou em fevereiro de 2024. Fastly, Cloudflare e uma issue do projeto FormatJS reagiram na época, mostrando que a reavaliação a jusante era possível antes que a entrega maliciosa fosse publicamente relatada em junho. A transferência em si não deve ser descrita como prova de intenção maliciosa. [2][3][4]
A Sansec relatou em 25 de junho que o serviço estava retornando seletivamente JavaScript modificado que redirecionava visitantes qualificados. A Cloudflare disse que os indicadores do Page Shield incluíam correspondências desde 8 de junho, enquanto a Akamai descreveu amostragem no lado do servidor seguida por verificações no lado do cliente. Essas observações estabelecem uma campanha de redirecionamento, não todas as ações que o JavaScript fornecido remotamente poderia teoricamente realizar. [1][5][9]
A estimativa da Sansec de mais de 100.000 sites referia-se a sites que incorporavam ou usavam o serviço. A Cloudflare citou uma estimativa de uso próxima a quatro por cento dos sites. Nenhum dos números é uma contagem verificada de sites que serviram o ramo malicioso, redirecionaram visitantes ou sofreram perdas. [1][5]
A reescrita automática da Cloudflare e a retenção do domínio pela Namecheap restringiram o caminho de entrega. Elas não removeram referências obsoletas do código a jusante, estabeleceram o que cada visitante anterior recebeu ou completaram a investigação de cada proprietário de site. [5][6][10]
Fides, Jellyfish e Wordfence ilustram três tarefas de evidência diferentes: determinar se um caminho condicional era alcançável, rastrear um fornecedor transitivo, verificar a remoção e evitar tratar uma referência ao endpoint como prova de exploração. [11][12][13][14][22]
Responsabilidade aqui não é uma conclusão legal ou uma afirmação de culpa igual. Significa que cada parte deve ser responsável pelos controles que realmente poderia exercer. Os proprietários de sites mantiveram o controle sobre necessidade, inventário, escolha do provedor, auto-hospedagem, monitoramento de propriedade, observação no lado do navegador, investigação, reparo e comunicação.

Uma tag script delegou autoridade, não apenas conveniência

A decisão técnica central parecia comum. Um site colocava um elementoscriptem uma página e o apontava paracdn.polyfill.io. Quando um visitante carregava essa página, o navegador solicitava JavaScript do serviço remoto. O serviço podia inspecionar características da solicitação e fornecer polyfills adequados ao navegador, permitindo que navegadores mais antigos usassem recursos da web que não implementavam nativamente.

Esse arranjo resolvia um problema prático de compatibilidade. Em vez de enviar todas as funções de compatibilidade para todos os visitantes, um site podia pedir a um serviço especializado que retornasse o que um navegador específico parecia precisar. O resultado podia ser menor e mais fácil de manter do que um pacote local universal. Mas a eficiência vinha de manter a resposta dinâmica. O site não apenas baixava um pacote fixo durante o desenvolvimento e implantava bytes revisados de sua própria infraestrutura. Ele convidava outro operador a decidir, no momento do carregamento da página, quais bytes um visitante executaria.

A distinção determina o quadro de responsabilidade. Um repositório de código aberto é código e histórico inspecionáveis. Um serviço hospedado é um relacionamento operacional. O serviço ao vivo depende de um domínio, DNS, roteamento, hospedagem, certificados, acesso de implantação e das pessoas ou organizações capazes de alterar a resposta. Um site pode confiar no código público enquanto ainda falha em examinar se o endpoint que atende seus visitantes permanece sob o mesmo controle, segue o mesmo processo ou retorna o mesmo tipo de saída.

HTTPS não elimina essas questões. Ele pode ajudar um navegador a autenticar que alcançou o detentor de autoridade válida para o domínio solicitado e proteger a resposta em trânsito. Não promete que o detentor do domínio não mudou, que o programa retornado é benevolente ou que o conteúdo é invariável entre solicitações. Quando o controle do domínio muda legitimamente, o HTTPS pode continuar funcionando exatamente como projetado, autenticando uma nova realidade operacional.

O navegador dá ao JavaScript carregado remotamente uma extensa influência prática sobre a página que o inclui. O alcance preciso depende da página e dos controles do navegador, mas a fraqueza básica é bem estabelecida: funcionalidade de terceiros executa dentro do contexto web da primeira parte. O CWE-830 do MITRE descreve essa classe de inclusão como uma transferência de confiança para código de outro domínio, e o OWASP trata o JavaScript de terceiros como um problema de governança porque pode afetar dados e comportamento da página. A orientação do GitHub CodeQL aplica a mesma lógica à funcionalidade carregada de um domínio não confiável.

[15][16][17]

É por isso que o incidente não deve ser reduzido a "código aberto se tornou inseguro". O código aberto original, uma cópia auto-hospedada revisada e um serviço ao vivo controlado por domínio eram objetos de confiança distintos. Um site usando uma cópia local fixa não fazia a mesma delegação em tempo de execução que um site solicitando uma resposta variável decdn.polyfill.io. Um host alternativo também criava um relacionamento operacional diferente, mesmo que servisse código derivado do mesmo projeto.

A primeira questão de responsabilidade, portanto, não é se os desenvolvedores devem desconfiar de toda biblioteca externa. É se o site sabia qual parte podia escolher bytes executáveis para seus visitantes no momento do uso. Um inventário útil responderia a pelo menos cinco perguntas: quais páginas solicitavam o script, se a inclusão era direta ou transitiva, quais usuários e caminhos de navegador podiam alcançá-lo, que função de negócio o exigia e quem atualmente controlava o endpoint.

Essas perguntas pertencem ao proprietário do site porque o site tornou a inclusão efetiva. Um visitante não negociou com o Polyfill.io ou escolheu seu operador. O visitante solicitou uma página do site e razoavelmente experimentou os scripts retornados como parte dessa página. Mesmo onde um tema, plugin, gerenciador de tags ou fornecedor inseriu a referência, a organização downstream continuava sendo a parte que apresentava a experiência combinada aos seus usuários.

Isso não torna o proprietário do site o autor do código malicioso nem apaga o controle do operador do serviço. Significa que poder delegado não elimina a responsabilidade da primeira parte. O operador do serviço podia escolher a resposta. O proprietário do site podia escolher se esse operador mantinha um lugar na página. Esses são controles diferentes, e o incidente testou ambos.

A transferência de fevereiro foi um evento de governança de software

A cronologia pública fornece um intervalo de aviso excepcionalmente importante. Em fevereiro de 2024, o controle do domínio Polyfill.io e da presença associada no GitHub mudou para a Funnull, conforme descrito nas fontes contemporâneas. As fontes estabelecem uma mudança no controle e na base de confiança. Elas não estabelecem, por si só, o motivo do novo operador, um plano criminoso, uma violação legal ou a identidade final de cada pessoa que posteriormente influenciou a entrega.

Para um site informacional convencional, uma transferência de domínio pode alterar principalmente a autoridade de publicação. Para um domínio que retorna JavaScript executável para outros sites, a transferência altera quem pode influenciar o software em execução nessas páginas downstream. Isso torna a informação de propriedade parte do estado da dependência. Um novo proprietário do endpoint é operacionalmente comparável a um novo mantenedor, autoridade de assinatura ou canal de lançamento, mesmo quando o repositório de origem parece familiar.

O aviso da Fastly em 28 de fevereiro torna visível o significado de governança. Anunciou domínios de substituição e deu aos usuários opções que incluíam migrar, auto-hospedar ou remover o serviço. Essas opções não eram meramente alternativas de marca. Cada uma mudava quem controlaria os bytes entregues aos visitantes. A migração selecionava um relacionamento de serviço diferente. A auto-hospedagem colocava a entrega sob os próprios controles de implantação do site. A remoção eliminava a dependência de compatibilidade se não fosse mais necessária. [3]

A Cloudflare seguiu em 29 de fevereiro com uma alternativa hospedada no cdnjs. Sua explicação conectou a transição do provedor ao risco da cadeia de suprimentos: sites confiaram em outra parte para manter e proteger um serviço que podia executar código em suas páginas. A alternativa da Cloudflare não tornou a hospedagem de terceiros livre de riscos, mas mostrou que os provedores de infraestrutura entendiam a mudança de propriedade como motivo para uma nova decisão de confiança. [2]

Uma issue do FormatJS aberta em 28 de fevereiro fornece um registro de projeto downstream do mesmo período. Levantou preocupações sobre a propriedade e o relacionamento CNAME e pediu ao projeto que parasse de recomendar o endpoint. Esse registro é importante porque mostra um mantenedor agindo sobre uma dependência de documentação antes de uma campanha maliciosa publicamente relatada. Remover uma recomendação não repara todos os sites que a seguiram anteriormente, mas limita a propagação futura e cria um aviso rastreável. [4]

Juntos, esses registros evitam uma narrativa excessivamente conveniente em que os proprietários downstream não tiveram nenhum sinal até 25 de junho. Nem todo proprietário de site teria visto o aviso da Fastly, o post da Cloudflare ou a issue do FormatJS. As fontes não estabelecem aviso universal, e seria injusto converter a disponibilidade pública em prova de que toda organização realmente sabia. Elas estabelecem que a mudança de propriedade era observável, que alternativas estavam disponíveis e que algumas partes responsáveis reavaliaram o endpoint meses antes do relatório do incidente.

Essa distinção é essencial para a responsabilidade. Um dever de monitorar não significa onisciência. Significa projetar um processo que possa receber mudanças relevantes para dependências de alta autoridade. Um site pode rastrear avisos de pacotes enquanto ignora propriedade de domínio, DNS ou mudanças de hospedagem. Para um pacote versionado, feeds de lançamento e vulnerabilidade podem ser os sinais importantes. Para um endpoint de script remoto, registro, DNS, operador e comportamento de resposta também pertencem ao modelo de monitoramento.

O evento de fevereiro também expõe os limites de uma revisão única de fornecedor. Uma equipe pode ter aprovado o Polyfill.io anos antes com base no operador, infraestrutura, reputação do projeto e necessidades de navegador da época. Se o registro de aprovação continha apenas a stringcdn.polyfill.io, a equipe podia tratar erroneamente a dependência como inalterada enquanto a URL permanecesse inalterada. Na realidade, a parte por trás do nome estável havia mudado.

Uma aprovação responsável deve registrar a base da confiança, não apenas o endereço. Essa base podia incluir o operador, propósito do serviço, características esperadas de resposta, relação contratual ou comunitária, evidência de auditoria disponível, plano de contingência e gatilhos de revisão. A transferência de propriedade então invalidaria ou pelo menos reabriria a aprovação. Sem tal registro, uma organização não pode explicar facilmente por que a delegação continuada permaneceu justificada após a premissa mudar.

A questão da necessidade também deveria ter sido reaberta. Polyfills estão ligados à capacidade do navegador. As populações de navegadores evoluem, as políticas de suporte de produtos mudam e o código de compatibilidade que antes era essencial pode se tornar residual. Uma dependência remota com autoridade de nível de página não deve persistir apenas porque ninguém é dono de sua remoção. Os avisos de fevereiro ofereceram um momento para perguntar se o suporte a navegadores antigos ainda exigia o endpoint e se um pacote local menor poderia atender à necessidade restante.

Nada disso prova que todo site que manteve a referência agiu negligentemente, e não transforma a transferência de domínio em si em um ataque. Estabelece um ponto mais restrito: a transferência alterou um controle de software material mesmo antes que a saída prejudicial fosse observada. A responsabilidade do site começa com se essa mudança material era detectável e revisável.

Entrega seletiva tornou a inspeção casual não confiável

Em 25 de junho, a Sansec relatou quecdn.polyfill.ioestava entregando JavaScript modificado através de sites que o incorporavam. O comportamento observado redirecionava visitantes selecionados através de domínios projetados para se assemelhar ao Google Analytics para destinos de golpe ou apostas. A Sansec descreveu condições que incluíam segmentação móvel, verificações no lado do servidor e do cliente, comportamento baseado em tempo e evitação de alguns contextos de administrador ou análise. [1]

O ato observado precisa de um substantivo preciso. Foi uma campanha de redirecionamento entregue através de JavaScript modificado. O registro não suporta a atualização dessa observação para roubo de credenciais, roubo de dados da página, comprometimento do host, execução de código fora do navegador ou perda financeira quantificada. Um endpoint de script controlado remotamente poderia, em princípio, retornar JavaScript capaz de uma gama muito mais ampla de ações no navegador. O CNCF TAG Security, o CWE-830 e o modelo geral de execução do navegador suportam essa conclusão de capacidade.

Capacidade não é evidência de que cada ação possível ocorreu. [8][16]

A Cloudflare disse que seus dados do Page Shield corroboravam os indicadores e incluíam correspondências desde 8 de junho. Essa é a correspondência mais antiga no conjunto de dados da Cloudflare descrito no registro fonte. Não é prova de que toda atividade maliciosa começou nessa data, que o mesmo ramo alcançou todos os sites continuamente a partir de então ou que nenhuma entrega anterior ocorreu fora da visibilidade da Cloudflare. [5]

A Akamai descreveu separadamente um padrão de dois estágios em que a seleção no lado do servidor com base em cabeçalhos de solicitação podia determinar o que era enviado, seguido por verificações no lado do cliente antes do redirecionamento. Essa arquitetura explica por que a inspeção comum podia perder o problema. Um desenvolvedor solicitando o script de um navegador de desktop podia receber um polyfill esperado. Um visitante móvel com cabeçalhos, localização, tempo ou estado de página diferentes podia receber ou ativar outro ramo. [9]

A entrega seletiva muda o ônus da evidência. Um único download limpo não prova segurança histórica. Uma comparação de código-fonte de um navegador em um momento pode mostrar apenas a resposta selecionada para essa solicitação. Um rastreador de mecanismo de busca, monitor de tempo de atividade ou scanner de segurança pode ter características deliberadamente excluídas pela lógica de entrega. Um administrador testando enquanto logado pode ver comportamento diferente de um visitante pela primeira vez.

Isso não significa que a detecção era impossível. Significa que o monitoramento tinha que corresponder à variabilidade da dependência. A observação útil amostraria navegadores, dispositivos, locais e condições de solicitação; preservaria corpos de resposta e hashes ao longo do tempo; detectaria novos domínios e cadeias de redirecionamento; e compararia o comportamento visto por clientes reais com o propósito declarado do serviço. O monitoramento do lado do cliente tinha um papel importante porque o programa consequente era montado e executado no navegador.

O incidente também ilustra como a otimização pode se tornar camuflagem. A segmentação dinâmica do navegador fazia parte do modelo de serviço legítimo do Polyfill.io: o serviço selecionava código de compatibilidade de acordo com as capacidades do navegador. Um ramo malicioso poderia explorar a expectativa de que as respostas naturalmente diferem. A variabilidade em si não era prova de abuso. Tornou um modelo simples de "hash conhecido igual a serviço seguro" mais difícil de aplicar e deu à entrega seletiva espaço para se esconder dentro de um padrão operacional aceito.

A responsabilidade, portanto, depende da definição da variabilidade esperada. Um site deve ser capaz de declarar quais atributos de solicitação o provedor usa legitimamente, quais famílias de código podem ser retornadas, quais destinos o script pode contatar e quais ações da página estão fora do propósito. Sem essa linha de base, o monitoramento pode observar mudanças sem saber se a mudança é autorizada.

A amostragem no lado do servidor também complica a investigação retrospectiva. O repositório estático de um site pode conter apenas a URL do script, não os bytes maliciosos que um visitante recebeu. Os bytes vieram de outro sistema no momento da solicitação e podem não estar mais disponíveis após a contenção. Telemetria do navegador, logs de CDN, respostas salvas, relatórios de segurança de conteúdo e registros de endpoint podem ser a única evidência para reconstruir o alcance. Se esses registros nunca foram coletados ou foram retidos por muito pouco tempo, um site pode ser incapaz de responder quais visitantes encontraram o ramo.

Essa incerteza não deve ser escondida com uma alegação ampla de que todos estavam seguros ou todos foram comprometidos. Uma declaração de incidente responsável pode, em vez disso, definir o que foi encontrado: o endpoint foi referenciado; um caminho condicional particular era alcançável ou não; a telemetria cobria datas e populações especificadas; os redirecionamentos observados correspondiam ou não a indicadores conhecidos; e permanecem lacunas para solicitações fora da evidência retida.

A entrega seletiva é, portanto, central para o teste de responsabilidade. Explica como a saída prejudicial podia coexistir com inspeção benigna, por que referências de endpoint não são contagens de vítimas e por que a remediação verificada requer mais do que carregar a página uma vez após o domínio ter sido suspenso.

Estimativas de escala não eram contagens de vítimas

A Sansec descreveu mais de 100.000 sites como incorporando ou usando o serviço. A Cloudflare citou estimativas de que o Polyfill.io aparecia em quase quatro por cento dos sites. Esses números transmitem a amplitude potencial de um serviço amplamente reutilizado. Eles não compartilham o mesmo denominador, e nenhum estabelece um conjunto completo de comprometimentos confirmados. [1][5]

Várias populações devem permanecer separadas. Uma é o conjunto de sites cujo código atual ou histórico referenciava um endpoint do Polyfill.io. Outra é o conjunto para o qual o caminho de inclusão relevante era alcançável em produção. Uma terceira é o conjunto que solicitou uma resposta maliciosa durante a campanha. Uma quarta é o conjunto cujos visitantes satisfizeram as condições do lado do servidor e do cliente. Uma quinta são os visitantes que foram realmente redirecionados. Uma sexta é qualquer população que sofreu uma perda mensurável posterior.

O registro público disponível não fornece uma contagem verificada para a maioria desses grupos. Portanto, seria impreciso chamar cada referência de vítima, cada site incluinte de comprometido ou cada visitante de exposto. Seria igualmente impreciso descartar referências como inofensivas simplesmente porque a entrega seletiva impedia a observação universal. Uma referência estabelece um caminho de confiança. Evidências adicionais são necessárias para estabelecer alcance, entrega e impacto.

Esse vocabulário é importante para avisos downstream. "Nosso código continha uma referência" é diferente de "nossa telemetria mostra que o script foi solicitado". Ambos diferem de "observamos o ramo malicioso" e de "um visitante relatou um redirecionamento". Combiná-los pode criar alarme desnecessário ou falsa garantia. Separá-los permite que os usuários entendam o que a organização sabe.

O tratamento do Wordfence dos padrões de plugins WordPress afetados reforça esse limite. Seu catálogo identificou usos do Polyfill.io, mas alertou contra assumir que toda instância de plugin entregou conteúdo malicioso. Os plugins podiam introduzir o endpoint em muitos sites, tornando o trabalho de inventário urgente, enquanto a presença do código ainda ficava aquém de provar execução maliciosa em cada instalação. [14]

Relatórios governamentais repetiram a grave preocupação de escala enquanto focavam os operadores na remoção e investigação. O CERT-AGID descreveu a aquisição e a entrega dependente de cabeçalho e referiu-se ao número de mais de 100.000. Esse aviso independente suporta atenção defensiva ampla, mas não transforma o denominador em visitantes afetados confirmados. [21]

A declaração de escala mais forte é, portanto, também a mais delimitada: o endpoint tinha uma grande pegada downstream, e a campanha seletiva observada criou risco através dessa pegada. O impacto exato tinha que ser estabelecido site por site e população de visitantes por população de visitantes.

Contenção mudou o caminho; não concluiu a remediação

A resposta envolveu partes com diferentes tipos de controle. A Cloudflare reescreveu automaticamente as referências do Polyfill.io nas páginas de clientes com proxy para um espelho hospedado pela Cloudflare. A empresa explicou que simplesmente bloquear o domínio original poderia quebrar sites ainda dependentes do serviço. A reescrita tentou preservar a compatibilidade esperada enquanto removia a dependência imediata do endpoint alterado. [5]

Essa intervenção ilustra uma troca operacional real. As equipes de segurança geralmente preferem a remoção imediata de um recurso suspeito. As equipes de produto sabem que eliminar abruptamente uma camada de compatibilidade pode tornar um site inutilizável para alguns visitantes. A posição da Cloudflare na cadeia de entrega permitiu substituir uma fonte diferente sem esperar que todos os proprietários de site implantassem uma alteração.

Substituição foi contenção, não prova de reparo completo. Mudou o operador confiável e o caminho de resposta para o tráfego coberto pelo mecanismo. Não estabeleceu que a substituição tinha comportamento idêntico para todos os navegadores, que todas as páginas e caminhos de entrega estavam cobertos, ou que os repositórios downstream não continham mais a referência antiga. Também não respondeu o que os visitantes receberam antes da reescrita.

A Namecheap então colocou o domínio Polyfill.io em espera, e avisos governamentais descreveram o endpoint como suspenso até 27 de junho. A ação no nível do domínio removeu o caminho de serviço imediato, mas também poderia quebrar sites que ainda esperavam uma resposta. A espera foi uma importante alavanca de contenção detida pelo registrador. Não limpou modelos downstream, configurações de plugins, páginas em cache, configurações de gerenciadores de tags ou produtos de fornecedores. [6][10]

A diferença fica mais clara quando o domínio está indisponível. Um site pode parecer protegido porque o navegador não pode mais recuperar o script suspeito. No entanto, a referência obsoleta permanece uma dependência não resolvida. Se o status de controle mudar novamente, se um nome de host alternativo persistir, ou se uma cópia interna não foi examinada, o problema de governança subjacente permanece. Mesmo um endpoint permanentemente morto pode impor custos de desempenho, tratamento de erros e compatibilidade.

O CERT-FR e a Unidade de Segurança Cibernética da Austrália Ocidental aconselharam os operadores a identificar e remover referências, mover para uma alternativa controlada quando necessário e considerar controles do navegador, como Integridade de Sub-recursos e Política de Segurança de Conteúdo. O Semgrep também focou na detecção em todo o repositório, em vez de tratar a suspensão do domínio como suficiente. [6][7][20]

Essa sequência sugere quatro alegações de encerramento distintas. "Contido" significa que o caminho de entrega prejudicial conhecido foi interrompido. "Removido" significa que a referência downstream e os caminhos de inserção transitivos desapareceram. "Investigado" significa que a evidência disponível foi usada para avaliar o alcance e impacto históricos. "Verificado" significa que testes e monitoramento demonstram que o site atual não depende mais do caminho antigo e que a substituição se comporta dentro de seu escopo pretendido.

Um proprietário de site podia confiar em um provedor de infraestrutura para a primeira alegação enquanto ainda possuía as outras três. A Cloudflare podia reescrever o tráfego que via. A Namecheap podia suspender um domínio que registrou. Nenhum podia saber todos os locais onde um cliente tinha incorporado a URL, todos os caminhos de navegador condicionais dentro de um plugin, ou todas as populações de visitantes que o site precisava investigar.

Essa separação também protege contra exagerar a intervenção de terceiros. Uma retenção de registrador não é uma constatação de atribuição. A reescrita automática não estabelece que todo cliente protegido serviu o ramo malicioso. Uma correspondência de indicador de um fornecedor de detecção não é um relatório forense completo para cada site. Cada ação deve ser descrita de acordo com o controle que exerceu e a evidência que produziu.

Operacionalmente, a remediação downstream deve começar com uma busca completa. O nome de host literal pode aparecer em arquivos fonte, pacotes gerados, campos de gerenciamento de conteúdo, código de plugins, gerenciadores de tags, modelos, configurações arquivadas ou respostas de fornecedores. Ferramentas de busca podem encontrar strings conhecidas, mas um inventário de dependências também deve explicar quem introduziu a referência e qual caminho de construção ou tempo de execução a tornou ativa.

A remoção então precisa de uma decisão funcional. Se o polyfill não é mais necessário, eliminá-lo é a redução de autoridade mais limpa. Se o suporte a navegadores legados ainda é necessário, um pacote local revisado ou um provedor explicitamente aprovado pode ser apropriado. A substituição não deve ser escolhida apenas porque sua URL é conveniente. Seu operador, processo de atualização, variabilidade de resposta e modelo de monitoramento tornam-se parte da nova base de confiança.

Finalmente, a avaliação histórica requer evidências proporcionais ao risco do site. Observações do lado do navegador, logs de rede, relatórios de segurança, reclamações de clientes e respostas de script preservadas podem ajudar a determinar se indicadores de redirecionamento conhecidos apareceram. A ausência de evidência deve estar vinculada à cobertura. Um site sem telemetria retida do cliente pode dizer que não encontrou relatórios ou indicadores nos registros disponíveis; não pode converter registros ausentes em prova de que nenhum visitante recebeu o ramo.

Fides mostrou por que um ramo condicional ainda importa

CVE-2024-38537 registra um problema downstream no Fides. O caminho relevante dofides.jspodia carregar o Polyfill.io para navegadores legados. O registro identifica versões afetadas e diz que a versão 2.39.1 removeu a exposição. Também preserva um limite importante: nenhuma exploração através do Fides havia sido identificada. [11][12]

Esse caso é útil porque resiste a dois erros opostos. O primeiro descartaria o problema porque apenas um caminho de navegador antigo carregava o endpoint. Alcance condicional ainda é alcance. Se uma página de produção podia solicitar JavaScript remoto para uma população de visitantes suportada, a dependência pertencia ao inventário de segurança do produto mesmo que a maioria dos desenvolvedores nunca a acionasse.

O segundo erro trataria o CVE como prova de que os usuários do Fides foram explorados. Um registro de vulnerabilidade pode estabelecer um caminho de inclusão inseguro e versões afetadas sem estabelecer que o ramo malicioso alcançou uma implantação específica. "Podia carregar" e "foi observado explorando" respondem a perguntas diferentes. O registro do Fides manteve explicitamente essa distinção.

A remediação também demonstra por que o reparo versionado é importante. Remover a dependência remota em um lançamento nomeado dá aos operadores downstream uma ação concreta e um limite rastreável. Eles podem identificar versões implantadas, atualizar, escanear referências restantes e testar o caminho legado. Um aviso geral para "ter cuidado com o Polyfill.io" não forneceria a mesma evidência de encerramento.

A condição legada deve moldar a verificação. Testar apenas um navegador desktop moderno pode nunca executar o ramo afetado. A verificação deve reproduzir ou inspecionar a condição que originalmente o selecionava. Isso pode exigir revisar código empacotado, simular um agente de usuário mais antigo, verificar solicitações de rede e confirmar que a versão reparada não constrói ou solicita mais o endpoint.

O boletim do SingCERT também discutiu o caso downstream do Fides e reteve o limite de nenhuma exploração observada. A repetição por um CERT nacional aumenta a visibilidade do problema; não converte a possibilidade em exploração observada. [22]

A lição do Fides, portanto, não é que toda solicitação condicional de terceiros merece a mesma gravidade. É que um mantenedor deve conhecer a condição, versões afetadas, população alcançável, versão de remediação e limite de evidência. A responsabilidade é mais forte quando um registro formal de vulnerabilidade diz tanto o que poderia acontecer quanto o que não foi observado.

Jellyfish mostrou como rastrear uma dependência transitiva

O aviso da Jellyfish documentou um caminho diferente. Seu serviço dependia de um fornecedor que podia carregar o Polyfill.io sob condições especiais. A Jellyfish identificou o relacionamento transitivo, contatou o fornecedor, verificou a remoção e delimitou a população de navegadores que podia ter alcançado o caminho. [13]

Essa sequência é um modelo prático porque começa com a arquitetura, não com a acusação. Uma organização voltada para o cliente pode não ter colocado a tag script diretamente em seu próprio repositório. A referência pode vir de um componente de análise, ferramenta de consentimento, plugin, widget de suporte ou outro código de fornecedor. A propriedade direta da linha não é o mesmo que controle sobre a experiência do usuário.

Dependências transitivas criam um problema de evidência. Uma lista de materiais de software orientada para pacotes instalados no momento da construção pode não incluir um domínio que um fornecedor solicita dinamicamente no navegador. Os inventários de contrato podem nomear o fornecedor, mas não os próprios fornecedores de script do fornecedor. O monitoramento de rede pode ver o nome de host sem identificar o proprietário do negócio que o introduziu. Todas as três visões são necessárias para conectar uma solicitação a um relacionamento responsável.

A sequência de resposta da Jellyfish aborda essas lacunas. Primeiro, identificar que a dependência existe e as condições sob as quais pode ser invocada. Segundo, mapeá-la para o relacionamento com o fornecedor. Terceiro, pedir à parte com controle de código que a remova. Quarto, verificar a mudança em vez de tratar a garantia do fornecedor como o fim da questão. Quinto, delimitar a população usando a melhor evidência disponível de navegador e produto.

A verificação é especialmente importante quando a condição é incomum. Um fornecedor pode remover uma referência visível enquanto um fallback, pacote antigo ou ativo em cache ainda a contém. O cliente deve testar de fora, além de aceitar a confirmação interna. A captura de rede em navegadores relevantes, varreduras de repositório ou pacote e monitoramento do lado do cliente podem mostrar se a solicitação realmente desapareceu.

A população delimitada deve reter seu denominador. Se apenas certas versões de navegador ou fluxos de página podiam acionar o caminho do fornecedor, a investigação pode restringir o alcance potencial. Não deve implicar que todo membro desse grupo de navegadores recebeu conteúdo malicioso. Por outro lado, o fato de um caminho ser raro não desculpa a falha em removê-lo. Caminhos raros geralmente recebem menos testes de rotina, o que pode torná-los lugares atraentes para dependências persistirem despercebidas.

A Jellyfish também demonstra responsabilidade compartilhada, mas não fungível. O fornecedor controlava seu código e podia remover a inclusão. A Jellyfish controlava a escalação do fornecedor, a investigação voltada para o cliente e a aceitação do reparo. Provedores de infraestrutura e segurança podiam contribuir com telemetria. Nenhuma dessas partes podia substituir completamente outra.

Esse modelo escala além deste incidente. Uma organização downstream precisa de uma rota de escalação para qualquer fornecedor capaz de introduzir código executável. O contrato ou processo de integração técnica deve identificar quem pode responder a perguntas urgentes sobre dependências, com que rapidez um script de terceiros pode ser desabilitado, quais logs estão disponíveis e como o cliente pode verificar uma mudança.

Plugins WordPress mostraram por que referências e exploração devem permanecer separadas

O Wordfence catalogou o uso do Polyfill.io em vários padrões de plugins WordPress. Esse tipo de inventário é valioso porque os plugins podem distribuir uma dependência externa por muitos sites operados independentemente. Uma pequena decisão de mantenedor pode se tornar um amplo relacionamento de confiança downstream sem que cada proprietário de site adicione conscientemente o endpoint. [14]

O catálogo também trazia um aviso crucial: o uso do endpoint não provava que todo plugin ou site entregava conteúdo malicioso. A referência identificava um caminho de execução potencial. Se esse caminho estava ativo dependia da versão do plugin, configuração, renderização da página, cache, condições do navegador e da resposta remota no momento.

Para um proprietário de site WordPress, a resposta correta não é debater se o autor do plugin ou operador do serviço é "a" parte responsável. As tarefas imediatas são locais: identificar versões instaladas e ativas, determinar quais páginas renderizam a referência, atualizar ou remover componentes afetados, limpar ativos gerados quando necessário e verificar o comportamento de rede do site público.

O mantenedor do plugin tem um conjunto diferente de tarefas. Pode remover a dependência, publicar uma versão corrigida, explicar condições afetadas, atualizar a documentação e notificar os usuários. Um repositório de plugins ou serviço de segurança pode distribuir avisos. O proprietário do site ainda tem que implantar a mudança. Um lançamento corrigido sentado sem instalação não altera o caminho do navegador.

Esta é outra razão pela qual os números de escala não devem ser lidos como uma contagem de organizações prejudicadas. Um plugin pode criar milhares de referências; um site pode conter vários plugins com o mesmo nome de host; um plugin inativo ou desabilitado pode permanecer no disco sem renderizar o script; e uma página pública em cache pode continuar servindo uma referência antiga após mudanças no código-fonte. Contar strings, instalações, solicitações ativas e entregas maliciosas produz números diferentes.

Um ecossistema responsável mantém essas medidas rotuladas. A inteligência de segurança pode publicar uma lista ampla de exposição para acelerar a ação. Os mantenedores podem declarar versões afetadas. Os proprietários de sites podem relatar a alcançabilidade implantada. Os investigadores de incidentes podem relatar indicadores observados. Nenhum deve emprestar certeza dos outros.

SRI e CSP eram controles, não respostas mágicas

A Integridade de Sub-recursos (SRI) permite que um autor de página forneça um resumo criptográfico para um recurso externo. Um navegador compatível pode buscar o recurso e se recusar a executá-lo se os bytes retornados não corresponderem ao resumo esperado. A especificação do W3C e o guia de implementação do MDN apresentam o SRI como uma forma de impedir que um host de terceiros comprometido altere silenciosamente um recurso que o site incluinte espera que permaneça fixo. [18][19]

Esse é um controle forte para um script estável. Converte uma delegação aberta em aprovação de bytes específicos. Se o host retornar qualquer outra coisa, o navegador bloqueia a execução. O site pode então atualizar o resumo através de seu próprio processo de implantação após revisar uma nova versão.

O design legítimo do Polyfill.io complica esse modelo porque o serviço intencionalmente gerava pacotes diferentes de acordo com as capacidades do navegador e parâmetros de solicitação. Um resumo estável não pode aprovar muitas sequências de bytes válidas, a menos que o site mude como consome o serviço. Uma equipe podia pré-calcular e aprovar um conjunto limitado de recursos fixos em algumas arquiteturas, mas anexar um hash a um endpoint cujo propósito é a seleção dinâmica de resposta provavelmente quebraria o comportamento esperado ou deixaria variação importante não vinculada.

A conclusão correta não é que o SRI é inútil. É que a escolha de controle deve corresponder ao modelo de recurso. Se um site quer fixação de integridade, pode precisar parar de pedir a um serviço remoto que gere bytes arbitrários específicos da solicitação. Auto-hospedar um pacote revisado, servir variantes fixas versionadas ou restringir navegadores suportados pode tornar a aprovação no nível de byte prática.

A Política de Segurança de Conteúdo (CSP) aborda uma camada diferente. Uma política pode restringir quais origens podem fornecer scripts e pode usar nonces, hashes ou diretivas relacionadas para limitar a execução. Pode bloquear domínios inesperados e reduzir a liberdade de marcação injetada para carregar novos recursos. Mas secdn.polyfill.ioé explicitamente permitido como uma origem de script confiável, uma resposta maliciosa aprovada pela origem não se torna confiável por aparecer na lista de permissões.

A CSP ainda pode ajudar a conter o comportamento secundário. Uma política cuidadosamente projetada pode restringir conexões, frames ou navegações envolvidas em uma cadeia de ataque, e relatórios de violação podem adicionar evidência de detecção. O efeito exato depende da política e do comportamento do navegador. A limitação central permanece: a aprovação de origem responde de onde o código pode vir, não se o operador aprovado sempre retornará código aceitável.

O espelhamento move novamente o limite de confiança. Um site ou provedor de infraestrutura busca ou mantém uma cópia e a serve de um local controlado. Isso pode impedir que o domínio original mude bytes no momento da solicitação. Também cria obrigações sobre como o espelho é obtido, revisado, atualizado e protegido. A reescrita automática para o espelho da Cloudflare foi uma contenção útil, mas selecionou a Cloudflare como a nova autoridade operacional; não eliminou o conceito de confiança.

A auto-hospedagem dá ao proprietário do site um controle mais direto sobre a entrega. Pode revisar uma versão, implantá-la com a aplicação e monitorar mudanças através de seu processo normal de lançamento. A auto-hospedagem não garante código seguro. Estreita quem pode alterar a resposta de produção e torna os bytes implantados mais fáceis de vincular a um lançamento.

A remoção é mais forte quando a função é desnecessária. Se o suporte atual do navegador não requer mais um serviço de polyfill, o script remoto de menor risco é aquele que a página não solicita. É por isso que a revisão do ciclo de vida pertence junto com os controles de segurança. Decisões de compatibilidade tomadas anos antes não devem se tornar concessões de autoridade permanentes.

O sandboxing pode reduzir alguma influência de terceiros quando a funcionalidade pode ser executada em um frame restrito ou contexto isolado. Nem todo script pode ser movido para lá sem alterar o produto. Um polyfill destinado a modificar o ambiente JavaScript da página está especialmente vinculado ao contexto de execução principal, o que limita a utilidade do isolamento. Essa limitação deve influenciar se a conveniência continua valendo a autoridade.

Ferramentas de varredura de código ajudam a encontrar referências conhecidas. A orientação específica do Polyfill do CodeQL enfatiza diligência de propriedade, revisão de logs, auto-hospedagem e as limitações dos controles de integridade para conteúdo dinâmico. O Semgrep propôs buscas em repositório e regras para identificar o uso do Polyfill.io após o incidente. [15][20]

A varredura estática sozinha é incompleta porque a injeção em tempo de execução pode vir de sistemas de conteúdo, gerenciadores de tags ou fornecedores. A observação em tempo de execução sozinha é incompleta porque condições raras podem não ocorrer durante a amostra. Uma pilha de controle madura combina varredura de fonte e pacote, um inventário de scripts de terceiros, monitoramento de DNS e propriedade, telemetria do lado do navegador, revisão de mudanças e um mecanismo de desativação de emergência.

A pilha também deve especificar o comportamento de falha. Se um polyfill falha ao carregar, a página perde um aprimoramento menor, torna-se inutilável ou impede uma transação crítica? Equipes que entendem o impacto da falha podem remover ou bloquear um recurso suspeito rapidamente sem improvisar durante um incidente. Se a continuidade depende do recurso, um fallback local testado é mais seguro do que descobrir a dependência quando um registrador suspende o domínio.

Os controles, portanto, não são um menu do qual um acrônimo da moda pode ser selecionado. Eles são uma sequência de decisões: remover autoridade desnecessária, tornar o código necessário fixo quando possível, limitar de onde pode vir, observar o que faz, preservar evidências e manter um caminho testado para desabilitá-lo ou substituí-lo.

Responsabilidade deve seguir os controles que cada parte detinha

O incidente envolveu um operador de serviço, proprietários de sites, provedores de infraestrutura, um registrador, pesquisadores de segurança, mantenedores de plugins e produtos, e fornecedores cujo código introduziu o endpoint. Suas responsabilidades se sobrepunham, mas não eram intercambiáveis.

O operador que controlava o serviço hospedado Polyfill.io detinha a autoridade mais direta sobre a resposta retornada por esse serviço. Isso é diferente de manter o código aberto original. A responsabilidade nesta camada diz respeito à custódia do domínio e caminho de implantação, controle de mudanças, integridade da resposta, visibilidade na entrega e comunicação precisa sobre a operação. O registro disponível não deve ser esticado para uma conclusão sobre cada ator individual, relação corporativa ou dever legal.

Fastly e Cloudflare detinham capacidades de infraestrutura e substituição. Seus avisos de fevereiro podiam alertar e oferecer alternativas. A posição posterior da Cloudflare permitia reescrita automática e telemetria do lado do cliente para tráfego coberto. Esses controles eram significativos, mas não davam a nenhum dos provedores conhecimento completo da fonte, configuração ou impacto do visitante de cada site downstream. [2][3][5]

Namecheap detinha uma alavanca de contenção no nível do registrador. Colocar o domínio em espera interrompeu a resolução ou uso do endpoint. Essa ação reduziu a exposição imediata, potencialmente quebrando sites dependentes. O controle do registrador podia parar um caminho; não podia corrigir aplicações ou estabelecer entrega histórica para cada site. [10]

Pesquisadores de segurança e respondedores governamentais detinham capacidades de detecção, análise e aviso. A Sansec publicou indicadores e comportamento observado. Akamai e Cloudflare adicionaram perspectivas de telemetria. CERT-FR, Austrália Ocidental, CERT-AGID e SingCERT traduziram o incidente em orientações para operadores para seus públicos. Essas partes podiam aumentar a visibilidade e recomendar controles; não podiam implantar correções em todos os sites. [1][5][6][7][9][21][22]

Mantenedores de plugins, bibliotecas e fornecedores controlavam código que podia introduzir a dependência de forma transitiva. Suas ações responsáveis incluíam identificar versões e condições afetadas, remover o endpoint, lançar uma correção, comunicar o escopo e preservar a distinção entre exposição potencial e exploração observada. Os registros do Fides e dos plugins WordPress mostram por que a evidência de versão e alcançabilidade é importante. [11][12][14]

Os proprietários de sites controlavam a decisão final de inclusão, mesmo quando executá-la exigia que um fornecedor ou mantenedor mudasse o código. Eles podiam definir navegadores suportados, aprovar provedores de script de terceiros, manter inventários, monitorar propriedade, bloquear ou reescrever recursos, auto-hospedar código revisado, reter evidências do navegador, investigar reclamações e comunicar-se com visitantes.

Isso não implica culpa igual. Um operador de site pequeno pode ter muito menos visibilidade e especialização do que uma empresa global de infraestrutura. Um fornecedor pode ser a única parte capaz de mudar um fallback empacotado. Um registrador pode ser a única parte capaz de suspender um domínio rapidamente. A responsabilidade segue o controle prático e a evidência disponível para exercê-lo, não uma suposição de que todo participante tinha a mesma capacidade.

Um mapa de dever útil pode ser organizado em torno de seis perguntas.

Primeiro, quem podia evitar exposição desnecessária? Proprietários de sites e produtos podiam revisar o suporte do navegador e remover a dependência. Mantenedores podiam parar de recomendá-la ou empacotá-la. Provedores podiam oferecer caminhos de migração mais seguros.

Segundo, quem podia detectar mudança de confiança? Monitores de domínio e infraestrutura podiam observar mudanças de propriedade, DNS e roteamento. Mantenedores de projeto podiam rastrear controle de conta e documentação. Proprietários de sites podiam se inscrever em avisos relevantes e revisar dependências de alta autoridade quando seu operador mudava.

Terceiro, quem podia observar entrega prejudicial? O operador do serviço e provedores de infraestrutura podiam ver respostas no lado do servidor. Proprietários de sites e serviços de segurança do lado do cliente podiam ver comportamento do navegador. Pesquisadores podiam comparar amostras entre condições. Nenhuma visão única cobria necessariamente toda a campanha.

Quarto, quem podia conter o caminho? O operador podia parar a entrega, o registrador podia suspender o domínio, provedores de infraestrutura podiam reescrever ou bloquear tráfego, mantenedores podiam lançar correções, e proprietários de sites podiam desabilitar ou remover referências.

Quinto, quem podia investigar o impacto? Cada proprietário de site detinha sua própria arquitetura de página, registros de visitantes, reclamações e histórico de implantação. Fornecedores detinham informações sobre condições transitivas. Provedores de infraestrutura detinham telemetria selecionada de tráfego e resposta. A investigação exigia cooperação sem fingir que o conjunto de dados de uma parte representava todos os visitantes.

Sexto, quem podia verificar o reparo e comunicá-lo? Mantenedores podiam vincular correções a versões. Fornecedores podiam mostrar remoção. Proprietários de sites podiam testar o caminho público e declarar o que sua evidência cobria. Órgãos governamentais e de segurança podiam atualizar orientações. A verificação tinha que permanecer delimitada à visibilidade da parte.

Esse mapa torna a responsabilidade testável. Em vez de perguntar apenas quem causou o incidente, pergunta qual parte podia responder a cada pergunta de prevenção, detecção, contenção, investigação e reparo. Também expõe lacunas de controle. Se ninguém monitorava a propriedade do domínio para um script com autoridade de nível de página, a lacuna existia antes do ramo malicioso aparecer.

O que um site downstream deve ser capaz de provar

Uma resposta downstream crível pode ser expressa como uma cadeia de evidências, em vez de uma garantia genérica.

A cadeia começa com inventário. A organização deve identificar toda referência direta e transitiva ao Polyfill.io, o componente ou fornecedor que a introduziu, as páginas que a renderizavam e as condições do navegador que a tornavam alcançável. Os resultados da busca devem ser conectados ao comportamento implantado, não deixados como uma lista de arquivos correspondentes.

Em seguida vem a necessidade. O proprietário deve documentar se a função de compatibilidade ainda é necessária para os navegadores que suporta intencionalmente. Se não, a remoção deve ser preferida. Se for necessária, a organização deve explicar por que a substituição escolhida ou versão auto-hospedada é proporcional à necessidade.

O terceiro passo é a reavaliação da confiança. O registro deve mostrar quando a organização soube da transição de propriedade ou incidente de junho, quem tomou a decisão de continuar, bloquear, substituir ou remover o serviço, e que evidência apoiou essa decisão. Uma revisão em fevereiro e uma resposta de emergência em junho são eventos diferentes e não devem ser colapsados.

O quarto passo é o escopo histórico. A organização deve declarar quais datas, populações de visitantes e fontes de telemetria examinou. Deve separar referências de endpoint, solicitações, correspondências de indicadores conhecidos, redirecionamentos e danos relatados. Se os logs estão faltando, a lacuna deve permanecer explícita.

O quinto passo é o reparo. O proprietário deve vincular a mudança a um lançamento, configuração ou confirmação do fornecedor. Deve contabilizar ativos gerados, caches, plugins, gerenciadores de tags e branches condicionais. Meramente observar que o domínio suspenso não responde mais não é evidência de remoção.

O sexto passo é a verificação. Os testes devem cobrir condições relevantes do navegador e confirmar que a página pública não faz solicitação ao endpoint antigo. O monitoramento deve procurar reintrodução, origens de script inesperadas e comportamento de redirecionamento. Quando o fornecedor forneceu a correção, o cliente deve verificar o resultado externo.

O sétimo passo é a comunicação. Um aviso deve usar definições estáveis e evitar converter uso em vitimização. Deve explicar que dependência existia, se era alcançável, que evidência de entrega maliciosa foi ou não encontrada, o que mudou e quais incertezas permanecem. Os usuários precisam de fatos práticos, não de uma declaração ampla de que o problema foi "resolvido".

Finalmente, o proprietário deve atualizar seus controles de ciclo de vida. Scripts remotos de alta autoridade precisam de proprietários nomeados, datas de revisão, registros de base de confiança, monitoramento de domínio e operador, caminhos de desativação de emergência e retenção de evidências úteis do navegador. Caso contrário, a mesma falha de governança pode ocorrer novamente sob um nome de host diferente.

Essas provas não exigem divulgação de detalhes defensivos sensíveis. Exigem especificidade suficiente para tornar a resposta falseável. Um visitante, cliente ou revisor deve ser capaz de distinguir "removemos a string" de "encontramos todos os caminhos ativos", e "não vimos exploração" de "nossa evidência a descarta para a população coberta".

Uma transferência de domínio pode ser uma mudança de software

Polyfill.io tornou um princípio simples difícil de ignorar: quando um domínio retorna código executável, a propriedade do domínio faz parte do estado de segurança do software. A URL pode permanecer estável enquanto o fornecedor efetivo muda. Um repositório pode permanecer público enquanto a resposta hospedada se move para controle diferente. HTTPS pode permanecer válido enquanto a base de confiança que justificava a inclusão não existe mais.

Os avisos de fevereiro mostraram que essa mudança era visível e acionável. Os relatórios de junho mostraram por que isso importava. A entrega seletiva de redirecionamento explorou um modelo em que visitantes diferentes podiam legitimamente receber código diferente, tornando a inspeção casual uma garantia fraca. A reescrita posterior e a suspensão do domínio restringiram o caminho, mas apenas o inventário, remoção, investigação e verificação downstream podiam fechar a parte de cada site do problema.

O incidente não justifica chamar mais de 100.000 sites de vítimas confirmadas. Não prova que toda referência serviu conteúdo malicioso, que todo visitante foi exposto ou que todo produto downstream foi explorado. Também não justifica descrever o código aberto original como universalmente malicioso ou tratar uma cópia auto-hospedada como idêntica ao relacionamento hospedado comprometido.

O evento também não suporta um veredito legal ou uma história de atribuição completa do registro disponível. Responsabilidade aqui é mais restrita e mais operacional. É a obrigação de explicar por que a autoridade executável foi delegada, como a mudança de controle foi detectada, que evidência estabeleceu alcance, qual ação reduziu a exposição e como o reparo foi verificado.

O operador do serviço, empresas de infraestrutura, registrador, mantenedores, fornecedores e proprietários de sites cada um detinha partes diferentes dessa resposta. A responsabilidade foi compartilhada porque o sistema era compartilhado, mas não era fungível. Um registrador podia suspender um domínio e ainda deixar código obsoleto para trás. Um fornecedor podia remover uma referência e ainda carecer da telemetria do visitante do cliente. Um site podia investigar seus usuários e ainda depender de uma parte upstream para alterar um componente empacotado.

Para proprietários downstream, o padrão duradouro é direto: conheça toda parte externa que pode escolher código para seus visitantes; monitore os fatos que tornavam essa parte confiável; remova autoridade que não serve mais a uma função necessária; e preserve evidência suficiente para distinguir exposição, entrega e dano.

Uma tag script pode ser uma linha de HTML, mas cria um relacionamento operacional. Quando o proprietário por trás dessa linha muda, o relacionamento de software muda também. A responsabilidade do site começa com reconhecer essa mudança antes que um visitante tenha que revelá-la.

Polyfill.io Transformou a Propriedade de Domínio em um Teste de Responsabilidade para Sites a Jusante