4. Server Side Parameter Pollution(SSPP)

Server-Side Parameter Pollution(SSPP)¶

Manche Systeme haben interne API's die nicht öffentlich erreichbar sind - Problem: Eine Webseite nimmt User Input, aber verarbeitet diesen intern und im Zweifel kann ein Angreifer eigene Parameter einschleusen (Parameter Pollution)

Mögliche Auswirkungen¶

Vorhandene Parameter überschreiben.
Verhalten der Anwendung manipulieren.
Unberechtigten Zugriff auf Daten erhalten.

Wo kann das passieren?¶

Alles, was User Input enthält, könnte anfällig sein: - Query-Parameter (?id=123&role=user) - Form-Felder - HTTP-Header - URL-Pfade

Query strings¶

Nehmen wir an, die Anwendung baut serverseitig einen API-Request:

/internal-api/getUser?id=123

Der User darf eigentlich nur die id beeinflussen.
Aber der Angreifer gibt als Input ein:

123&isAdmin=true

Der Server baut dann:

/internal-api/getUser?id=123&isAdmin=true

Der Server leitet das intern dann weiter an die API

Query Strings abschneiden(Truncating) `#`¶

Man kann serverseitige Anfragen abschneiden indem man ein URL-kodiertes # einfügt. Also :%23

Beispiel: GET /userSearch?name=peter%23foo&back=/home

Daraus wird intern:

GET /users/search?name=peter#foo&publicProfile=true

Ungültige Parameter einschleusen `&`¶

Mit & URL-kodiert %26 kannn man neue Parameter injizieren

GET /userSearch?name=peter%26foo=xyz&back=/home

GET /users/search?name=peter&foo=xyz&publicProfile=true

### Vorhandene Parameter überschreiben `&`¶

Um sicher zu bestätigen, dass die Anwendung anfällig ist, versuche einen bereits vorhandenen Parameter zu überschreiben, indem du denselben Namen zweimal sendest.

Beispiel:

GET /userSearch?name=peter%26name=carlos&back=/home

Intern:

GET /users/search?name=peter&name=carlos&publicProfile=true

Wie das interpretiert wird, hängt von der Technologie ab:

PHP → letzter Parameter zählt → Suche nach carlos.
ASP.NET → kombiniert beide → Suche nach peter,carlos → evtl. Fehler Invalid username.
Node.js / Express → erster Parameter zählt → Suche nach peter.

Lab: Exploiting server-side parameter pollution in a query string¶

!!! Nachträglich !!!

Testing for server-side parameter pollution in REST paths¶

Parameter in der URL-Pfad-Struktur¶

Bei einer RESTful API können Parameter nicht nur im Query String, sondern auch direkt im URL-Pfad stehen.

Beispiel: /api/users/123 - /api → Root-Endpoint - /users → Ressource - /123 → Parameter (z. B. User-ID)

Beispiel-Szenario¶

Die Anwendung erlaubt das Bearbeiten von Profilen über: GET /edit_profile.php?name=peter

Intern macht der Server daraus: GET /api/private/users/peter

Angriffsmöglichkeit¶

Ein Angreifer könnte den Parameter so manipulieren, dass er Pfad-Traversal-Sequenzen einschleust.

Beispiel: GET /edit_profile.php?name=peter%2f..%2fadmin

Das führt intern zu: GET /api/private/users/peter/../admin

Wenn die API oder der Server diesen Pfad normalisiert, wird daraus: /api/private/users/admin

Testing for Server-side Parameter Pollution in Structured Data Formats¶

Ein Angreifer kann versuchen, Parameter in strukturierten Datenformaten wie JSON oder XML einzuschleusen.
Ziel: Schwachstellen in der Verarbeitung auf der Serverseite ausnutzen. Kurz gesagt: Wenn User-Input ungefiltert in JSON/XML übernommen wird, dann kann der Angreifer zusätzliche Parameter einschleusen insofern diese vom Server verarbeitet werden können

Beispiel 1 – Formulardaten → JSON auf Serverseite¶

Client-Request: POST /myaccount name=peter

Server-Request: PATCH /users/7312/update {"name":"peter"}

Angreifer manipuliert die Eingabe: POST /myaccount name=peter","access_level":"administrator

Server übernimmt das ungefiltert → daraus wird: {"name":"peter","access_level":"administrator"}

Der User peter könnte fälschlicherweise Adminrechte bekommen.

Beispiel 2 – JSON-Input vom Client¶

Client-Request: POST /myaccount {"name":"peter"}