HTTP Parameter Pollution (HPP) - Parameter-Verschmutzung

Kurzerklärung: HTTP Parameter Pollution tritt auf wenn mehrere gleichnamige Parameter in einer HTTP-Anfrage gesendet werden und Backend-Systeme diese unterschiedlich interpretieren. Angreifer können dadurch Validierungs-Logik umgehen, WAF-Regeln aushebeln und unerwartetes Verhalten auslöser. Betroffen: Parameterparsing in PHP (letzter Wert), ASP.NET (erster Wert), Node.js (Array) - die Inkonsistenz zwischen Komponenten wird ausgenutzt.

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 ?

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 diesen Request. HPP-Bypass:

/search?q=SELECT+*&q=FROM+users

Die WAF prüft nur den ersten Parameter, das Backend konkateniert beide - Bypass! Oder:

/search?q=1' OR '1'='1
/search?q=1'&q=OR '1'='1

Die WAF sieht keinen vollständigen Payload, das Backend kombiniert beides - 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

Die Signatur-Prüfung nimmt den ERSTEN to-Wert (alice, gültig), die Transfer-Logik nimmt den LETZTEN to-Wert (attacker, Angriff) - gültiger Transfer zu falschem Empfänger!

Angriff 3 - Zugriffskontroll-Bypass:

GET /api/order?user_id=123&status=pending
GET /api/order?user_id=123&user_id=456&status=pending

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

Angriff 4 - Logik-Manipulation (Bestellprozess):

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

Die Coupon-Validierung prüft den ersten Wert (INVALID, kein Rabatt geloggt), die Preis-Kalkulation nutzt den letzten Wert (VALID50, 50% Rabatt) - Rabatt ohne validierten Coupon!

Angriff 5 - Server-Side HPP (SSHPP):

Der Backend-Server aggregiert URLs für externe API-Calls. Der Angreifer übergibt &id=MALICIOUS&lang=en, woraus die vollständige URL wird:

https://api.intern/data?id=1&id=MALICIOUS&lang=en

Der interne Parameter wird überschrieben.

Erkennung im Pentest

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

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

Schutzmaßnahmen

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. 1x 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.