Eu esqueci de ler no outro dia e novamente estou eu aqui... referenciando um conteúdo que eu mesmo compartilhei 27 de maio
Outro site para quem quiser se aprofundar no tema: https://aszx87410.github.io/beyond-xss/en/
Pretendo nos próximos dias compartilhar mais coisas daqui.
Por hoje é isso.
Pretendo nos próximos dias compartilhar mais coisas daqui.
Por hoje é isso.
O dilema de não forçar novas proteções por padrão ecoa o drama do suporte a legados de 2010. Na época, a solução para o ataque via :visited foi limitar o CSS, corrigindo a falha de segurança sem remover a funcionalidade visual de links visitados.
A chegada do Spectre (uma vulnerabilidade de CPU que permitia a um site malicioso ler a memória de outros processos, possibilitando o roubo de dados entre abas e quebrando a barreira de segurança mais fundamental do sistema) mudou tudo. A severidade da ameaça fez a indústria aceitar o enorme custo de performance do Site Isolation, uma proteção imposta na arquitetura do próprio navegador.
Então, por que o mesmo não ocorre com headers como COOP/COEP? A diferença é a responsabilidade: Site Isolation é uma mudança do navegador; headers são uma implementação do desenvolvedor do site.
Forçá-los por padrão quebraria funcionalidades essenciais, como logins OAuth e integrações de pagamento, que dependem da comunicação entre janelas. O navegador não pode adivinhar se essa interação é legítima. Por isso, a proteção total hoje é opt-in: a decisão de isolar uma página é do desenvolvedor, pois o risco de paralisar a web funcional ainda impede que a segurança máxima seja o padrão.
A chegada do Spectre (uma vulnerabilidade de CPU que permitia a um site malicioso ler a memória de outros processos, possibilitando o roubo de dados entre abas e quebrando a barreira de segurança mais fundamental do sistema) mudou tudo. A severidade da ameaça fez a indústria aceitar o enorme custo de performance do Site Isolation, uma proteção imposta na arquitetura do próprio navegador.
Então, por que o mesmo não ocorre com headers como COOP/COEP? A diferença é a responsabilidade: Site Isolation é uma mudança do navegador; headers são uma implementação do desenvolvedor do site.
Forçá-los por padrão quebraria funcionalidades essenciais, como logins OAuth e integrações de pagamento, que dependem da comunicação entre janelas. O navegador não pode adivinhar se essa interação é legítima. Por isso, a proteção total hoje é opt-in: a decisão de isolar uma página é do desenvolvedor, pois o risco de paralisar a web funcional ainda impede que a segurança máxima seja o padrão.
Em 2010, navegadores mitigaram ataques mascarando estilos de links visitados e limitando propriedades CSS aplicáveis. Entre 2013 e 2018 surgiram ataques mais sofisticados de timing e pixel/bleeding, observando reflows, cores renderizadas ou tempos de layout para inferir dados cross-origin. Alguns exploravam que múltiplos sites compartilhavam o mesmo processo do navegador, abrindo espaço para Spectre-like attacks, combinando microarquitetura da CPU e medições de tempo para exfiltrar informação.
Hoje, mitigadores modernos dificultam muito esses ataques: performance.now() tem baixa resolução, SharedArrayBuffer é restrito, e Site Isolation separa processos por origem. Ainda assim, muitos sites não aplicam COOP/COEP corretamente, deixando pequenas superfícies de ataque. Outros ataques modernos combinam eventos como onload ou focus com medições de layout e cores para inferir dados sem acesso direto ao DOM.
Essa é uma luta constante entre usabilidade, acessibilidade e cibersegurança: cada mitigação pode impactar performance ou experiência do usuário, e cada site sem proteção oferece terreno fértil para ataques de side-channel. Estudar esses cenários é essencial para entender como canais colaterais podem vazar informação sem quebrar o SOP.
Hoje, mitigadores modernos dificultam muito esses ataques: performance.now() tem baixa resolução, SharedArrayBuffer é restrito, e Site Isolation separa processos por origem. Ainda assim, muitos sites não aplicam COOP/COEP corretamente, deixando pequenas superfícies de ataque. Outros ataques modernos combinam eventos como onload ou focus com medições de layout e cores para inferir dados sem acesso direto ao DOM.
Essa é uma luta constante entre usabilidade, acessibilidade e cibersegurança: cada mitigação pode impactar performance ou experiência do usuário, e cada site sem proteção oferece terreno fértil para ataques de side-channel. Estudar esses cenários é essencial para entender como canais colaterais podem vazar informação sem quebrar o SOP.
Antes de 2010, navegadores permitiam que sites medisse detalhes de links visitados via CSS, como :visited. Um atacante podia usar JavaScript para inferir dados sensíveis, mas isso só fazia sentido em contextos específicos, como um iframe cross-origin ou via XSS. Dentro de um iframe, o atacante não lê diretamente o conteúdo de outro site, mas podia medir diferenças de renderização que variavam dependendo de dados internos. Por exemplo:
Aqui você não lê o HTML do link. O que vaza é a discrepância no tempo de execução da operação, que varia com o cálculo do layout."
let iframe = document.querySelector("iframe");
let inicio = performance.now(); // Inicia a medição de tempo.
let altura = iframe.contentWindow.document.querySelector("a.visited").offsetHeight; // Solicita uma propriedade de layout que exige um cálculo (reflow). O tempo que essa linha leva é a informação vazada.
let fim = performance.now(); // Finaliza a medição de tempo.
console.log(fim - inicio); // Exibe a diferença de tempo.Aqui você não lê o HTML do link. O que vaza é a discrepância no tempo de execução da operação, que varia com o cálculo do layout."
Você abre um site desconhecido, mas não espera que um JavaScript leia o saldo da sua aba aberta do PayPal, certo? Quem protege você disso não é o servidor, é seu navegador — você está com dois sites abertos ao mesmo tempo. Quem impede que um site leia diretamente outro é o Same-Origin Policy (SOP).
Ótimo, estou mais seguro… Na verdade, não. Existem formas de bypassar o SOP sem ler o conteúdo diretamente, coletando informações sobre o layout ou renderização de elementos em outra página.
Fiz esse texto porque dediquei um tempo hoje para dar importância a esse assunto; ao final deixo alguns sites com ótimos conteúdos. Se você gosta de pentest web, essa é uma ótima categoria de ataque para estudar: XS-Leaks (cross-site leaks) ou side-channel attacks, ambos os termos se aplicam dependendo da técnica usada.
Ótimo, estou mais seguro… Na verdade, não. Existem formas de bypassar o SOP sem ler o conteúdo diretamente, coletando informações sobre o layout ou renderização de elementos em outra página.
Fiz esse texto porque dediquei um tempo hoje para dar importância a esse assunto; ao final deixo alguns sites com ótimos conteúdos. Se você gosta de pentest web, essa é uma ótima categoria de ataque para estudar: XS-Leaks (cross-site leaks) ou side-channel attacks, ambos os termos se aplicam dependendo da técnica usada.
[16º Seminário de Privacidade] -
O evento será realizado pelo CGI.br e NIC.br, nos dias 25, 26 e 27 de agosto de 2025, em São Paulo/SP.
Transmissão ao vivo rolando agora
https://www.youtube.com/watch?v=IfhJ3I-w6Mg
O evento será realizado pelo CGI.br e NIC.br, nos dias 25, 26 e 27 de agosto de 2025, em São Paulo/SP.
Transmissão ao vivo rolando agora
https://www.youtube.com/watch?v=IfhJ3I-w6Mg
Caso alguem tenha interesse, ele esta funcional, mas pos reparo ele pode ser vendido com lucro. Envio para todo brasil ja incluso no valor. Seguem mais infos:
https://rs.olx.com.br/regioes-de-porto-alegre-torres-e-santa-cruz-do-sul/informatica/notebooks/notebook-gamer-avell-a62-liv-i7-potente-para-usar-como-desktop-leia-descricao-1430468214
---
🚀 No Bug Bounty, o sucesso nem sempre está na exploração... às vezes, o Recon é o verdadeiro "game changer".
E no nosso próximo episódio de #0xCuriosity, teremos um convidado de peso:
🎙️ Felipe Caon (aka caon), reconhecido como um dos melhores Bug Hunters do Brasil 🇧🇷, que irá compartilhar sua experiência em levar o Recon além do escaneamento e da automação.
📅 Quarta-feira, 27 de agosto
🕗 22:00 (GMT-3)
📍 https://twitch.tv/0xcuriosity
----
Nota do Zeroc00i: O Caon é bughunter true, podem seguir a call que é conteúdo bom, não aqueles marketing besteirol
Link para o texto da imagem: https://www.linkedin.com/posts/bruno-menozzi_a-nova-superf%C3%ADcie-de-ataque-n%C3%A3o-%C3%A9-seu-usu%C3%A1rio-activity-7365724038188490754-VRAf
Artigo sobre o PromptFix Attack: https://thehackernews.com/2025/08/experts-find-ai-browsers-can-be.html
Publicação do NIST sobre o novo framework: https://hackread.com/nist-concept-paper-ai-cybersecurity-framework/
Documento conceitual do NIST (PDF): https://csrc.nist.gov/pubs/cswp/29/the-way-forward/final/docs/sais-concept-paper_2025/08/14.pdf
O John Hammond publicou um vídeo ha 3 horas falando sobre isso e outros caracteres parecidos que tem o mesmo comportamento:
https://youtu.be/nxVr4ERhrPQ?si=-Lbb1B2Qs8hNp4w9&t=609
Vocês podem usar essa acao customizada usando esse código aqui:
https://github.com/PortSwigger/bambdas/blob/main/CustomAction/RetryUntilSuccess.bambda
https://github.com/PortSwigger/bambdas/blob/main/CustomAction/RetryUntilSuccess.bambda
Saiba como diferenciar:
https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling