**Dica de recompensa por bugs**: **cadastre-se** no **Intigriti**, uma plataforma premium de **recompensa por bugs criada por hackers, para hackers**! Junte-se a nós em [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) hoje mesmo e comece a ganhar recompensas de até **$100.000**!
1. Verifique se **qualquer valor que você controle** (_parâmetros_, _caminho_, _cabeçalhos_?, _cookies_?) está sendo **refletido** no HTML ou **usado** pelo código **JS**.
2.**Encontre o contexto** onde ele está sendo refletido/usado.
1. Verifique **quais símbolos você pode usar** e, dependendo disso, prepare o payload:
1. Em **HTML bruto**:
1. Você pode criar novas tags HTML?
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ê pode abusar de uma [**Injeção de Modelo do Lado do Cliente**](../client-side-template-injection-csti.md).
5. Se você não pode criar tags HTML que executam código JS, você pode abusar de uma [**Marcação Pendente - Injeção HTML sem script**](../dangling-markup-html-scriptless-injection.md)?
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?
3. O atributo em que você está preso suporta execução de JS?
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 um código JS diferente?
3. Seus inputs estão em literais de modelo \`\`?
4. Você pode contornar proteções?
4. Função **JavaScript** sendo **executada**
1. Você pode indicar o nome da função a ser executada. ex.: `?callback=alert(1)`
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 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ê pode explorar um **XSS Refletido**.
* **Armazenado e refletido**: Se você descobrir que um valor controlado por você é salvo no servidor e é refletido toda vez que você acessa uma página, você pode explorar um **XSS Armazenado**.
* **Acessado via JS**: Se você descobrir que um valor controlado por você está sendo acessado usando JS, você pode explorar um **DOM XSS**.
Ao tentar explorar um XSS, a primeira coisa que você precisa saber é **onde seu input está sendo refletido**. Dependendo do contexto, você poderá executar código JS arbitrário de diferentes maneiras.
Se seu input está **refletido 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ê pode usar.\
2. Se você **puder escapar do atributo, mas não da tag** (`>` está codificado ou excluído), dependendo da tag, você pode **criar um evento** que execute código JS: `" autofocus onfocus=alert(1) x="`
3. Se você **não puder escapar do atributo** (`"` está sendo codificado ou excluído), então, dependendo de **qual atributo** seu valor está sendo refletido e **se você controla todo o valor ou apenas uma parte**, você poderá abusar dele. Por **exemplo**, se você controlar um evento como `onclick=`, poderá fazer com que ele execute código arbitrário quando 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 seu input está refletido dentro de tags "**inexploráveis**", você pode 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="`**
Nesse caso, seu input é refletido entre as tags **`<script> [...] </script>`** de uma página HTML, dentro de um arquivo `.js` ou dentro de um atributo usando o protocolo **`javascript:`**:
* Se refletido entre as tags **`<script> [...] </script>`**, mesmo que seu input esteja dentro de qualquer tipo de aspas, você pode tentar injetar `</script>` e escapar desse contexto. Isso funciona porque o **navegador primeiro analisará as tags HTML** e depois o conteúdo, portanto, não perceberá que sua tag `</script>` injetada está dentro do código HTML.
* Se refletido **dentro de uma string JS** e o último truque não estiver funcionando, você precisará **sair** da string, **executar** seu código e **reconstruir** o código JS (se houver algum erro, ele não será executado):
* Se refletido dentro de literais de modelo, você pode **incorporar expressões JS** usando a sintaxe `${ ... }`: `` var greetings = `Hello, ${alert(1)}` ``
Portanto, se você tiver cenários em que pode **injetar código JS depois de um objeto não declarado** ser usado, você pode **corrigir a sintaxe** declarando-o (para que seu código seja executado em vez de gerar um erro):
Para obter mais informações sobre o Hoisting do JavaScript, verifique: [https://jlajara.gitlab.io/Javascript\_Hoisting\_in\_XSS\_Scenarios](https://jlajara.gitlab.io/Javascript\_Hoisting\_in\_XSS\_Scenarios)
Várias páginas da web têm endpoints que **aceitam como parâmetro o nome da função a ser executada**. Um exemplo comum de se ver na prática é algo como: `?callback=callbackFunc`.
Uma boa maneira de descobrir se algo fornecido diretamente pelo usuário está tentando ser executado é **modificar o valor do parâmetro** (por exemplo, para 'Vulnerable') e procurar no console por erros como:
Caso esteja vulnerável, você pode ser capaz de **disparar um alerta** apenas enviando o valor: **`?callback=alert(1)`**. No entanto, é muito comum que esses endpoints **validem o conteúdo** para permitir apenas letras, números, pontos e sublinhados (**`[\w\._]`**).
No entanto, mesmo com essa limitação, ainda é possível realizar algumas ações. Isso ocorre porque você pode usar esses caracteres válidos para **acessar qualquer elemento no DOM**:
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.
Há **código JS** que está usando de forma **insegura** alguns **dados controlados por um atacante**, como `location.href`. Um atacante pode abusar disso para executar código JS arbitrário.
Esse tipo de XSS pode ser encontrado **em qualquer lugar**. Eles não dependem apenas da exploração do cliente de um aplicativo da 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 muito mais.\
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 do `<` para criar novas tags: apenas tente **refletir** esse **caractere** e verifique se ele está sendo **codificado em HTML** ou **removido** ou se está sendo **refletido sem alterações**. **Somente nesse último caso você poderá explorar esse caso**.\
Mas, se estiver sendo utilizado um sistema de lista negra/branca de tags/atributos, você precisará **forçar a entrada para descobrir quais tags** você pode criar.\
Depois de **localizar quais tags são permitidas**, você precisará **forçar a entrada de atributos/eventos** dentro das tags válidas encontradas para ver como pode atacar o contexto.
Acesse [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) e clique em _**Copiar tags para a área de transferência**_. Em seguida, envie todas elas usando o Burp Intruder e verifique se alguma tag não foi identificada como maliciosa pelo WAF. Depois de descobrir quais tags você pode usar, você pode **forçar a entrada de todos os eventos** usando as tags válidas (na mesma página da web, clique em _**Copiar eventos para a área de transferência**_ e siga o mesmo procedimento anterior).
Se você não encontrou nenhuma tag HTML válida, pode tentar **criar uma tag personalizada** e executar código JS com o atributo `onfocus`. Na solicitação XSS, você precisa terminar a URL com `#` para fazer a página **focar nesse objeto** e **executar** o código:
**Mais XSSs pequenos para diferentes ambientes** o payload [**pode ser encontrado aqui**](https://github.com/terjanq/Tiny-XSS-Payloads) e [**aqui**](https://tinyxss.terjanq.me).
Se, para explorar a vulnerabilidade, você precisa que o **usuário clique em um link ou em um formulário** com dados preenchidos antecipadamente, você pode tentar [**abusar do Clickjacking**](../clickjacking.md#xss-clickjacking) (se a página for vulnerável).
Se você acha que **é impossível criar uma tag HTML com um atributo para executar código JS**, você deve verificar [**Marcação Pendente**](../dangling-markup-html-scriptless-injection.md) porque você pode **explorar** a vulnerabilidade **sem** executar **código JS**.
Se você estiver **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 pode escapar da tag**, você pode criar novos atributos dentro da tag para tentar executar código JS, por exemplo, usando uma carga útil como (_observe que neste exemplo as aspas duplas são usadas para escapar do atributo, você não precisará delas se a entrada for refletida diretamente dentro da tag_):
Os eventos de estilo são uma técnica comum usada em ataques de Cross-Site Scripting (XSS). Esses ataques exploram a capacidade de injetar código malicioso em um site, permitindo que um invasor execute scripts arbitrários no navegador do usuário.
Os eventos de estilo são acionados quando ocorre uma interação com um elemento HTML específico, como um clique do mouse ou passagem do cursor. Eles são usados para modificar o estilo de um elemento, como a cor de fundo ou o tamanho da fonte.
No contexto de um ataque XSS, os eventos de estilo podem ser explorados para injetar código malicioso. Por exemplo, um invasor pode usar o evento "onmouseover" para executar um script que redireciona o usuário para um site falso ou rouba suas informações de login.
Para se proteger contra ataques de XSS baseados em eventos de estilo, é importante validar e sanitizar todas as entradas de usuário antes de exibi-las em um site. Isso pode ser feito usando funções de escape ou filtros de entrada para remover qualquer código malicioso potencial.
Além disso, é recomendável implementar uma política de segurança de conteúdo (Content Security Policy - CSP) para restringir o uso de eventos de estilo e outras técnicas de XSS. A CSP permite que os desenvolvedores especifiquem quais tipos de conteúdo são permitidos em um site, ajudando a prevenir ataques de XSS.
Mesmo que você **não consiga escapar do atributo** (`"` está sendo codificado ou excluído), dependendo de **qual atributo** seu valor está sendo refletido, **se você controla todo o valor ou apenas uma parte**, você poderá abusar dele. Por **exemplo**, se você controla um evento como `onclick=`, você poderá fazer com que ele execute código arbitrário quando clicado.\
Outro **exemplo** interessante é o atributo `href`, onde você pode usar o protocolo `javascript:` para executar código arbitrário: **`href="javascript:alert(1)"`**
Os caracteres **codificados em HTML** dentro do valor dos atributos das tags HTML são **decodificados em tempo de execução**. Portanto, algo como o seguinte será válido (o payload está em negrito): `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`'-alert(1)-'`**`';">Go Back </a>`
Às vezes, ao tentar explorar uma vulnerabilidade de Cross-Site Scripting (XSS), você pode encontrar filtros que bloqueiam certos caracteres ou palavras-chave. No entanto, é possível contornar esses filtros usando a codificação Unicode.
A codificação Unicode permite representar caracteres especiais usando sequências de escape. Ao usar a codificação Unicode, você pode substituir caracteres bloqueados por suas representações Unicode correspondentes.
Por exemplo, se o caractere "<" estiver bloqueado, você pode substituí-lo por sua representação Unicode "<". Dessa forma, o filtro não reconhecerá o caractere bloqueado e permitirá que ele passe.
Aqui está um exemplo de como usar a codificação Unicode para contornar um filtro que bloqueia o caractere "<":
Neste exemplo, o caractere "<" é substituído por "\u003c" e o caractere ">" é substituído por "\u003e". Isso permite que o código JavaScript seja executado sem ser bloqueado pelo filtro.
Lembre-se de que a codificação Unicode pode variar dependendo do contexto e do conjunto de caracteres usado. Portanto, é importante entender como o filtro está configurado e quais caracteres estão sendo bloqueados antes de tentar contorná-lo usando a codificação Unicode.
Aqui 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, outros não.
**Em geral**, o protocolo `javascript:` pode ser **usado em qualquer tag que aceite o atributo `href`** e na **maioria** das tags que aceitam o **atributo `src`** (exceto `<img`).
Além disso, há outro **truque interessante** para esses casos: **Mesmo que sua entrada dentro de `javascript:...` esteja sendo codificada em URL, ela será decodificada antes de ser executada.** Portanto, se você precisar **escapar** da **string** usando uma **aspas simples** e perceber que **ela está sendo codificada em URL**, lembre-se de que **não importa**, ela será **interpretada** como uma **aspas simples** durante o **tempo de execução**.
Observe que se você tentar **usar ambos**`URLencode + HTMLencode` em qualquer ordem para codificar a **carga útil**, isso **não funcionará**, mas você pode **misturá-los dentro da carga útil**.
Você pode usar a codificação **Hexadecimal** e **Octal** dentro do atributo `src` do `iframe` (pelo menos) para declarar **tags HTML para executar JS**:
Reverse tab nabbing is a type of cross-site scripting (XSS) attack that targets users who have multiple tabs open in their web browser. The attack takes advantage of the trust users have in the websites they visit.
When a user opens a new tab and navigates to a different website, the original website can still execute JavaScript code in the background. This allows an attacker to modify the content of the original website and display a phishing page or malicious content.
To perform a reverse tab nabbing attack, the attacker first injects malicious code into a vulnerable website. This code typically includes a JavaScript function that detects when the user switches tabs. When the user switches to a different tab, the malicious code modifies the content of the original website to display the attacker's phishing page.
The phishing page is designed to look like a legitimate website, such as a login page for a popular service. When the user enters their credentials on the phishing page, the attacker captures the information and can use it for malicious purposes, such as identity theft or unauthorized access to accounts.
To protect against reverse tab nabbing attacks, users should be cautious when switching between tabs and ensure they only enter sensitive information on trusted websites. Website owners should also implement security measures, such as input validation and output encoding, to prevent XSS vulnerabilities that can be exploited for reverse tab nabbing attacks.
Se você pode injetar qualquer URL em uma tag **`<a href=`** arbitrária que contenha os atributos **`target="_blank"`** e **`rel="opener"`**, verifique a **página a seguir para explorar esse comportamento**:
Primeiro, verifique esta página ([https://portswigger.net/web-security/cross-site-scripting/cheat-sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)) para obter informações úteis sobre **manipuladores de eventos "on"**.\
Caso haja uma lista negra que impeça você de criar esses manipuladores de eventos, você pode tentar as seguintes bypasses:
<buttonpopovertarget="newsletter">Subscribe to newsletter</button>
<divpopoverid="newsletter">Newsletter popup</div>
```
A partir [**daqui**](https://portswigger.net/research/xss-in-hidden-input-fields): Você pode executar um **payload XSS dentro de um atributo oculto**, desde que você possa **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 chave de acesso. Aqui está o vetor:
Se você encontrou um **XSS em uma parte muito pequena** da web que requer algum tipo de interação (talvez um pequeno link no rodapé com um elemento onmouseover), você pode tentar **modificar o espaço que o elemento ocupa** para maximizar as probabilidades de o link ser acionado.
Este truque foi retirado de [https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703](https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703)
Nesses casos, sua **entrada** será **refletida dentro do código JS** de um arquivo `.js` ou entre as tags `<script>...</script>` ou entre eventos HTML que podem executar código JS ou entre atributos que aceitam o protocolo `javascript:`.
Se o seu código for inserido dentro de `<script> [...] var input = 'dados refletidos' [...] </script>`, você pode facilmente **escapar fechando a tag `<script>`**:
Observe que neste exemplo **nem mesmo fechamos a aspa simples**, mas isso não é necessário, pois o **navegador primeiro realiza a análise HTML** para identificar os elementos da página, incluindo blocos de script, e só depois realiza a análise JavaScript para entender e executar os scripts incorporados.
Se `<>` estiverem sendo sanitizados, ainda é possível **escapar a string** onde sua entrada está sendo **localizada** e **executar JS arbitrário**. É importante **corrigir a sintaxe do JS**, pois se houver erros, o código JS não será executado:
Para construir **strings** além de aspas simples e duplas, o JS também aceita **backticks****` `` `**. Isso é conhecido como template literals, pois permite **incorporar expressões JS** usando a sintaxe `${ ... }`.\
Portanto, se você perceber 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**:
Cross-site scripting (XSS) é uma vulnerabilidade comum em aplicações web que permite que um atacante injete código malicioso em páginas da web visualizadas por outros usuários. Uma forma de explorar essa vulnerabilidade é através da execução de código codificado.
A execução de código codificado ocorre quando um atacante consegue injetar código malicioso em uma página da web que será executado pelo navegador do usuário. Isso pode ser feito através da inserção de código em campos de entrada, como formulários, URLs ou até mesmo em campos de comentários.
O código malicioso é geralmente codificado para evitar a detecção pelos filtros de segurança da aplicação. Isso pode ser feito usando técnicas como a codificação de caracteres especiais, a utilização de entidades HTML ou a codificação em base64.
Quando o código malicioso é executado pelo navegador do usuário, ele pode realizar várias ações prejudiciais, como roubar informações confidenciais, redirecionar o usuário para sites maliciosos, modificar o conteúdo da página ou até mesmo controlar completamente o navegador do usuário.
Considere um campo de pesquisa em um site que não faz a devida validação dos dados inseridos pelo usuário. Um atacante pode inserir o seguinte código malicioso no campo de pesquisa:
```html
<script>alert('Seu computador foi comprometido!');</script>
Quando um usuário realiza uma pesquisa e visualiza os resultados, o código malicioso será executado pelo navegador do usuário, exibindo uma mensagem de alerta enganosa.
Para prevenir a execução de código codificado, é importante implementar práticas de segurança adequadas em aplicações web. Algumas medidas de prevenção incluem:
O Unicode Encode JS execution é uma técnica de ataque que explora vulnerabilidades de Cross-Site Scripting (XSS) em aplicações web. Nesse tipo de ataque, o invasor utiliza a codificação Unicode para injetar e executar código JavaScript malicioso no navegador do usuário.
1. O invasor identifica uma vulnerabilidade de XSS em uma aplicação web.
2. O invasor utiliza a codificação Unicode para escapar dos filtros de entrada e injetar código JavaScript malicioso.
3. O código JavaScript malicioso é executado no navegador do usuário, permitindo que o invasor realize ações indesejadas, como roubo de informações confidenciais, redirecionamento para sites maliciosos ou manipulação do conteúdo da página.
Suponha que uma aplicação web tenha uma vulnerabilidade de XSS em um campo de entrada de texto. O invasor pode explorar essa vulnerabilidade inserindo o seguinte código JavaScript malicioso:
Nesse exemplo, o código JavaScript malicioso é codificado usando a notação Unicode `\uXXXX`, onde `XXXX` representa o código Unicode do caractere. O código injetado cria uma imagem com um evento `onerror` que exibe um alerta com a mensagem "XSS". Quando o usuário visualiza a página e o campo de entrada é renderizado, o código JavaScript é executado, resultando na exibição do alerta.
#### Prevenção
Para prevenir ataques de Unicode Encode JS execution, é importante implementar práticas de segurança adequadas, como:
- Validar e sanitizar todas as entradas de usuário.
- Utilizar mecanismos de escape apropriados para evitar a execução de código JavaScript malicioso.
- Implementar políticas de segurança de conteúdo (CSP) para restringir o carregamento de scripts de fontes não confiáveis.
- Manter a aplicação web atualizada com as últimas correções de segurança.
#### Conclusão
A técnica de Unicode Encode JS execution é uma forma comum de explorar vulnerabilidades de XSS em aplicações web. Compreender como esse tipo de ataque funciona e adotar medidas preventivas adequadas é essencial para proteger a segurança das aplicações e dos usuários.
Quando exploramos vulnerabilidades de XSS (Cross-Site Scripting), muitas vezes nos deparamos com filtros que tentam bloquear a injeção de código malicioso. Um desses filtros comuns é a substituição de espaços em branco dentro do código JavaScript.
Essa técnica de substituição de espaço é usada para contornar os filtros de XSS que procuram por padrões específicos de código malicioso. Ao substituir os espaços em branco por caracteres equivalentes, podemos evitar a detecção do código malicioso pelos filtros.
Existem várias formas de realizar essa substituição de espaço, como:
- Usar caracteres de espaço alternativos, como o caractere de espaço em branco não quebrável (` `) ou o caractere de espaço em branco em largura total (`\u200b`).
- Utilizar caracteres de escape, como o caractere de barra invertida (`\`) seguido por um espaço em branco (`\ `) ou o caractere de barra invertida seguido por um caractere de nova linha (`\n`).
- Utilizar codificação hexadecimal ou unicode para representar o espaço em branco, como `%20` ou `\x20`.
Ao aplicar essas substituições de espaço dentro do código JavaScript injetado, podemos contornar os filtros de XSS e executar nosso código malicioso no contexto da página vulnerável.
É importante lembrar que a substituição de espaço é apenas uma técnica para contornar filtros de XSS e não deve ser a única medida de segurança adotada. É fundamental implementar outras práticas recomendadas, como a validação e sanitização adequada dos dados de entrada, para garantir a segurança das aplicações web.
Os espaços em branco no JavaScript referem-se a qualquer tipo de espaço em branco, como espaços, tabulações e quebras de linha, presentes em um código JavaScript. Embora os espaços em branco sejam normalmente ignorados pelo interpretador JavaScript, eles podem desempenhar um papel importante na legibilidade e organização do código.
No entanto, em certos casos, os espaços em branco podem ser explorados por hackers para realizar ataques de Cross-Site Scripting (XSS). Isso ocorre quando um invasor insere código malicioso em um campo de entrada que não é devidamente validado ou sanitizado. O código malicioso é então executado no navegador do usuário, permitindo que o invasor roube informações confidenciais, como senhas ou cookies de autenticação.
Ao adotar essas práticas, os desenvolvedores podem reduzir significativamente o risco de ataques de XSS baseados em espaços em branco e garantir a segurança de suas aplicações web.
Quando se trata de ataques de Cross-Site Scripting (XSS), é importante estar ciente de que o código JavaScript pode ser injetado não apenas em campos de entrada de dados, mas também em comentários. Isso ocorre porque os comentários em HTML não são processados pelo navegador, mas ainda são visíveis no código-fonte da página.
Os atacantes podem explorar essa vulnerabilidade inserindo código JavaScript malicioso dentro de um comentário HTML. Embora o código não seja executado pelo navegador, ele pode ser usado para realizar ataques de phishing, roubo de cookies ou redirecionamento do usuário para sites maliciosos.
Para evitar esse tipo de ataque, é fundamental garantir que todos os comentários sejam devidamente sanitizados e escapados antes de serem exibidos na página. Isso pode ser feito usando funções de escape específicas da linguagem de programação ou por meio de bibliotecas de sanitização de HTML confiáveis.
Além disso, é importante manter-se atualizado sobre as melhores práticas de segurança e implementar medidas de segurança adicionais, como a filtragem de entrada de dados e a validação adequada dos campos de entrada. Dessa forma, é possível reduzir significativamente o risco de ataques de XSS bem-sucedidos.
O XSS (Cross-Site Scripting) é uma vulnerabilidade comum em aplicações web que permite que um invasor injete código JavaScript malicioso em páginas da web visualizadas por outros usuários. Uma técnica comum usada em ataques XSS é explorar a capacidade do JavaScript de ser executado sem a necessidade de parênteses.
Quando o código JavaScript é inserido em um campo de entrada não sanitizado e exibido em uma página da web, ele pode ser interpretado e executado pelo navegador do usuário. No entanto, para evitar a detecção e contornar as proteções de segurança, os invasores podem usar técnicas para evitar o uso de parênteses no código JavaScript injetado.
Ao remover os parênteses, o código JavaScript pode ser disfarçado como texto normal e passar despercebido pelos filtros de segurança. Isso permite que o código seja executado quando a página é carregada ou quando um evento específico é acionado, dependendo da implementação específica do ataque XSS.
É importante destacar que a remoção dos parênteses não é uma técnica exclusiva de ataques XSS e pode ser usada em outros contextos para ocultar código malicioso. Portanto, é fundamental que os desenvolvedores implementem medidas de segurança adequadas, como a sanitização de entradas e a validação de dados, para mitigar o risco de ataques XSS.
Reflect.apply.call`${alert}${window}${[1337]}` //Pass the function to call (“alert”), then the “this” value to that function (“window”) which avoids the illegal invocation error and finally an array of arguments to pass to the function.
Reflect.set.call`${location}${'href'}${'javascript:alert\x281337\x29'}` // It requires a valid object in the first argument (“location”), a property in the second argument and a value to assign in the third.
// The “has instance” symbol allows you to customise the behaviour of the instanceof operator, if you set this symbol it will pass the left operand to the function defined by the symbol.
Existe **código JS** que está usando **dados controlados por um atacante de forma insegura**, como `location.href`. Um atacante poderia abusar disso para executar código JS arbitrário.\
Além disso, não se esqueça que **no final do post mencionado** você pode encontrar uma explicação sobre [**ataques de Clobbering DOM**](dom-xss.md#dom-clobbering).
Você pode verificar se os **valores refletidos** estão sendo **normalizados em unicode** no servidor (ou no lado do cliente) e abusar dessa funcionalidade para contornar as proteções. [**Encontre um exemplo aqui**](../unicode-injection/#xss-cross-site-scripting).
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.\
Se você descobrir que pode **injetar cabeçalhos em uma resposta de redirecionamento 302**, você pode tentar fazer com que o navegador execute JavaScript arbitrário. Isso não é trivial, pois os navegadores modernos não interpretam o corpo da resposta HTTP se o código de status da resposta HTTP for 302, portanto, apenas uma carga útil de script entre sites é inútil.
Neste [**relatório**](https://www.gremwell.com/firefox-xss-302) e [**neste**](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 a carga útil de XSS dentro do corpo.\
Se você puder 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.
(De [**aqui**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Se você tentar carregar um script com um **tipo de conteúdo** como `application/octet-stream`, o Chrome lançará o seguinte erro:
> 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 do tipo MIME está habilitada.
Os únicos **tipos de conteúdo** que o Chrome suportará para executar 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)
(De [**aqui**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Então, quais tipos podem ser indicados para carregar um script?
* [**webbundle**](https://web.dev/web-bundles/): Web Bundles é um recurso que permite empacotar um conjunto de dados (HTML, CSS, JS...) em um arquivo **`.wbn`**.
Esse comportamento foi utilizado neste [**relatório**](https://github.com/zwade/yaca/tree/master/solution) para remapear uma biblioteca para eval e abusá-la, podendo desencadear XSS.
* [**speculationrules**](https://github.com/WICG/nav-speculation)**:** Essa funcionalidade é principalmente para resolver alguns problemas causados pelo pré-renderização. Funciona da seguinte forma:
(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:
Em outros navegadores, outros **`Tipos de Conteúdo`** 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)
Quando algo como **`"alguns dados {{template}}".replace("{{template}}", <user_input>)`** é usado. O atacante pode usar [**substituições especiais de string**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global\_Objects/String/replace#specifying\_a\_string\_as\_the\_replacement) para tentar contornar algumas proteções: ``"123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"}))``
Por exemplo, neste [**artigo**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA), isso foi usado para **escapar uma string JSON** dentro de um script e executar código arbitrário.
Se **tudo é indefinido** antes de executar código não confiável (como neste [**artigo**](https://blog.huli.tw/2022/02/08/en/what-i-learned-from-dicectf-2022/#miscx2fundefined55-solves)), é possível gerar objetos úteis "do nada" para abusar da execução de código arbitrário não confiável:
* Usando import()
```javascript
// although import "fs" doesn’t work, import('fs') does.
[De acordo com isso](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050) os módulos são envolvidos pelo Node.js dentro de uma função, como este exemplo:
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`**: 
De forma semelhante ao exemplo anterior, é possível **usar manipuladores de erros** para acessar o **invólucro** do módulo e obter a função **`require`**:
* JSFuck mais sofisticado: [https://medium.com/@Master\_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce](https://medium.com/@Master\_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce)
O XSS (Cross-Site Scripting) é uma vulnerabilidade comum em aplicações web que permite que um atacante injete scripts maliciosos em páginas web visualizadas por outros usuários. Esses scripts podem ser usados para roubar informações confidenciais, como cookies de autenticação, ou redirecionar o usuário para sites maliciosos.
1.**Reflected XSS**: os dados fornecidos pelo usuário são imediatamente refletidos na resposta do servidor, sem serem armazenados no banco de dados. Isso permite que o atacante injete um script malicioso na resposta e engane os usuários que visualizam a página.
2.**Stored XSS**: os dados fornecidos pelo usuário são armazenados no banco de dados e exibidos em outras páginas posteriormente. Isso permite que o atacante injete um script malicioso que será exibido para todos os usuários que acessarem a página.
3.**DOM-based XSS**: o ataque ocorre no lado do cliente, manipulando o Document Object Model (DOM) da página. O atacante injeta um script malicioso que é executado no navegador do usuário, alterando o comportamento da página.
Para explorar uma vulnerabilidade de XSS, o atacante precisa identificar um ponto de entrada onde os dados fornecidos pelo usuário são refletidos ou armazenados sem a devida sanitização. Em seguida, o atacante pode injetar um script malicioso que será executado quando a página for visualizada por outros usuários.
O XSS é uma vulnerabilidade séria que pode comprometer a segurança de aplicações web e expor os usuários a riscos. É fundamental que os desenvolvedores implementem práticas de segurança adequadas para prevenir e mitigar essa vulnerabilidade. Além disso, os usuários devem estar cientes dos riscos e tomar precauções ao acessar sites desconhecidos ou suspeitos.
Você **não conseguirá acessar os cookies do JavaScript** se a flag HTTPOnly estiver definida no cookie. Mas aqui você tem [algumas maneiras de contornar essa proteção](../hacking-with-cookies/#httponly) se tiver sorte o suficiente.
Durante um teste de penetração, pode ser útil identificar os endereços IP internos de uma rede. Isso pode ajudar a mapear a infraestrutura e identificar possíveis alvos para ataques.
1.**ARP Scanning**: O ARP (Address Resolution Protocol) é usado para mapear endereços IP para endereços MAC em uma rede local. Ao realizar uma varredura ARP, você pode obter uma lista dos IPs internos e seus respectivos endereços MAC.
2.**DNS Zone Transfer**: Se o servidor DNS estiver mal configurado, é possível realizar uma transferência de zona para obter uma lista de todos os registros DNS, incluindo os IPs internos.
3.**Ping Sweep**: O ping sweep envolve o envio de pacotes ICMP Echo Request para uma faixa de endereços IP e verificar quais IPs estão respondendo. Isso pode revelar os IPs internos ativos na rede.
Lembre-se de que a obtenção de IPs internos sem permissão é considerada uma atividade ilegal. Sempre obtenha autorização por escrito antes de realizar qualquer teste de penetração.
The `port_scanner_fetch.py` script is a simple port scanner that uses the `fetch` function from the `requests` library to send HTTP requests to a target host and port. It is designed to quickly scan a range of ports and determine if they are open or closed.
To use the script, you need to provide the target host and a list of ports to scan. The script will then iterate through the list of ports and send a GET request to each port on the target host. If a response is received, the port is considered open. If no response is received, the port is considered closed.
The script utilizes the `fetch` function from the `requests` library, which allows for asynchronous requests. This means that multiple requests can be sent simultaneously, making the scanning process faster.
Replace `<target_host>` with the IP address or domain name of the target host, and `<port1,port2,port3,...>` with the list of ports you want to scan, separated by commas.
**Note:** This script is intended for educational and testing purposes only. Unauthorized port scanning is illegal and can result in severe consequences. Always ensure that you have proper authorization before conducting any port scanning activities.
This tool is a simple port scanner that uses websockets to establish a connection with the target host and check for open ports. It can be used during a penetration test to identify potential entry points into a system.
This tool is intended for educational and penetration testing purposes only. The misuse of this tool or any unauthorized access to systems is strictly prohibited. The author is not responsible for any illegal activities performed using this tool.
Revise a lista de portas bloqueadas no Chrome [**aqui**](https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net\_util.cc) e no Firefox [**aqui**](https://www-archive.mozilla.org/projects/netlib/portbanning#portlist).
A captura de preenchimento automático de senhas é uma técnica utilizada para explorar vulnerabilidades de cross-site scripting (XSS) em aplicações web.
When a user visits a vulnerable website, the attacker injects malicious code that captures the user's saved passwords from the browser's auto-fill feature. This can be achieved by injecting JavaScript code that listens for changes in the input fields and sends the captured data to a remote server controlled by the attacker.
Quando um usuário visita um site vulnerável, o atacante injeta um código malicioso que captura as senhas salvas do usuário a partir do recurso de preenchimento automático do navegador. Isso pode ser alcançado através da injeção de código JavaScript que monitora as alterações nos campos de entrada e envia os dados capturados para um servidor remoto controlado pelo atacante.
To perform this attack, the attacker needs to identify a vulnerable input field where the auto-fill feature is enabled. This can be a login form, registration form, or any other form that requires user input. The attacker then crafts a payload that exploits the XSS vulnerability and injects it into the vulnerable input field.
Para realizar esse ataque, o atacante precisa identificar um campo de entrada vulnerável onde o recurso de preenchimento automático esteja habilitado. Isso pode ser um formulário de login, formulário de registro ou qualquer outro formulário que exija entrada do usuário. O atacante então cria um payload que explora a vulnerabilidade XSS e o injeta no campo de entrada vulnerável.
When the victim interacts with the injected input field, the malicious payload executes, capturing the saved passwords and sending them to the attacker's server. The attacker can then use these captured passwords for unauthorized access to the victim's accounts.
Quando a vítima interage com o campo de entrada injetado, o payload malicioso é executado, capturando as senhas salvas e enviando-as para o servidor do atacante. O atacante pode então usar essas senhas capturadas para acessar as contas da vítima sem autorização.
To protect against auto-fill passwords capture attacks, web developers should implement proper input validation and output encoding to prevent XSS vulnerabilities. Users should also be cautious when entering sensitive information on websites and consider using password managers instead of relying on the browser's auto-fill feature.
Para se proteger contra ataques de captura de preenchimento automático de senhas, os desenvolvedores web devem implementar validação adequada de entrada e codificação de saída para evitar vulnerabilidades de XSS. Os usuários também devem ter cuidado ao inserir informações sensíveis em sites e considerar o uso de gerenciadores de senhas em vez de depender do recurso de preenchimento automático do navegador.
Quando qualquer dado é inserido no campo de senha, o nome de usuário e a senha são enviados para o servidor do atacante, mesmo que o cliente selecione uma senha salva e não escreva nada, as credenciais serão exfiltradas.
O roubo de mensagens PostMessage é uma técnica de ataque que visa explorar vulnerabilidades de Cross-Site Scripting (XSS) para interceptar e roubar mensagens enviadas por meio do método PostMessage. Essa técnica é particularmente eficaz em cenários em que um site confiável permite a comunicação entre diferentes domínios por meio do uso do PostMessage.
O roubo de mensagens PostMessage é uma técnica de ataque que explora vulnerabilidades de XSS para interceptar e roubar mensagens enviadas por meio do método PostMessage. É essencial que os desenvolvedores implementem práticas de segurança adequadas para proteger seus aplicativos e usuários contra esse tipo de ataque.
<!-- html5sec - eventhandler - element fires an "onpageshow" event without user interaction on all modern browsers. This can be abused to bypass blacklists as the event is not very well known. -->
<!-- ... add more CDNs, you'll get WARNING: Tried to load angular more than once if multiple load. but that does not matter you'll get a HTTP interaction/exfiltration :-]... -->
A partir [**deste artigo**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay), é possível aprender que mesmo que alguns valores desapareçam do JS, ainda é possível encontrá-los nos atributos JS de diferentes objetos. Por exemplo, é possível encontrar um input de uma REGEX mesmo depois que o valor do input da regex foi removido:
Conseguiu XSS em um **site que utiliza cache**? Tente **atualizar isso para SSRF** através da Injeção de Include do Lado do Servidor (Edge Side Include Injection) com este payload:
Se uma página da web estiver 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**.\
Portanto, 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**.
AMP é uma tecnologia conhecida por desenvolver páginas da web super rápidas em clientes móveis. **AMP é um conjunto de tags HTML suportadas por JavaScript** que facilita a funcionalidade com um foco adicional em desempenho e segurança. Existem [componentes AMP](https://amp.dev/documentation/components/?format=websites) para tudo, desde carrosséis até elementos de formulário responsivos, até a obtenção de conteúdo atualizado de pontos de extremidade remotos.
O formato [**AMP para Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) fornece [um subconjunto de componentes AMP](https://github.com/ampproject/amphtml/blob/master/docs/spec/email/amp-email-components.md) que você pode usar em mensagens de e-mail. Os destinatários de e-mails AMP podem visualizar e interagir com os componentes AMP diretamente no e-mail.
**Dica de recompensa por bugs**: **inscreva-se** no **Intigriti**, uma plataforma premium de **recompensas por bugs criada por hackers, para hackers**! Junte-se a nós em [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) hoje mesmo e comece a ganhar recompensas de até **$100.000**!
* Você trabalha em uma **empresa de cibersegurança**? Gostaria de ver sua **empresa anunciada no HackTricks**? Ou gostaria de ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo Telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
