From 1bef06651e55849b8afb4c63b9b508b7ee57fc59 Mon Sep 17 00:00:00 2001
From: Translator <github-actions@github.com>
Date: Tue, 19 Aug 2025 21:11:29 +0000
Subject: [PATCH] Translated
 ['src/binary-exploitation/rop-return-oriented-programing/srop

---
 .../srop-arm64.md                             |  6 ++---
 .../iframes-in-xss-and-csp.md                 | 22 +++++++++----------
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md b/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md
index 03a095187..563206a29 100644
--- a/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md
+++ b/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md
@@ -2,7 +2,7 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Exemplo de Pwntools
+## Exemplo Pwntools
 
 Este exemplo cria o binário vulnerável e o explora. O binário **lê na pilha** e então chama **`sigreturn`**:
 ```python
@@ -205,7 +205,7 @@ frame.x2 = 7                       # PROT_READ|PROT_WRITE|PROT_EXEC
 frame.sp = 0x400000 + 0x100        # new pivot
 frame.pc = svc_call                # will re-enter kernel
 ```
-Após enviar o frame, você pode enviar um segundo estágio contendo shell-code bruto em `0x400000+0x100`.  Porque **AArch64** usa endereçamento *PC-relative*, isso é frequentemente mais conveniente do que construir grandes cadeias ROP.
+Após enviar o frame, você pode enviar um segundo estágio contendo código shell bruto em `0x400000+0x100`.  Como **AArch64** usa endereçamento *PC-relative*, isso é frequentemente mais conveniente do que construir grandes cadeias ROP.
 
 ## Validação do Kernel, PAC e Shadow-Stacks
 
@@ -223,7 +223,7 @@ Shadow-Call-Stacks introduzidos no ARMv8.9 (e já habilitados no ChromeOS 1.27+)
 
 ## Referências
 
-* [Documentação de manipulação de sinal arm64 do Linux](https://docs.kernel.org/arch/arm64/signal.html)
+* [Documentação de manipulação de sinal do Linux arm64](https://docs.kernel.org/arch/arm64/signal.html)
 * [LWN – "AArch64 branch protection comes to GCC and glibc" (2023)](https://lwn.net/Articles/915041/)
 
 {{#include ../../../banners/hacktricks-training.md}}
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 bf58e0a86..621bb9ac5 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 mesma origem)
+- Via `src` indicando uma URL (a URL pode ser de origem cruzada ou da mesma origem)
 - Via `src` indicando o conteúdo usando o protocolo `data:`
 - Via `srcdoc` indicando o conteúdo
 
@@ -81,7 +81,7 @@ No entanto, **apenas os scripts `if1` e `if2` serão executados, mas apenas `if1
 
 ![](<../../images/image (372).png>)
 
-Portanto, é possível **contornar um CSP se você puder fazer upload de um arquivo JS para o servidor e carregá-lo via iframe, mesmo com `script-src 'none'`**. Isso pode **potencialmente ser feito abusando de um endpoint JSONP de mesmo site**.
+Portanto, é possível **contornar um CSP se você puder fazer upload de um arquivo JS para o servidor e carregá-lo via iframe, mesmo com `script-src 'none'`**. Isso pode **potencialmente ser feito também abusando de um endpoint JSONP de mesmo site**.
 
 Você pode testar isso com o seguinte cenário onde um cookie é roubado mesmo com `script-src 'none'`. Basta executar o aplicativo e acessá-lo com seu navegador:
 ```python
@@ -107,7 +107,7 @@ app.run()
 
 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 `<iframe name>` *dangling*. Uma vez que a marcação parcial é analisada, o script do atacante rodando em uma origem separada navega o frame para `about:blank` e lê `window.name`, que agora contém tudo até o próximo caractere de citação (por exemplo, um token CSRF). Como nenhum JavaScript é executado no contexto da vítima, o ataque geralmente evita `script-src 'none'`. Um PoC mínimo é:
+* **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 `<iframe name>` *dangling*. Uma vez que a marcação parcial é analisada, o script do atacante em uma origem separada navega o frame para `about:blank` e lê `window.name`, que agora contém tudo até o próximo caractere de citação (por exemplo, um token CSRF). Como nenhum JavaScript é executado no contexto da vítima, o ataque geralmente evita `script-src 'none'`. Um PoC mínimo é:
 
 ```html
 <!-- Ponto de injeção logo antes de um <script> sensível -->
@@ -130,12 +130,12 @@ s.nonce = n;
 top.document.body.appendChild(s);
 ```
 
-* **Sequestro de form-action (PortSwigger 2024)** – Uma página que omite a diretiva `form-action` pode ter seu formulário de login *re-direcionado* a partir de um iframe injetado ou HTML inline, de modo que gerenciadores de senhas preencham automaticamente e enviem credenciais para um domínio externo, mesmo quando `script-src 'none'` está presente. Sempre complemente `default-src` com `form-action`!
+* **Sequestro de form-action (PortSwigger 2024)** – Uma página que omite a diretiva `form-action` pode ter seu formulário de login *re-direcionado* de um iframe injetado ou HTML inline, de modo que gerenciadores de senhas preencham automaticamente e enviem credenciais para um domínio externo, mesmo quando `script-src 'none'` está presente. Sempre complemente `default-src` com `form-action`!
 
-**Notas defensivas (checklist rápido)**
+**Notas defensivas (checklist rápida)**
 
 1. Sempre envie *todas* as diretivas CSP que controlam contextos secundários (`form-action`, `frame-src`, `child-src`, `object-src`, etc.).
-2. Não confie que nonces sejam secretos—use `strict-dynamic` **e** elimine pontos de injeção.
+2. Não confie que os nonces sejam secretos—use `strict-dynamic` **e** elimine pontos de injeção.
 3. Quando você precisar incorporar documentos não confiáveis, use `sandbox="allow-scripts allow-same-origin"` **com muito cuidado** (ou sem `allow-same-origin` se você só precisar de isolamento de execução de script).
 4. Considere uma implantação de defesa em profundidade COOP+COEP; o novo atributo `<iframe credentialless>` (§ abaixo) permite que você faça isso sem quebrar incorporações de terceiros.
 
@@ -175,12 +175,12 @@ O valor do atributo pode ser deixado vazio (`sandbox=""`) para aplicar todas as
 ```
 ### 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 requisiçã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 solicitação, mantendo a mesma política de origem (SOP) da página carregada no iframe.
 
-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:
+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 o 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.
+* Como a rede é **sem credenciais**, qualquer solicitaçã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
 // PoC: two same-origin credentialless iframes stealing cookies set by a third
@@ -189,7 +189,7 @@ alert(window.top[2].document.cookie);                 // read -> foo=bar
 ```
 - Exemplo de exploração: Self-XSS + CSRF
 
-Neste ataque, o atacante prepara uma página maliciosa com 2 iframes:
+Neste ataque, o atacante prepara uma página web 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
@@ -209,7 +209,7 @@ document.forms[0].submit();
 
 - Outro iframe que na verdade tem o usuário logado (sem a flag `credentialless`).
 
-Então, a partir do XSS, é possível acessar o outro iframe, pois eles têm o mesmo SOP e roubar o cookie, por exemplo, executando:
+Então, a partir do XSS é possível acessar o outro iframe, pois eles têm o mesmo SOP e roubar o cookie, por exemplo, executando:
 ```javascript
 alert(window.top[1].document.cookie);
 ```