Muitas vezes focamos só em XSS, mas o CSS exfiltration pode ser uma forma sutil de vazar dados sensíveis como tokens CSRF ou informações de formulários, especialmente quando as políticas de segurança de conteúdo (CSP) não estão configuradas para restringir fontes de estilo ou conexões externas de forma rigorosa.
Ah, e acalmem o coração: aquele seu XSS refletido ou armazenado clássico, que não depende dessa mutação doida no DOM durante a sanitização, é outra história e continua valendo do mesmo jeito. !=mXss
Sabe aquele payload clássico de mXSS, especialmente o que usava a tag <noscript> e acrescia um </noscript><img src=x onerror=alert(1)> direto no valor de um atributo, tipo alt?

<noscript><a alt="</noscript><img src onerror=alert(1)>">Hello</a></noscript>


A malandragem era que, quando o sanitizador (tipo DOMPurify) processava isso e depois serializava de volta pra string, os caracteres < e > no atributo não eram escapados. Aí, na hora que o navegador ia renderizar esse HTML "limpo", ele interpretava esses caracteres como início de novas tags, e boom, XSS!

Pois é, essa brincadeira específica acabou, ou pelo menos ficou bem mais difícil no Chrome a partir da versão M138 (que vai virar estável agora 24 de junho de 2025). O Google anunciou que a especificação do HTML mudou: agora, ao serializar um DOM para string, os caracteres < e > dentro de atributos serão automaticamente convertidos para &lt; e &gt;. Com isso, aquele </noscript> ou <img ...> dentro do atributo não vai mais ter força pra quebrar a estrutura e criar uma nova tag do nada durante a re-parse do navegador.

Isso quer dizer que o mXSS morreu? Não completamente. Ainda existem outros vetores, como os que abusam da forma como o conteúdo de certas tags (tipo <style> ou <textarea>) é serializado sem escape. Mas aquela técnica específica, que dependia da falta de escape em atributos pra injetar tags, tomou um golpe duro.

Pra evitar mXSS de vez, o ideal continua sendo usar sanitizadores que manipulam e retornam o DOM diretamente, sem essa etapa de serializar para string e depois dar innerHTML.
Vi esse insight do Tib3rius e achei hilário kkk
O cabeçalho 'Referer' foi designado para ser RefeRRer, com 2 R (vindo de referenciador mesmo).
Só quando estavam perto de publicar a especificação do HTTP 1.0 que foram notar.
Ouve uma troca de ideia "alguem mais notou o erro na soletração"?
E continuaram a thread com "ah, bem. Todos nós cometemos erros =-)"
E após 30 anos o erro se perpetuou por que é inviável hoje em dia com a quantidade de implementações feitas em cima desse erro voltar atrás
Achei emocionante essa reflexão. Quem se atrair pelo titulo, recomendo a ler. Esse cara é bem reconhecido na cena de bugbounty. Ele fala se as AI vão tomar o espaço em cybersec, inclusive bugbounty.
Zeroc00i News & Tricks
Shareando uma trick boba mas útil. Cenário: - Tu suspeita de SSRF em uma requisição; - O parâmetro do endpoint exige que tu forneça um domínio válido para receber a requisição; - Oastify (listener do Burp), etc não é o suficiente. Tu quer devolver uma header…
A dica é usar o cloudflared (tunnel da cloudflare).
Ele vai te dar um domínio sem esses banners e você não precisa criar conta / configurar token etc

sudo apt install cloudflared
cloudflared tunnel --url 0.0.0.0:80

2023-10-27T10:00:02Z INF | Your quick Tunnel has been created! Visit it at (it may take a few seconds to be available): |
2023-10-27T10:00:02Z INF | https://your-random-words-here.trycloudflare.com
Shareando uma trick boba mas útil.
Cenário:
- Tu suspeita de SSRF em uma requisição;
- O parâmetro do endpoint exige que tu forneça um domínio válido para receber a requisição;
- Oastify (listener do Burp), etc não é o suficiente. Tu quer devolver uma header específica, tipo um content-type de PDF, precisa ter mais liberdade e não simplesmente receber a request http / dns
- 👉 Tu tem uma VPS, mas não tem um domínio registrado.
> Tu pensa: NGROK!
O problema é que pra evitar abusos, o Ngrok e outros programas vão te dar essa mensagem (da imagem anexada) se o SSRF simplesmente for chamado pra tua URL final do Ngrok. Ele basicamente tá dizendo: oh, na requisição que tu fizer (client-side), seta essa header aqui pra gente ter certeza que tu não é uma botnet, ou que tá usando pra más intencões ou algo assim.

Então se tu tiver esse SSRF via GET, o ngrok te trava aqui se tu só tiver um plano FREE (pago da pra remover esse aviso).
É comum ver comentários nas redes sociais sugerindo que hackers presos acabam trabalhando para o governo, como para o FBI ou a CIA. No entanto, quem passou pelo sistema sabe que isso raramente corresponde à realidade por diversos motivos:

Muitos, especialmente adolescentes, lidam com questões de saúde mental ou são neurodiversos, tornando um ambiente de trabalho tradicional inadequado.

A "cooperação" oferecida pelas autoridades geralmente se resume a delatar outros criminosos, não a um emprego.

👉 Ao contrário da crença popular, a maioria dos presos por cibercrime não possui habilidades técnicas excepcionais. 👈

O sistema judicial priorizará a punição se acreditar que ela envia uma mensagem mais forte do que qualquer cooperação.

Além disso, a realidade do cibercrime mudou drasticamente desde os anos 90 e 2000. Hoje, as penas são severas (superiores a 15 anos de prisão), e envolver-se nisso, especialmente nos EUA ou Europa, é arriscar a vida inteira. A natureza remota do crime, onde as vítimas são apenas nomes numa tela, facilita a escalada das ações e suas graves consequências.
Gemini can "watch" videos using a tool called "Youtube".
Pessoal, em bugbounty aqui encontrei um caso que o $metadata do Odata era extremamente grande e a extensão mais conhecida do Burp: odata-explorer não conseguiu dar conta de manipular ela. Então resolvi criar uma:

https://github.com/zeroc00I/Zodata

Aproveitei e coloquei algumas funcionalidades nela para facilitar explorações. Vocês podem sacar elas no README mesmo.

Então próximo pentest / asset em bugbounty que se depararem com Odata, give it a try

Vlw
Back to Top