HTTP Parameter Pollution (HPP) - Parameter-Verschmutzung

HTTP Parameter Pollution (HPP) entsteht durch eine Eigenheit des HTTP-Standards: Es gibt keine normative Spezifikation wie Webserver mit mehrfach vorkommenden Query- oder Body-Parametern gleichen Namens umgehen sollen. Verschiedene Technologien lösen das Problem unterschiedlich - und genau diese Inkonsistenz wird von Angreifern ausgenutzt.

Grundprinzip

Problem: Was passiert bei ?id=1&id=2 ?

PHP (Apache):        $_GET['id'] = "2"           → letzter Wert gewinnt
ASP.NET (IIS):       Request["id"] = "1,2"        → Komma-separierte Liste
JSP (Tomcat):        request.getParameter("id") = "1"  → erster Wert gewinnt
Node.js (qs):        req.query.id = ["1", "2"]    → Array
Flask (Python):      request.args.get("id") = "1" → erster Wert gewinnt
Flask (getlist):     request.args.getlist("id") = ["1", "2"] → explizit

Die Inkonsistenz IST das Problem - nicht ein Bug in einer Komponente!

Typische HPP-Angriffsflächen:
  □ Query-Parameter in GET-Requests: ?role=user&role=admin
  □ POST-Body-Parameter: username=victim&username=attacker
  □ HTTP-Header-Werte (seltener, aber möglich)
  □ JSON-Arrays in Request-Bodies (JSON HPP)
  □ SOAP-Envelopes mit duplizierten Elementen

HPP-Angriffsvektoren

Angriff 1 - WAF-Bypass:

  WAF prüft auf SQL-Injection in Parametern:
  /search?q=SELECT+*+FROM+users        → WAF blockiert!

  HPP-Bypass:
  /search?q=SELECT+*&q=FROM+users      → WAF prüft nur ersten Parameter
                                           Backend konkateniert → Bypass!

  Oder:
  /search?q=1' OR '1'='1              → WAF blockiert
  /search?q=1'&q=OR '1'='1           → WAF sieht keinen vollständigen Payload
                                           Backend kombiniert → SQLi möglich!

Angriff 2 - Signaturprüfungs-Bypass:

  Typisches sicheres API-Design (z.B. Zahlungs-API):
  POST /transfer
  Body: amount=100&to=alice&signature=HMAC(amount=100,to=alice)

  HPP-Angriff:
  POST /transfer
  Body: amount=100&to=alice&signature=VALID_HASH&to=attacker

  Problem: Signatur-Prüfung → nimmt ERSTEN "to"-Wert → alice (gültig!)
           Transfer-Logik  → nimmt LETZTEN "to"-Wert → attacker (Angriff!)
  → Gültiger Transfer zu falschem Empfänger!

Angriff 3 - Zugriffskontroll-Bypass:

  Applikation prüft Berechtigung:
  GET /api/order?user_id=123&status=pending

  HPP-Bypass:
  GET /api/order?user_id=123&user_id=456&status=pending

  Wenn Autorisierungs-Layer 123 prüft (erster Wert) aber
  Daten-Query mit 456 läuft (letzter Wert) → IDOR!
  → Fremde Bestellungen abrufbar!

Angriff 4 - Logik-Manipulation (Bestellprozess):

  Rabattcode anwenden:
  POST /checkout
  Body: item_id=EXPENSIVE&coupon=INVALID&coupon=VALID50

  Coupon-Validierung prüft ersten Wert → INVALID → kein Rabatt geloggt
  Preis-Kalkulation nutzt letzten Wert → VALID50 → 50% Rabatt!
  → Rabatt ohne validierten Coupon!

Angriff 5 - Server-Side HPP (SSHPP):

  Backend-Server aggregiert URLs für externe API-Calls:
  Nutzereingabe: &lang=en
  Vollständige URL: https://api.intern/data?id=1&lang=en

  Angreifer übergibt: &id=MALICIOUS&lang=en
  Vollständige URL: https://api.intern/data?id=1&id=MALICIOUS&lang=en
  → Interner Parameter überschrieben!

Erkennung im Pentest

HPP-Testing-Methodik:

