**Dica de recompensa por bugs**: **inscreva-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, e comece a ganhar recompensas de até **$100,000**!
1. Verifique se **qualquer valor que você controla** (_parâmetros_, _caminho_, _cabeçalhos_?, _cookies_?) está sendo **refletido** no HTML ou **usado** pelo código **JS**.
2.**Encontre o contexto** onde está refletido/usado.
1. Verifique **quais símbolos você pode usar** e, dependendo disso, prepare o payload:
1. Em **HTML puro**:
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 motor 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 executam código JS, você poderia abusar de uma [**Marcação Pendente - Injeção sem scripts HTML**](../dangling-markup-html-scriptless-injection/)?
2. Dentro de uma **tag HTML**:
1. Você pode sair para o contexto de HTML puro?
2. Você pode criar novos eventos/atributos para executar código JS?
3. O atributo onde 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 sair da string e executar um código JS diferente?
3. Sua entrada está em literais de template ``?
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 web.
* **Refletido imediatamente**: Se você descobrir que o valor de um parâmetro ou até mesmo o caminho está sendo refletido na página web, você poderia 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ê poderia explorar um **XSS Armazenado**.
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` ... estas são apenas algumas das muitas possíveis tags HTML que você poderia usar.\
Além disso, lembre-se da [Injeção de Template do Lado do Cliente](../client-side-template-injection-csti.md).
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ê **pode escapar do atributo, mas não da tag** (`>` é 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** (`"` é 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á abusá-lo. Por **exemplo**, se você controla um evento como `onclick=` você poderá fazê-lo executar 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 "**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="`**
Neste caso, 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 sua entrada esteja dentro de qualquer tipo de aspas, você pode tentar injetar `</script>` e escapar deste contexto. Isso funciona porque o **navegador primeiro analisa 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 está 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 template, você pode **incorporar expressões JS** usando a sintaxe `${ ... }`: `` var greetings = `Hello, ${alert(1)}` ``
* **Codificação Unicode** funciona para escrever **código javascript válido**:
Elevação de Javascript refere-se à oportunidade de **declarar funções, variáveis ou classes depois de serem usadas, para que você possa abusar de cenários onde um XSS está utilizando 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 na prática é algo como: `?callback=callbackFunc`.
Uma boa maneira de descobrir se algo fornecido diretamente pelo usuário está tentando ser executado é **modificando o valor do parâmetro** (por exemplo, para 'Vulnerable') e procurando no console por erros como:
Caso esteja vulnerável, você poderia 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 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 um 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 **inseguramente** 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 em **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 neste 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 **deletado** ou se é **refletido sem alterações**. **Apenas no último caso você poderá explorar este caso**.\
Uma vez que você tenha **localizado quais tags são permitidas**, será necessário **forçar a descoberta de atributos/eventos** dentro das tags válidas encontradas para ver como você 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 descoberta como maliciosa pelo WAF. Uma vez que você tenha descoberto quais tags pode usar, você pode **forçar a descoberta 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 encontrar nenhuma tag HTML válida, você poderia tentar **criar uma tag personalizada** e executar código JS com o atributo `onfocus`. Na requisição XSS, você precisa terminar a URL com `#` para fazer a página **focar naquele objeto** e **executar** o código:
**Mais payloads de XSS pequenos para diferentes ambientes** podem ser encontrados [**aqui**](https://github.com/terjanq/Tiny-XSS-Payloads) e [**aqui**](https://tinyxss.terjanq.me).
Se, para explorar a vulnerabilidade, você precisar que o **usuário clique em um link ou um formulário** com dados pré-preenchidos, você poderia 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 [**Dangling Markup**](../dangling-markup-html-scriptless-injection/) porque você poderia **explorar** a vulnerabilidade **sem** executar código **JS**.
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 pode 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_):
Mesmo que você **não possa 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ê será capaz de abusar dele. 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)"`**
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>`
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 para URL, ela será decodificada antes de ser executada.** Então, se você precisar **escapar** da **string** usando uma **aspas simples** e perceber que **está sendo codificada para 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ê puder injetar qualquer URL em uma tag **`<a href=`** arbitrária que contém 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 encontrar manipuladores de eventos **"on"** úteis.\
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 chave 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 esse elemento ocupa** para maximizar as probabilidades de ativar o link.
Por exemplo, você poderia adicionar um estilo no elemento como: `position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`
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)
Nestes casos, sua **entrada** será **refletida dentro do código JS** de um arquivo `.js` ou entre 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ê poderia facilmente **escapar fechando a tag `<script>`**:
Note que neste exemplo **não fechamos sequer 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, você ainda pode **escapar da string** onde sua entrada está sendo **localizada** e **executar JS arbitrário**. É importante **corrigir a sintaxe JS**, porque se houver erros, o código JS não será executado:
Para construir **strings** além de aspas simples e duplas, JS também aceita **crases****`` ` ``**. Isso é conhecido como literais de modelo, pois permitem **incorporar expressões JS** usando a sintaxe `${ ... }`.\
Portanto, se você descobrir que sua entrada está sendo **refletida** dentro de uma string JS que está usando crases, 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á utilizando **dados controlados de forma insegura por um atacante** como `location.href`. Um atacante poderia abusar disso para executar código JS arbitrário.\
Além disso, não esqueça que **no final do post mencionado** você pode encontrar uma explicação sobre [**ataques de DOM Clobbering**](dom-xss.md#dom-clobbering).
Você pode verificar se os **valores refletidos** estão sendo **normalizados para unicode** no servidor (ou no lado do cliente) e abusar dessa funcionalidade para burlar proteções. [**Encontre um exemplo aqui**](../unicode-injection/#xss-cross-site-scripting).
Devido ao **RoR mass assignment**, aspas são inseridas no HTML e então 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ê poderia 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 cross-site scripting é inútil.
Neste [**relatório**](https://www.gremwell.com/firefox-xss-302) e [**neste outro**](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ê conseguir indicar o **callback** que o javascript vai **executar** limitado a esses caracteres. [**Leia esta seção deste post**](./#javascript-function) para encontrar como abusar deste 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 exibirá o seguinte erro:
> Recusado a executar 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 **Content-Type**s que permitirão que o Chrome execute um **script carregado** são os que estão dentro da const **`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…) juntos em um arquivo **`.wbn`**.
Este comportamento foi utilizado em [**este relatório**](https://github.com/zwade/yaca/tree/master/solution) para remapear uma biblioteca para eval a fim de abusar dela e desencadear 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 **`Content-Types`** podem ser usados para executar JS arbitrário, confira: [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 {{template}} dados".replace("{{template}}", <user_input>)`** é usado. O atacante poderia 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 [**relatório**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA), isso foi usado para **escapar de uma string JSON** dentro de um script e executar código arbitrário.
Se **tudo está indefinido** antes de executar código não confiável (como neste [**relatório**](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:
[De acordo com isto](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050), módulos são encapsulados pelo Node.js dentro de uma função, assim:
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`**: 
De maneira semelhante ao exemplo anterior, é possível **usar manipuladores de erro** 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)
Você **não poderá acessar os cookies pelo JavaScript** se a flag HTTPOnly estiver configurada no cookie. Mas aqui você tem [algumas maneiras de contornar essa proteção](../hacking-with-cookies/#httponly) se tiver sorte.
Revise 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 qualquer dado é introduzido 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 relatório**](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 em atributos JS em diferentes objetos. Por exemplo, uma entrada de um REGEX ainda é possível encontrá-la depois que o valor da entrada do regex foi removido:
Se uma página 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**.
Então, 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**.
AMP é uma tecnologia conhecida por desenvolver páginas web super rápidas em clientes móveis. **AMP é um conjunto de tags HTML suportadas por JavaScript** que facilmente habilita funcionalidades com um foco adicional em desempenho e segurança. Existem [componentes AMP](https://amp.dev/documentation/components/?format=websites) para tudo, desde carrosséis, a elementos de formulário responsivos, até a obtenção de conteúdo atualizado de endpoints 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. Destinatários de e-mails AMP podem visualizar e interagir com os componentes AMP diretamente no e-mail.
**Dica de bug bounty**: **inscreva-se** no **Intigriti**, uma plataforma premium de **bug bounty criada por hackers, para hackers**! Junte-se a nós em [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) hoje, e comece a ganhar recompensas de até **$100,000**!
<summary><strong>Aprenda hacking AWS do zero ao 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ê quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**merchandising oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-me no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
