**Dica de recompensa por bug**: **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**!
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.
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 Pendurada - 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 a 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?
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ê encontrar que o valor de um parâmetro ou até mesmo o caminho está sendo refletido na página da web, você pode explorar um **Reflected XSS**.
* **Armazenado e refletido**: Se você encontrar que um valor controlado por você é salvo no servidor e é refletido toda vez que você acessa uma página, você pode explorar um **Stored XSS**.
* **Acessado via JS**: Se você encontrar 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 sua entrada está sendo refletida**. Dependendo do contexto, você poderá executar código JS arbitrário de diferentes maneiras.
Se sua entrada é **refletida na página HTML bruta**, 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.\
Além disso, tenha em mente a [Injeção de Modelo do Lado do Cliente](../client-side-template-injection-csti.md).
1.**Escapar do atributo e da tag** (então você estará no HTML bruto) e criar uma nova tag HTML para abusar: `"><img [...]`
2. Se você **puder escapar do atributo, mas não da tag** (`>` é 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 em **se você controla todo o valor ou apenas uma parte**, você poderá abusar dele. Por **exemplo**, se você controla um evento como `onclick=`, 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 inexpugnáveis**", você pode tentar o truque **`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 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)}` ``
* **Codificação Unicode** funciona para escrever **código javascript válido**:
Portanto, se você tiver cenários em que pode **injetar código JS depois que um objeto não declarado** é 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 'Vulnerável') 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 **excluído** ou se ele é **refletido sem alterações**. **Somente nesse último caso você poderá explorar esse caso**.\
Para esses casos, também **tenha em mente** a [**Injeção de Modelo do Lado do Cliente**](../client-side-template-injection-csti.md)**.**\
Mas, se estiver sendo usado 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 descoberta 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 pequenos XSSs para diferentes ambientes** carga útil [**pode ser encontrada 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 um formulário** com dados preenchidos, 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 [**Dangling Markup**](../dangling-markup-html-scriptless-injection.md) porque você pode **explorar** a vulnerabilidade **sem** executar código **JS**.
Se você está **dentro de uma tag HTML**, a primeira coisa que você pode tentar é **escapar** da tag e usar algumas das técnicas mencionadas na [seção anterior](./#injecting-inside-raw-html) para executar código JS.\
Se você **não pode escapar da tag**, você pode criar novos atributos dentro da tag para tentar executar código JS, por exemplo, usando algum payload como (_observe que neste exemplo as aspas duplas são usadas para escapar do atributo, você não precisará delas se sua entrada for refletida diretamente dentro da tag_):
Os eventos de estilo são uma técnica de XSS que envolve a exploração de vulnerabilidades em sites que permitem a entrada de código CSS personalizado. Essa técnica é usada para injetar código malicioso em um site, que é executado quando um usuário visita a página comprometida. O código injetado pode ser usado para roubar informações do usuário, como cookies de autenticação, ou redirecionar o usuário para um site malicioso. É importante notar que essa técnica só funciona em sites que permitem a entrada de código CSS personalizado e que o código injetado é executado no navegador do usuário, não no servidor.
Mesmo que você **não possa escapar do atributo** (`"` está sendo codificado ou excluído), 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á 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)"`**
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, os filtros de entrada podem bloquear determinados caracteres, como `<` e `>`, para evitar ataques XSS. No entanto, é possível contornar esses filtros usando a codificação Unicode. Por exemplo, o caractere `<` pode ser representado como `\u003c`. Dessa forma, se o filtro estiver procurando por `<`, ele não encontrará, mas o navegador ainda interpretará o caractere como `<`. Isso pode ser usado para injetar código malicioso em eventos internos, como `onload` e `onclick`.
Em alguns lugares, você pode usar os protocolos **`javascript:`** ou **`data:`** 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 a **carga útil**, isso **não funcionará**, mas você pode **misturá-los dentro da carga útil**.
O ataque de *reverse tab nabbing* é uma técnica de phishing que explora a confiança do usuário em links que abrem em novas guias. O atacante cria um link malicioso que, quando clicado, abre uma nova guia com o site legítimo e, em seguida, redireciona a guia original para um site malicioso. Isso faz com que o usuário acredite que está navegando no site legítimo, enquanto na verdade está interagindo com o site malicioso. O atacante pode então roubar informações confidenciais, como credenciais de login ou informações de cartão de crédito.
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**:
Em primeiro lugar, 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 manipuladores de eventos **"on"** úteis.\
Caso haja alguma lista negra impedindo você de criar esses manipuladores de eventos, você pode tentar os seguintes bypasses:
De [aqui](https://portswigger.net/research/xss-in-hidden-input-fields):\
Você pode executar um **payload XSS dentro de um atributo oculto**, desde que 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 ter o link disparado.
Por exemplo, você pode adicionar algum 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)
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 = 'reflected data' [...] </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 somente 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**, porque 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 literais de modelo, 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**:
Este tipo de ataque XSS envolve a codificação de caracteres especiais em JavaScript usando a codificação Unicode. Isso pode ser usado para contornar filtros de entrada que não estão preparados para lidar com caracteres Unicode.
O atacante pode usar a codificação Unicode para injetar código JavaScript malicioso em uma página da web, que será executado no navegador do usuário. Isso pode permitir que o atacante roube informações confidenciais, como cookies de autenticação, ou execute ações maliciosas em nome do usuário.
Às vezes, os filtros de entrada de dados podem ser contornados usando espaços em branco. Por exemplo, se o filtro estiver procurando por `<script>` e você usar `<scr ipt>`, o filtro não detectará a tag. No entanto, se o filtro estiver procurando por `<script>` e você usar `<scr<script>ipt>`, o filtro detectará a tag. Portanto, é importante testar diferentes combinações de espaços em branco para contornar os filtros de entrada de dados.
Adicionar quebras de linha em JavaScript pode ser útil para ofuscar o código e torná-lo mais difícil de ler. Isso pode ser feito usando a sequência de escape `\n` para indicar uma nova linha. Por exemplo:
Isso exibirá uma caixa de diálogo com o texto "Hello" em uma linha e "world!" em outra linha. Em um ataque XSS, isso pode ser usado para ocultar o código malicioso em uma linha separada, tornando-o menos visível para a vítima.
JavaScript é uma linguagem de programação que é interpretada pelo navegador. O JavaScript é uma linguagem de script, o que significa que é executado linha por linha. O JavaScript é uma linguagem de espaço em branco insensível, o que significa que os espaços em branco não afetam a execução do código. No entanto, os espaços em branco podem ser usados para melhorar a legibilidade do código.
Às vezes, os desenvolvedores colocam comentários em seu código HTML para explicar o que está acontecendo. No entanto, se um comentário contiver código JavaScript, ele será executado pelo navegador. Isso pode ser usado para injetar código malicioso em uma página da web. Para explorar essa vulnerabilidade, você pode tentar inserir código JavaScript dentro de um comentário e ver se ele é executado pelo navegador.
O truque de JavaScript sem parênteses é uma técnica de XSS que envolve a execução de código JavaScript sem o uso de parênteses. Isso é possível porque o JavaScript permite que os parênteses sejam omitidos em torno dos argumentos de uma função. Em vez disso, os argumentos podem ser separados por vírgulas. Essa técnica pode ser usada para injetar código malicioso em um site e executá-lo no navegador do usuário.
// Backtips pass the string as an array of lenght 1
alert`1`
// Backtips + Tagged Templates + call/apply
eval`alert\x281\x29` // This won't work as it will just return the passed array
setTimeout`alert\x281\x29`
eval.call`${'alert\x281\x29'}`
eval.apply`${[`alert\x281\x29`]}`
[].sort.call`${alert}1337`
[].map.call`${eval}\\u{61}lert\x281337\x29`
// To pass several arguments you can use
function btt(){
console.log(arguments);
}
btt`${'arg1'}${'arg2'}${'arg3'}`
//It's possible to construct a function and call it
Function`x${'alert(1337)'}x```
// .replace can use regexes and call a function if something is found
"a,".replace`a${alert}` //Initial ["a"] is passed to str as "a," and thats why the initial string is "a,"
"a".replace.call`1${/./}${alert}`
// This happened in the previous example
// Change "this" value of call to "1,"
// match anything with regex /./
// call alert with "1"
"a".replace.call`1337${/..../}${alert}` //alert with 1337 instead
// Using Reflect.apply to call any function with any argumnets
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.
// Using Reflect.set to call set any value to a variable
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.
// valueOf, toString
// These operations are called when the object is used as a primitive
// Because the objet is passed as "this" and alert() needs "window" to be the value of "this", "window" methods are used
// 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 pode abusar disso para executar código JS arbitrário.\
**Devido à extensão da explicação das** [**vulnerabilidades DOM, ela foi movida para esta página**](dom-xss.md)**:**
Lá você encontrará uma **explicação detalhada do que são as vulnerabilidades DOM, como elas são provocadas e como explorá-las**.\
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.\
Por exemplo, ([neste relatório](https://hackerone.com/reports/709336)), se você enviar o payload:
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, portanto, apenas uma carga útil de script entre sites é 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 a carga útil 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:
> Refused to execute script from ‘[https://uploader.c.hc.lc/uploads/xxx'](https://uploader.c.hc.lc/uploads/xxx') because its MIME type (‘application/octet-stream’) is not executable, and strict MIME type checking is enabled.
Os únicos **tipos de conteúdo** que suportarão o Chrome 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`**.
Este comportamento foi utilizado neste [**writeup**](https://github.com/zwade/yaca/tree/master/solution) para remapear uma biblioteca para eval e abusá-la para desencadear XSS.
* \*\*\*\*[**speculationrules**](https://github.com/WICG/nav-speculation)**:** Este recurso é principalmente para resolver alguns problemas causados pela pré-renderização. Funciona assim:
(Daqui [**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}}", <entrada_do_usuário>)`** é 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.
* 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 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.
Este script é um scanner de portas simples que usa a biblioteca `fetch` do JavaScript para enviar solicitações HTTP para cada porta em uma lista de portas. Se a solicitação for bem-sucedida (ou seja, o servidor estiver ouvindo na porta), a porta é considerada aberta. Caso contrário, a porta é considerada fechada. Este script é útil para identificar portas abertas em um servidor e pode ser usado como parte de um teste de penetração.
O scanner de portas é uma ferramenta essencial para qualquer testador de penetração. Ele permite que você descubra quais portas estão abertas em um determinado host, o que pode ajudá-lo a identificar possíveis vulnerabilidades. O scanner de portas baseado em websockets é uma variação do scanner de portas tradicional que usa a tecnologia de websockets para se comunicar com o servidor. Isso permite que o scanner de portas seja executado em um navegador da web, sem a necessidade de instalar nenhum software adicional.
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.
PostMessage é uma API do navegador que permite a comunicação entre janelas/frames de diferentes origens. Isso é muito útil para aplicativos da web que precisam se comunicar com outras partes do aplicativo em diferentes janelas/frames. No entanto, essa funcionalidade também pode ser explorada por um atacante para roubar mensagens PostMessage.
O ataque funciona da seguinte maneira: o atacante injeta um script malicioso em uma página da web que envia mensagens PostMessage para outra janela/frame. O script malicioso intercepta essas mensagens e as envia para um servidor controlado pelo atacante. Dessa forma, o atacante pode roubar informações confidenciais que são transmitidas por meio de mensagens PostMessage.
Para se proteger contra esse tipo de ataque, é importante validar todas as mensagens PostMessage recebidas e garantir que elas sejam originárias de uma fonte confiável. Além disso, é importante evitar o uso de mensagens PostMessage para transmitir informações confidenciais.
<!-- 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 em atributos JS em diferentes objetos. Por exemplo, é possível encontrar a entrada de uma REGEX mesmo depois que o valor da entrada da REGEX foi 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**.\
Assim, se o **bot criador de PDF encontrar** algum tipo de **tags HTML**, ele vai **interpretá-las**, e você pode **abusar** desse comportamento para causar um **XSS no servidor**.
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 permite facilmente 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 até elementos de formulário responsivos, até a recuperação de conteúdo fresco de pontos finais 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 bug bounty**: **inscreva-se** na **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**!
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**The PEASS Family**](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** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
