API

Manchmal sind Dokumentationen zu API's auf bestimmten Seiten und können so leicht eingesehen werden:

/api
/swagger/index.html
/openapi.json

Die API Dokumentationen können auch geparst werden beispielsweise mit dem Addon OpenAPI Parser aus dem BApp Store. Es ist auch immer sinnvoll zu testen, welche Methoden erlaubt sind. Beispielsweise die drei Methoden: GET, POST und DELETE können mit dem selben link unterschiedliche Aktionen ausführen. Meistens erwarten API Endpunkte Daten in einem bestimmten Format, ein anderes kann zu unerwarteten Ergebnissen führen. Hierbei kann auch der Content type converter aus dem BApp Store helfen. Auch ist es möglich, bei Anfragen zusätzliche Attribute hinzuzufügen, wenn man weiß wie ein Objekt aufgebaut ist. Beispielsweise mit dem PATCH Request ist es möglich die Email eines Nutzers upzugraden. Dazu wird das folgende JSON Objekt gesendet:

{
    "username": "wiener",
    "email": "wiener@example.com"
}

Mit einer Abfrage über Details des Users erhält man:

{
    "id": 123,
    "name": "John Doe",
    "email": "john@example.com",
    "isAdmin": "false"
}

Wie hier zu sehen ist, hat das User Objekt noch zwei Weitere Attribute. Nun kann versucht werden eins dieser zusätzlichen Attribute im ersten Request zu nutzen um diese Werte zu verändern.

Server-side parameter pollution

Manchmal kontaktieren manche Webapplikationen Intern APIs. Dies passiert, ohne dass der Nutzer dies mitbekommt. Dies kann aber ausgenutzt werden. Um nach Server-side parameter pollution in einer URL zu suchen, können die Zeichen #, & und = benutzt werden. Um dieses Szenario zu verdeutlichen kann man sich den folgenden Request vorstellen, welcher Nutzer Informationen abfragt:

GET /userSearch?name=peter&back=/home

Die Webanwendung wiederum nimmt die erhaltenen Informationen und fragt eine Interne API ab:

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

Dies kann nun ausgenutzt werden indem die Parameter so angepasst werden, dass sie den internen Request beeinflussen können, wenn nicht eine gute Validierung stattgefunden hat. Beispielsweise kann das # Zeichen url enkodiert werden und hinter dem Namen eingefügt werden. Dadurch werden die folgenden Parameter nicht mehr als Parameter gesehen und es kann in diesem Fall auch auf nicht öffentliche Profile zugegriffen werden.

Überschreiben von existierenden Parametern

Das überschreiben ist auch möglich. Beispielsweise kann der folgende Request URL enkodiert geschickt werden um den Parameter Namen zu überschreiben.

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

Je nachdem, wie dies von dem unterliegenden Backend bearbeitet wird kann dies ausgenutzt werden: - PHP wertet nur den letzten Parameter aus. Was in einer Suche nach dem Nutzer Carlos endet. - ASP.NET kombiniert die beiden Parameter zu peter,carlos was wahrscheinlich zu einem invalid username führt. - Node.js / express wertet nur den ersten Parameter aus. Hier wird nur nach peter gesucht.

Server-side parameter pollution in REST

In Rest APIs kann es dass die Parameter in dem URL Pfad anstatt des Query Strings. Dabei wird dann die Webapp abgefragt mit der folgenden Anfrage:

GET /edit_profile.php?name=peter

Die Webapp macht nun eine Anfrage an einer REST API, welche in folgendem resultiert:

GET /api/private/users/peter

Ein Angreifer könnte nun diesen URL Pfad manipulieren, mit einer path traversal Attacke.

Server-side parameter pollution in struckturierten Datenformaten

Mit strukturierten Datenformaten sieht es schon anders aus. Hier muss das Format an das strukturierte Datenformat angepasst werden, zumeist XML oder JSON.

POST /myaccount
name=peter

Aus diesem POST Request wird dann bei der Anfrage an die interne API das folgende:

PATCH /users/7312/update
{"name": "peter"}

Um dies auszunutzen kann dann der folgende Request erstellt werden: ```http POST /myaccount name=peter","access_level":"administrator