1. Parameter-Identifikation:
   → Alle Parameter in GET, POST, Cookies, Headers auflisten
   → Tipp: Burp Suite "Param Miner" Extension

2. Duplikations-Tests:
   Für jeden Parameter:
   □ Original: ?param=ORIGINAL
   □ HPP-Test: ?param=ORIGINAL&param=INJECTED
   □ Reihenfolge umkehren: ?param=INJECTED&param=ORIGINAL
   □ Komma-Notation: ?param=ORIGINAL,INJECTED
   □ Array-Notation: ?param[]=ORIGINAL&param[]=INJECTED

3. Verhaltensanalyse:
   □ Antwortet die App anders mit duplizierten Parametern?
   □ Welcher Wert wird tatsächlich verarbeitet?
   □ Gibt es Unterschiede zwischen Validierungs- und Verarbeitungsschicht?

4. WAF-Bypass-Test:
   □ Bekannten WAF-Block erzeugen (einfache SQLi/XSS-Payload)
   □ Payload auf zwei Parameter aufteilen
   □ Verschiedene Kombinationen testen
   □ Auch Array-Syntax: ?q[]=SELECT&q[]=*

5. Automatisiert (Burp Active Scan):
   → Parameter-Duplikation wird von Burp Pro erkannt
   → "Passive Scans" zeigen oft HPP-Hinweise in Response-Differenzen
   → HPP Finder Extension im BApp Store

6. JSON HPP:
   {"user": "alice", "user": "attacker"}
   → Welche Implementierung nimmt welchen Wert?
   → JavaScript-Parser: letzter Wert (meist)
   → Gott-modus durch JSON-Duplikate prüfen

Schutzmaßnahmen

Prävention gegen HTTP Parameter Pollution:

1. Einheitliche Parameter-Extraktion:
   □ NUR eine Methode zur Parameter-Extraktion verwenden
   □ Explizit entscheiden: erster oder letzter Wert?
   □ NIEMALS auf implizites Framework-Verhalten vertrauen!

   Python (Flask) - sicher:
   value = request.args.get('param')          # erster Wert
   values = request.args.getlist('param')     # alle Werte
   # Wenn getlist mehr als 1 Element → 400 Bad Request!

   Node.js (Express) - sicher:
   const param = req.query.param;
   if (Array.isArray(param)) {
     return res.status(400).json({ error: 'Duplicate parameter' });
   }

2. Duplikat-Ablehnung:
   → Middleware die mehrfache Parameter blockiert
   → 400 Bad Request bei Parameterduplikaten

   Nginx (rudimentär):
   if ($args ~* "(.+)=(.*)&\1=") {
     return 400;
   }
   # Warnung: Regex-Performance prüfen!

3. Konsistenz zwischen Schichten:
   □ Sicherheitsprüfung (WAF/Auth) und Applikation MÜSSEN gleiche
     Parameter-Semantik verwenden
   □ Single Source of Truth für Parameter-Parsing
   □ Selbe Library/Methode für WAF-Bypass-Prüfung und Business-Logik

4. Eingabe-Whitelisting:
   □ Erwartete Parameter explizit definieren
   □ Unbekannte Parameter verwerfen (nicht ignorieren!)
   □ Parameteranzahl validieren: max. 1× pro bekanntem Namen

5. Signatur und Integritätsprüfung:
   □ HMAC über exakt serialisierte Parameter berechnen
   □ Kanonische Serialisierung: alphabetisch sortierte Key=Value-Paare
   □ Signaturprüfung und Verarbeitung MÜSSEN selbe Canonical-Form nutzen

6. WAF-Konfiguration:
   □ HPP-Erkennung im WAF aktivieren (ModSecurity: CRS HPP-Regeln)
   □ REQUEST_ARGS:duplikat-Regeln aktivieren
   □ Periodische Bypass-Tests gegen eigene WAF!

---

HPP ist eine der am häufigsten übersehenen Schwachstellenklassen - weil sie oft erst im Zusammenspiel mehrerer Komponenten entsteht. Besonders gefährlich sind SSHPP-Angriffe, bei denen ein Angreifer-kontrollierter Parameter interne API-Parameter überschreibt. AWARE7 überprüft HPP-Schwachstellen im Rahmen von Web Application Penetrationstests als Teil der Input-Validierungs-Tests.