* Você trabalha em uma **empresa de segurança cibernética**? Gostaria de ver sua **empresa anunciada no HackTricks**? Ou gostaria de ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
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.
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.
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()`.
* **script-src**: Esta diretiva especifica as fontes permitidas para JavaScript. Isso inclui não apenas URLs carregados diretamente em elementos, mas também coisas como manipuladores de eventos de script inline (onclick) e folhas de estilo XSLT que podem acionar a execução de script.
* **default-src**: Esta diretiva define a política para buscar recursos por padrão. Quando as diretivas de busca estão ausentes no cabeçalho CSP, o navegador segue esta diretiva por padrão.
* **Child-src**: Esta diretiva define os recursos permitidos para web workers e conteúdos de frames incorporados.
* **connect-src**: Esta diretiva restringe URLs para carregar usando interfaces como fetch, websocket, XMLHttpRequest.
* **frame-src**: Esta diretiva restringe URLs para frames que podem ser chamados.
* **frame-ancestors**: Esta diretiva especifica as fontes que podem incorporar a página atual. Esta diretiva se aplica a [`<frame>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/frame), [`<iframe>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe), [`<object>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object), [`<embed>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/embed) ou [`<applet>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/applet). Esta diretiva não pode ser usada em tags e se aplica apenas a recursos não HTML.
* **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.
* \*: 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-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".
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**.
O CSP (Content Security Policy) é um mecanismo de segurança que ajuda a proteger os aplicativos da web contra ataques de injetar código malicioso. Ele permite que os desenvolvedores especifiquem quais fontes de conteúdo são consideradas seguras e quais não são permitidas.
Uma diretiva CSP comum é a diretiva `default-src 'self'`, que restringe o carregamento de recursos a partir do mesmo domínio em que a página está sendo exibida. Isso significa que apenas recursos do próprio domínio são permitidos, enquanto recursos de outros domínios são bloqueados.
No entanto, essa restrição pode ser explorada por um atacante para contornar a política de segurança e fazer o upload de arquivos maliciosos. O atacante pode usar um formulário de upload de arquivo para enviar um arquivo para o servidor, que será armazenado no mesmo domínio. Em seguida, o atacante pode explorar uma vulnerabilidade no aplicativo para executar o arquivo malicioso.
Para evitar esse tipo de ataque, é importante implementar medidas adicionais de segurança, como a validação rigorosa dos arquivos enviados e a verificação de sua integridade antes de serem executados ou armazenados no servidor. Além disso, é recomendável usar uma combinação de diretivas CSP para restringir ainda mais as fontes de conteúdo permitidas.
É importante lembrar que a implementação correta e eficaz de uma política de segurança de conteúdo é essencial para proteger os aplicativos da web contra ataques de injeção de código malicioso e garantir a segurança dos dados dos usuários.
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](https://github.com/Polydet/polyglot-database)).
#### Cargas úteis usando Angular + uma biblioteca com funções que retornam o objeto `window` ([confira esta postagem](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
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`**.
De acordo com [**este relatório de CTF**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?\_x\_tr\_sl=es&\_x\_tr\_tl=en&\_x\_tr\_hl=es&\_x\_tr\_pto=wapp#noteninja-3-solves), é possível explorar o [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) dentro de uma CSP para executar código JS arbitrário, burlando a CSP:
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.
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 uma solicitação JSONP para um ponto de terceiros e obter os dados desejados.
No entanto, é importante observar que nem todos os sites suportam JSONP. Além disso, o uso de JSONP pode introduzir riscos de segurança, como a possibilidade de ataques de XSS (Cross-Site Scripting). Portanto, é essencial avaliar cuidadosamente os riscos antes de usar essa técnica.
O uso de pontos de terceiros e JSONP pode permitir contornar a Política de Segurança de Conteúdo (CSP) e obter acesso a recursos externos restritos. No entanto, é importante considerar os riscos de segurança associados a essa técnica e avaliar se é apropriado usá-la em um determinado contexto.
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:
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.
Se a política CSP apontar para uma pasta e você usar **%2f** para codificar **"/"**, ainda será considerado dentro da pasta. Todos os navegadores parecem concordar com isso.\
Isso leva a uma possível contornar, usando "**%2f..%2f**" se o servidor decodificar. Por exemplo, se o CSP permitir `http://example.com/company/`, você pode contornar a restrição da pasta e executar: `http://example.com/company%2f..%2fattacker/file.js`
Se a diretiva **base-uri** estiver ausente, você pode abusar dela para realizar uma [**injeção de marcação pendente**](../dangling-markup-html-scriptless-injection/).
Além disso, se a página estiver carregando um script usando um caminho relativo (como `/js/app.js`) usando um **Nonce**, você pode abusar da **tag base** para fazer com que ele **carregue** o script do **seu próprio servidor, alcançando um XSS.**\
Se a página vulnerável for carregada com **httpS**, use um URL httpS na base.
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:
**Encontre outras formas de bypass Angular em** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
Se a aplicação estiver usando angular JS e os scripts forem carregados de um domínio permitido, é possível contornar essa política CSP chamando funções de retorno e classes vulneráveis. Para mais detalhes, visite este incrível [repositório](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22) no git.
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)
`'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):
De: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
Você também pode abusar dessa configuração para **carregar código JavaScript inserido dentro de uma imagem**. Se, por exemplo, a página permitir o carregamento de imagens do Twitter, você pode **criar** uma **imagem especial**, enviá-la para o Twitter e abusar do "**unsafe-inline**" para **executar** um código JS (como um XSS regular) que irá **carregar** a **imagem**, **extrair** o **JS** dela e **executá-lo**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
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:
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)
Desta vez, você pode fazer a vítima **carregar** uma página sob **seu controle** via **XSS** com um `<iframe>`. Desta vez, você fará com que a vítima acesse a página de onde deseja extrair informações (**CSRF**). Você não pode acessar o conteúdo da página, mas se de alguma forma você puder **controlar o tempo que a página precisa para carregar**, poderá extrair as informações necessárias.
Desta vez, uma **flag** será extraída, sempre que um **caractere for adivinhado corretamente** através do SQLi, a **resposta** levará **mais tempo** devido à função de sleep. Em seguida, você poderá extrair a flag:
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.
Neste [**writeup do CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), a CSP é burlada injetando dentro de um iframe permitido uma CSP mais restritiva que impede o carregamento de um arquivo JS específico que, em seguida, por meio de **poluição de protótipo** ou **dom clobbering**, permite **abusar de um script diferente para carregar um script arbitrário**.
Neste [**writeup do CTF**](https://github.com/aszx87410/ctf-writeups/issues/48), foi possível, através de **injeção de HTML**, **restringir** ainda mais um **CSP**, desabilitando um script que impedia CSTI e, portanto, tornando a **vulnerabilidade explorável**.\
CSP pode ser tornada mais restritiva usando **meta tags HTML** e scripts inline podem ser desabilitados **removendo** a **entrada** que permite seu **nonce** e **habilitando scripts inline específicos via sha**:
Se você conseguir fazer com que o servidor responda com o cabeçalho **`Content-Security-Policy-Report-Only`** com um **valor controlado por você** (talvez por causa de um CRLF), você pode fazer com que ele aponte para o seu servidor e, se você **envolver** o **conteúdo JS** que deseja exfiltrar com **`<script>`**, e como é altamente provável que `unsafe-inline` não seja permitido pelo CSP, isso irá **disparar um erro CSP** e parte do script (contendo as informações sensíveis) será enviada para o servidor a partir de `Content-Security-Policy-Report-Only`.
Para um exemplo, [**verifique este writeup do CTF**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
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.\
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)
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.
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.\
De [**este writeup**](https://blog.ssrf.kr/69) parece que foi possível burlar uma proteção CSP carregando uma página de erro (potencialmente sem CSP) e reescrevendo seu conteúdo.
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:
Além disso, o **wordpress** possui um endpoint **JSONP** em `/wp-json/wp/v2/users/1?_jsonp=data` que irá **refletir** os **dados** enviados na saída (com a limitação de apenas letras, números e pontos).
Um atacante pode abusar desse endpoint para **gerar um ataque SOME** contra o WordPress e **incorporá-lo** dentro de `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` observe que esse **script** será **carregado** porque é **permitido por 'self'**. Além disso, e porque o WordPress está instalado, um atacante pode abusar do **ataque SOME** por meio do **endpoint de retorno de chamada** vulnerável que **burla o CSP** para conceder mais privilégios a um usuário, instalar um novo plugin...\
Para mais informações sobre como realizar esse ataque, consulte [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
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.
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.
* Você trabalha em uma **empresa de cibersegurança**? Gostaria de ver sua **empresa anunciada no HackTricks**? Ou gostaria de ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).