Response Parameter Injection er en ukendt, men ikke ufarlig sårbarhed

Skrevet d. 06-05-2025 af Philip Meier Kreutzer

I dette blogindlæg kaster vores Security Advisor, Philip Meier Kreutzer, lys over en ofte overset, men potentielt alvorlig sårbarhed: Response Parameter Injection. Det er en angrebsmetode, som de færreste har hørt om, men som kan få alvorlige konsekvenser, hvis den ikke bliver opdaget i tide. Philip gennemgår, hvordan denne sårbarhed opstår, og hvordan du som udvikler eller sikkerhedsansvarlig kan identificere og beskytte dine systemer mod den. >

Hvorfor hedder det Response Parameter Injection?

Jeg læste om denne type sårbarhed i et blogindlæg for nogle år siden. Jeg kan ikke finde den oprindelige kilde, der fik mig til at få øjnene op for sårbarheden, og derfor kan jeg ikke henvise til den. I stedet vil jeg beskrive teknikken og sårbarheden ud fra mine egne opdagelser og erfaringer med den.

Navnet på sårbarheden er forskelligt, afhængig af hvor jeg læser om den. I det første blogindlæg jeg læste, blev det kaldt “Response in Request injection”. Et andet sted så jeg betegnelsen “Structured Format Injection”. Og i diskussioner på PortSwigger’s Discord har flere omtalt det som “Response Parameter Injection” – og det er det navn, jeg synes giver bedst mening. Derfor har jeg også kaldt denne artikel netop dette.

Hvad handler sårbarheden om?

Det er ikke en “klassisk” injection, som vi kender det fra fx SQL eller command injection. Men princippet er lidt det samme: Du sender noget ekstra input til et endpoint, som applikationen ikke havde forventet, og det påvirker applikationens adfærd.

Men i stedet for at indsætte en skadelig kode tilføjer man flere parametre til et request. Og det kan ændre den måde, applikationen fungerer på – uden at det nødvendigvis opdages af brugeren. Derfor taler vi mere om misbrug af applikationslogik end om egentlig kodeinjektion. Det kan kun lade sig gøre, fordi endpointet ikke er sat op til at kontrollere, hvilke input der må sendes.

Hvor opstår sårbarheden?

Sårbarheden Response Parameter Injection opstår oftest i API-kald, hvor der typisk bruges struktureret data (som JSON) – og hvor request og response kan ligne hinanden meget.

I takt med at flere webapplikationer bruger frameworks som React og Angular, og at API’er bliver mere udbredte, bliver denne type angreb mere og mere relevant. Desværre bliver den sjældent omtalt – selvom den i praksis bliver stadig mere almindelig.

Et konkret eksempel

Lad os tage et simpelt eksempel, hvor en bruger kan ændre oplysninger på sin profil via et JSON-request.

Brugergrænsefladen giver adgang til at ændre fornavn, efternavn og telefonnummer. Et typisk request ser sådan her ud:

Post Request

{
  "FirstName": "Philip",
  "LastName": "Kreutzer",
  "PhoneNumber": "+4561102038"
}

Når serveren svarer, får vi ikke bare bekræftet de data, vi selv har sendt. Vi får også ekstra information med i responsen – fx brugerens ID og rolle:

Post response

{
  "FirstName": "Philip",
  "LastName": "Kreutzer",
  "PhoneNumber": "+4561102038",
  "UserId": "666",
  "Role": "user"
}

Så her begynder det at blive interessant. Hvis man nu kan indsætte de ekstra felter (som fx “Role”) i sit request, og hvis serveren accepterer det – så har man fundet en sårbarhed.

Post Request - Injection

{
  "FirstName":"Philip", 
  "LastName":"Kreutzer", 
  "PhoneNumber":"+4561102038", 
  "UserId":"666", 
  "Role":"admin"     
}

Hvis applikationen ikke tjekker, hvilke felter den får lov til at modtage og behandle, så er det faktisk muligt at ændre sin rolle til “admin”. Og det er her, det bliver farligt, da den cyberkriminelle får adgang til siden og kan agere som administrator, som giver adgang til fortrolige oplysninger.

Hvordan opdager man sårbarheden?

Hvis du arbejder med penetrationstests, anbefaler jeg altid at starte med at lære applikationen at kende. Hvad kan den? Hvordan kommunikerer den? Hvad sender den frem og tilbage? Det gælder ikke kun for denne sårbarhed. Det er altid en fordel at forstå applikationen, før du forsøger at finde fejl i den.

Der findes også værktøjer, der kan hjælpe. Hvis du bruger Burp Suite Professional, kan du tage param-miner-udvidelsen i brug. Den scanner ikke alt automatisk, men du kan selv aktivere den på specifikke endpoints, som ser spændende ud – fx hvis du opdager et mønster i request-response, der kunne gemme på en sårbarhed, ligesom det eksempel jeg har vist.

Andre erfaringer med denne type sårbarhed

Mens jeg skrev denne artikel, faldt jeg over noget spændende research og et blogindlæg fra Dana Epp. Han har blandt andet skrevet en guide til at finde skjulte API-parametre – hvilket i praksis er en måde at udnytte netop denne type sårbarhed på.

Han har også skrevet om selve teknikken under navnet “Structured Format Injection”. Det bekræftede mig i, at denne sårbarhed er noget, der fortjener mere opmærksomhed. Derfor deler jeg min egen vinkel på det, så det forhåbentlig bliver nemmere for andre at finde information om sårbarheden og genkende problemet i praksis.

Vil du finde sårbarhederne i din virksomhed?

Få testet din IT-sikkerhed af vores specialister. Læs mere om vores webapplikationstest eller webservice-sikkerhedstest og se, hvordan vi kan hjælpe dig med at sikre dine systemer.