Para ler quando tiver mais tempo ++ (Referência boa: Pesquisadores da Portswigger)
https://portswigger.net/research/cookie-chaos-how-to-bypass-host-and-secure-cookie-prefixes
https://portswigger.net/research/cookie-chaos-how-to-bypass-host-and-secure-cookie-prefixes
Tudo anda bem corrido por aqui essa ultima semana.
Tem um artigo falando sobre esse assunto que parece de qualidade muito boa. Esse tipo de ataque vai crescer muito ainda.
https://brave.com/blog/comet-prompt-injection/
Tem um artigo falando sobre esse assunto que parece de qualidade muito boa. Esse tipo de ataque vai crescer muito ainda.
https://brave.com/blog/comet-prompt-injection/
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