Content Security Policy (CSP) Bypass
Last updated
Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Junte-se ao HackenProof Discord para se comunicar com hackers experientes e caçadores de bugs!
Insights 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 da plataforma
Junte-se a nós no Discord e comece a colaborar com os melhores hackers hoje!
Content Security Policy (CSP) é reconhecido como uma tecnologia de navegador, principalmente voltada para proteger contra ataques como cross-site scripting (XSS). Funciona definindo e detalhando caminhos e fontes a partir das quais recursos podem ser carregados de forma segura pelo navegador. Esses recursos abrangem uma variedade de elementos, como imagens, frames e JavaScript. Por exemplo, uma política pode permitir o carregamento e a execução de recursos do mesmo domínio (self), incluindo recursos inline e a execução de código em string através de funções como eval
, setTimeout
ou setInterval
.
A implementação do CSP é realizada através 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:
Implementado via meta tag:
CSP pode ser aplicado ou monitorado usando esses 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.
CSP restringe as origens para carregar tanto conteúdo ativo quanto passivo, controlando aspectos como a execução de JavaScript inline e o uso de eval()
. Um exemplo de política é:
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 trabalhadores da web e conteúdos de quadros incorporados.
connect-src: Restringe URLs que podem ser carregadas usando interfaces como fetch, WebSocket, XMLHttpRequest.
frame-src: Restringe URLs para quadros.
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 permitidas para carregamento usando elementos <base>
.
form-action: Lista endpoints válidos para envios de formulários.
plugin-types: Restringe 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 Worker, SharedWorker ou ServiceWorker.
prefetch-src: Especifica fontes válidas para recursos que serão buscados ou pré-buscados.
navigate-to: Restringe as URLs para as quais um documento pode navegar por qualquer meio (a, formulário, window.location, window.open, etc.)
*
: Permite todas as URLs, exceto aquelas com esquemas data:
, blob:
, filesystem:
.
'self'
: Permite 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 semelhantes, não recomendado por razões 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 razões 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 execução limitada de JS, é possível obter um nonce usado dentro da 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:
'sha256-<hash>'
: Adiciona à lista branca scripts com um hash sha256 específico.
'strict-dynamic'
: Permite carregar scripts de qualquer fonte se tiver sido adicionado à lista branca por um nonce ou hash.
'host'
: Especifica um host específico, como example.com
.
https:
: Restringe URLs àquelas que usam HTTPS.
blob:
: Permite que recursos sejam carregados de URLs Blob (por exemplo, URLs Blob criadas via JavaScript).
filesystem:
: Permite que recursos sejam carregados do sistema de arquivos.
'report-sample'
: Inclui uma amostra do código que viola a política 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 completas ao fazer solicitações de mesma origem, mas apenas envia a origem quando a solicitação é de origem cruzada.
'unsafe-allow-redirects'
: Permite que recursos sejam carregados que redirecionarão imediatamente para outro recurso. Não recomendado, pois enfraquece a segurança.
Payload funcional: "/><script>alert(1);</script>
Isso não está funcionando, para mais informações verifique isso.
Carga útil funcional:
Se você conseguir de alguma forma fazer um código JS permitido criar uma nova tag de script no DOM com seu código JS, porque um script permitido está criando-a, a nova tag de script será permitida para ser executada.
Carga útil funcional:
Parece que isso não está mais funcionando
Payloads funcionais:
Se você pode fazer upload de um arquivo JS, pode contornar este CSP:
Carga útil funcional:
No entanto, é altamente provável que o servidor esteja validando o arquivo enviado e só permitirá que você envie um tipo determinado de arquivos.
Além disso, mesmo que você conseguisse enviar um código JS dentro de um arquivo usando uma extensão aceita pelo servidor (como: script.png), isso não seria suficiente porque alguns servidores, como o servidor Apache, selecionam o tipo MIME do arquivo com base na extensão e navegadores como o Chrome rejeitarão a execução de 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 conhece a extensão .wave, portanto, não a serve com um tipo MIME como audio/*.
A partir daqui, se você encontrar um XSS e um upload de arquivo, e conseguir encontrar uma extensão mal interpretada, você poderia 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 poliglota aqui).
Se não for possível injetar JS, você ainda poderia tentar exfiltrar, por exemplo, credenciais injetando uma ação de formulário (e talvez esperando que gerenciadores de senhas preencham automaticamente as senhas). Você pode encontrar um exemplo neste relatório. Além disso, observe que default-src
não cobre ações de formulário.
Para alguns dos seguintes payloads, unsafe-eval
não é nem mesmo necessário.
Carregue uma versão vulnerável do angular e execute JS arbitrário:
window
(veja este post):O post mostra que você poderia carregar todas as bibliotecas do 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
.
Angular XSS a partir de um nome de classe:
De acordo com este writeup de CTF, você pode abusar de https://www.google.com/recaptcha/ dentro de um CSP para executar código JS arbitrário contornando o CSP: