diff --git a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
index f5243c5c0..bf58e0a86 100644
--- a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
+++ b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
@@ -6,7 +6,7 @@
Existem 3 maneiras de indicar o conteúdo de uma página em um iframe:
-- Via `src` indicando uma URL (a URL pode ser de origem cruzada ou da mesma origem)
+- Via `src` indicando uma URL (a URL pode ser de origem cruzada ou mesma origem)
- Via `src` indicando o conteúdo usando o protocolo `data:`
- Via `srcdoc` indicando o conteúdo
@@ -61,7 +61,7 @@ Portanto, é possível contornar o CSP de uma página com:
+content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk'" />
"
if __name__ == "__main__":
app.run()
```
-### Outros Payloads encontrados na natureza
+#### Novas técnicas de bypass de CSP (2023-2025) com iframes
+
+A comunidade de pesquisa continua a descobrir maneiras criativas de abusar de iframes para derrotar políticas restritivas. Abaixo você pode encontrar as técnicas mais notáveis publicadas nos últimos anos:
+
+* **Exfiltração de dados via dangling-markup / named-iframe (PortSwigger 2023)** – Quando uma aplicação reflete HTML, mas um CSP forte bloqueia a execução de scripts, você ainda pode vazar tokens sensíveis injetando um atributo `
+
+
```
### Iframes sem credenciais
-Como explicado em [este artigo](https://blog.slonser.info/posts/make-self-xss-great-again/), a flag `credentialless` em um iframe é usada para carregar uma página dentro de um iframe sem enviar credenciais na solicitação, mantendo a mesma política de origem (SOP) da página carregada no iframe.
+Como explicado em [este artigo](https://blog.slonser.info/posts/make-self-xss-great-again/), a flag `credentialless` em um iframe é usada para carregar uma página dentro de um iframe sem enviar credenciais na requisição, mantendo a mesma política de origem (SOP) da página carregada no iframe.
-Isso permite que o iframe acesse informações sensíveis de outro iframe na mesma SOP carregada na página pai:
+Desde **o Chrome 110 (fevereiro de 2023), o recurso está habilitado por padrão** e a especificação está sendo padronizada entre os navegadores sob o nome *iframe anônimo*. O MDN descreve como: “um mecanismo para carregar iframes de terceiros em uma nova partição de armazenamento efêmera, de modo que nenhum cookie, localStorage ou IndexedDB seja compartilhado com a origem real”. Consequências para atacantes e defensores:
+
+* Scripts em diferentes iframes sem credenciais **ainda compartilham a mesma origem de nível superior** e podem interagir livremente via DOM, tornando viáveis ataques de self-XSS em múltiplos iframes (veja PoC abaixo).
+* Como a rede está **sem credenciais**, qualquer requisição dentro do iframe efetivamente se comporta como uma sessão não autenticada – endpoints protegidos por CSRF geralmente falham, mas páginas públicas que podem vazar via DOM ainda estão em escopo.
+* Pop-ups gerados a partir de um iframe sem credenciais recebem um `rel="noopener"` implícito, quebrando alguns fluxos de OAuth.
```javascript
-window.top[1].document.body.innerHTML = 'Hi from credentialless';
-alert(window.top[1].document.cookie);
+// PoC: two same-origin credentialless iframes stealing cookies set by a third
+window.top[1].document.cookie = 'foo=bar'; // write
+alert(window.top[2].document.cookie); // read -> foo=bar
```
- Exemplo de exploração: Self-XSS + CSRF
-Neste ataque, o atacante prepara uma página da web maliciosa com 2 iframes:
+Neste ataque, o atacante prepara uma página maliciosa com 2 iframes:
- Um iframe que carrega a página da vítima com a flag `credentialless` com um CSRF que aciona um XSS (Imagine um Self-XSS no nome de usuário do usuário):
```html
@@ -171,7 +215,7 @@ alert(window.top[1].document.cookie);
```
### fetchLater Attack
-Como indicado em [este artigo](https://blog.slonser.info/posts/make-self-xss-great-again/), a API `fetchLater` permite configurar uma solicitação para ser executada mais tarde (após um certo tempo). Portanto, isso pode ser abusado para, por exemplo, fazer login em uma vítima dentro da sessão de um atacante (com Self-XSS), definir uma solicitação `fetchLater` (para mudar a senha do usuário atual, por exemplo) e sair da sessão do atacante. Então, a vítima faz login em sua própria sessão e a solicitação `fetchLater` será executada, mudando a senha da vítima para a que foi definida pelo atacante.
+Como indicado em [this article](https://blog.slonser.info/posts/make-self-xss-great-again/), a API `fetchLater` permite configurar uma solicitação para ser executada mais tarde (após um certo tempo). Portanto, isso pode ser abusado para, por exemplo, fazer login de uma vítima dentro da sessão de um atacante (com Self-XSS), definir uma solicitação `fetchLater` (para mudar a senha do usuário atual, por exemplo) e sair da sessão do atacante. Então, a vítima faz login em sua própria sessão e a solicitação `fetchLater` será executada, mudando a senha da vítima para a que foi definida pelo atacante.
Dessa forma, mesmo que a URL da vítima não possa ser carregada em um iframe (devido ao CSP ou outras restrições), o atacante ainda pode executar uma solicitação na sessão da vítima.
```javascript
@@ -201,4 +245,10 @@ Verifique as seguintes páginas:
../postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md
{{#endref}}
+
+
+## Referências
+
+* [PortSwigger Research – Usando sequestro de formulário para contornar CSP (Março 2024)](https://portswigger.net/research/using-form-hijacking-to-bypass-csp)
+* [Chrome Developers – Iframe sem credenciais: Incorpore facilmente iframes em ambientes COEP (Fev 2023)](https://developer.chrome.com/blog/iframe-credentialless)
{{#include ../../banners/hacktricks-training.md}}