Se você está interessado em **carreira de hacking** e hackear o inquebrável - **estamos contratando!** (_fluência em polonês escrita e falada necessária_).
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 está sendo refletido/usado.
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 Modelo do Lado do Cliente**](../client-side-template-injection-csti.md).
5. Se você não puder criar tags HTML que executem código JS, poderia abusar de uma [**Marcação Pendente - Injeção de HTML sem script**](../dangling-markup-html-scriptless-injection/).
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ê poderá 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ê poderá explorar um **XSS Armazenado**.
* **Acessado via JS**: Se você descobrir que um valor controlado por você está sendo acessado usando JS, você poderá explorar um **DOM XSS**.
Ao tentar explorar um XSS, a primeira coisa que você precisa saber é **onde sua entrada está sendo refletida**. Dependendo do contexto, você poderá executar código JS arbitrário de diferentes maneiras.
Se sua entrada é **refletida no HTML puro** 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.\
1.**Escapar do atributo e da tag** (então você estará no HTML puro) e criar uma nova tag HTML para abusar: `"><img [...]`
2. Se você **puder escapar do atributo, mas não da tag** (`>` está codificado ou excluído), dependendo da tag, você poderia **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ê 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)"`**
4. Se sua entrada é refletida dentro de "**tags inexplorá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="`**
Neste caso, a sua entrada é refletida 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 a sua entrada 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ê precisaria **sair** da string, **executar** o 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)}` ``
A elevação de Javascript refere-se à oportunidade de **declarar funções, variáveis ou classes após serem usadas, para que seja possível explorar cenários onde um XSS está usando variáveis ou funções não declaradas.**\
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 é 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 'Vulnerável') e procurar no console por erros como:
Caso seja 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 poderia 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 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.\
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 ele está sendo **codificado em HTML** ou **excluído** ou se está sendo **refletido sem alterações**. **Somente no último caso você poderá explorar esse caso**.\
Mas, se estiver sendo usado um sistema de listagem negra/listagem branca de tags/atributos, você precisará **forçar a barra em quais tags** você pode criar.\
Depois de **localizar quais tags são permitidas**, você precisará **forçar a barra em 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 pode usar, você pode **forçar a barra em 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 não encontrar nenhuma tag HTML válida, você 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 XSS pequenos para diferentes ambientes** payload [**pode ser encontrado aqui**](https://github.com/terjanq/Tiny-XSS-Payloads) e [**aqui**](https://tinyxss.terjanq.me).
Se, para explorar a vulnerabilidade, precisar que o **utilizador clique num link ou num formulário** com dados preenchidos antecipadamente, pode tentar [**abusar do Clickjacking**](../clickjacking.md#xss-clickjacking) (se a página for vulnerável).
Se achar que **é impossível criar uma tag HTML com um atributo para executar código JS**, deve verificar [**Dangling Markup**](../dangling-markup-html-scriptless-injection/) porque pode **explorar** a vulnerabilidade **sem** executar código **JS**.
Se estiver **dentro de uma tag HTML**, a primeira coisa que 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 **não conseguir escapar da tag**, pode criar novos atributos dentro da tag para tentar executar código JS, por exemplo, usando uma carga útil como (_note que neste exemplo as aspas duplas são usadas para escapar do atributo, não precisará delas se a sua entrada for refletida diretamente dentro da tag_):
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 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)"`**
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)-'`**`';">Voltar </a>`
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 e 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`** (mas não `<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 o **payload**, isso **não funcionará**, mas você pode **misturá-los dentro do payload**.
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**:
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 você 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 tecla 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)
Neste caso, 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 seu código for inserido dentro de `<script> [...] var input = 'dados refletidos' [...] </script>` você poderia facilmente **escapar fechando a tag `<script>`**:
Note que neste exemplo **nem sequer fechamos a aspa simples**. Isso ocorre porque o **parsing HTML é realizado primeiro pelo navegador**, o que envolve a identificação dos elementos da página, incluindo blocos de script. O parsing do JavaScript para entender e executar os scripts incorporados é realizado apenas posteriormente.
Se `< >` estiverem sendo sanitizados, você ainda pode **escapar a string** onde sua entrada está **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 **acento grave****` `` `**. Isso é conhecido como literais de modelo, pois permitem **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 acentos graves, você pode abusar da sintaxe `${ ... }` para executar **código JS arbitrário**:
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 de forma insegura por um atacante** como `location.href`. Um atacante poderia abusar disso para executar código JS arbitrário.\
**Devido à extensão da explicação das** [**vulnerabilidades DOM que foi movida para esta página**](dom-xss.md)**:**
Além disso, não se esqueça que **no final do post mencionado** você pode encontrar uma explicação sobre [**ataques de DOM Clobbering**](dom-xss.md#dom-clobbering).
Se você puder acionar um XSS enviando o payload dentro de um cookie, isso geralmente é um self-XSS. No entanto, se você encontrar um **subdomínio vulnerável ao XSS**, você poderia abusar desse XSS para injetar um cookie em todo o domínio, conseguindo acionar o XSS de cookie no domínio principal ou em outros subdomínios (aqueles vulneráveis ao XSS de cookie). Para isso, você pode usar o ataque de cookie tossing:
Você pode encontrar um grande abuso dessa técnica neste [**post de blog**](https://nokline.github.io/bugbounty/2024/06/07/Zoom-ATO.html).
### Enviando sua sessão para o administrador
Talvez um usuário possa compartilhar seu perfil com o administrador e se o self-XSS estiver dentro do perfil do usuário e o administrador acessá-lo, ele acionará a vulnerabilidade.
### 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 os clientes solicitem ajuda e para que o administrador 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.
Você poderia verificar se os **valores refletidos** estão sendo **normalizados em unicode** no servidor (ou no lado do cliente) e abusar dessa funcionalidade para contornar proteções. [**Encontre um exemplo aqui**](../unicode-injection/#xss-cross-site-scripting).
Devido às **atribuições 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.\
Por exemplo de formulário ([deste relatório](https://hackerone.com/reports/709336)), se você enviar a carga ú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 os 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 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 o payload 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á ativada.
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 poderiam 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...) juntos em um arquivo **`.wbn`**.
Este comportamento foi utilizado em [**este artigo**](https://github.com/zwade/yaca/tree/master/solution) para remapear uma biblioteca para eval e abusá-la pode acionar XSS.
* [**speculationrules**](https://github.com/WICG/nav-speculation)**:** Este recurso é principalmente para resolver alguns problemas causados pelo pré-renderização. Funciona assim:
(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 {{modelo}} dados".replace("{{modelo}}", <entrada_do_usuario>)`** é usado. O atacante poderia usar [**substituições de string especiais**](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 {{modelo}} 456".replace("{{modelo}}", JSON.stringify({"nome": "$'$`alert(1)//"}))``
Por exemplo, neste [**relatório**](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 em [**este 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 não confiável arbitrário:
[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`**:
- 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)
Você **não conseguirá acessar os cookies a partir 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.
Consulte a lista de portas banidas 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).
Quando são introduzidos dados 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.
<!-- 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 em diferentes objetos. Por exemplo, uma entrada de um REGEX ainda é possível de ser encontrada mesmo após o valor da entrada do regex ter sido removido:
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, com o objetivo de acelerar o desempenho da página 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 várias funcionalidades, acessíveis por meio de [componentes AMP](https://amp.dev/documentation/components/?format=websites).
O formato [**AMP para 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.
Se você está interessado em **carreira de hacking** e hackear o inquebrável - **estamos contratando!** (_fluência em polonês escrita e falada necessária_).
<summary><strong>Aprenda hacking AWS de zero a herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* 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** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
