Parameter Pollution | JSON Injection

Reading time: 9 minutes

Parameter Pollution

HTTP Parameter Pollution (HPP) Oorsig

HTTP Parameter Pollution (HPP) is 'n tegniek waar aanvallers HTTP parameters manipuleer om die gedrag van 'n webtoepassing op onvoorsiene maniere te verander. Hierdie manipulering word gedoen deur HTTP parameters by te voeg, te wysig of te dupliceer. Die effek van hierdie manipulering is nie direk sigbaar vir die gebruiker nie, maar kan die funksionaliteit van die toepassing aan die bedienerkant aansienlik verander, met waarneembare impakte aan die kliëntkant.

Voorbeeld van HTTP Parameter Pollution (HPP)

'n Banktoepassing transaksie URL:

• Oorspronklike URL: https://www.victim.com/send/?from=accountA&to=accountB&amount=10000

Deur 'n addisionele from parameter in te voeg:

• Gemanipeerde URL: https://www.victim.com/send/?from=accountA&to=accountB&amount=10000&from=accountC

Die transaksie mag verkeerdelik aan accountC in plaas van accountA gehef word, wat die potensiaal van HPP om transaksies of ander funksies soos wagwoordherstel, 2FA instellings, of API sleutel versoeke te manipuleer, toon.

Tegnologie-Spesifieke Parameter Parsing

• Die manier waarop parameters geparseer en geprioritiseer word, hang af van die onderliggende webtegnologie, wat beïnvloed hoe HPP uitgebuit kan word.
• Gereedskap soos Wappalyzer help om hierdie tegnologieë en hul parsing gedrag te identifiseer.

PHP en HPP Exploitatie

OTP Manipulasie Geval:

• Konteks: 'n Inlogmeganisme wat 'n Eenmalige Wagwoord (OTP) vereis, is uitgebuit.
• Metode: Deur die OTP versoek te onderskep met behulp van gereedskap soos Burp Suite, het aanvallers die email parameter in die HTTP versoek gedupliceer.
• Uitkoms: Die OTP, bedoel vir die aanvanklike e-pos, is in plaas daarvan na die tweede e-posadres in die gemanipeerde versoek gestuur. Hierdie fout het ongeoorloofde toegang moontlik gemaak deur die beoogde sekuriteitsmaatreël te omseil.

Hierdie scenario beklemtoon 'n kritieke oorsig in die toepassing se agterkant, wat die eerste email parameter vir OTP generasie verwerk het, maar die laaste vir aflewering gebruik het.

API Sleutel Manipulasie Geval:

• Scenario: 'n Toepassing laat gebruikers toe om hul API sleutel deur 'n profielinstellingsbladsy op te dateer.
• Aanval Vektor: 'n Aanvaller ontdek dat deur 'n addisionele api_key parameter aan die POST versoek toe te voeg, hulle die uitkoms van die API sleutel opdateringsfunksie kan manipuleer.
• Tegniek: Deur 'n gereedskap soos Burp Suite te gebruik, skep die aanvaller 'n versoek wat twee api_key parameters insluit: een wettig en een kwaadwillig. Die bediener, wat slegs die laaste voorkoms verwerk, werk die API sleutel na die aanvaller se verskafde waarde op.
• Resultaat: Die aanvaller verkry beheer oor die slagoffer se API funksionaliteit, wat moontlik toegang tot of wysiging van private data ongeoorloofde kan maak.

Hierdie voorbeeld beklemtoon verder die noodsaaklikheid van veilige parameter hantering, veral in funksies so krities soos API sleutel bestuur.

Parameter Parsing: Flask vs. PHP

Die manier waarop webtegnologieë duplikaat HTTP parameters hanteer, verskil, wat hul vatbaarheid vir HPP aanvalle beïnvloed:

• Flask: Neem die eerste parameter waarde wat teëgekom word, soos a=1 in 'n query string a=1&a=2, en prioritiseer die aanvanklike voorkoms bo daaropvolgende duplikate.
• PHP (op Apache HTTP Server): Teenwoordig prioritiseer die laaste parameter waarde, wat kies vir a=2 in die gegewe voorbeeld. Hierdie gedrag kan onbedoeld HPP exploits fasiliteer deur die aanvaller se gemanipeerde parameter bo die oorspronklike te eerbiedig.

Parameter besoedeling deur tegnologie

Daar resultate is geneem van https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89

PHP 8.3.11 EN Apache 2.4.62

1. Ignoreer enigiets na %00 in die parameter naam.
2. Hanteer naam[] as 'n array.
3. _GET beteken nie GET Metode nie.
4. Gee voorkeur aan die laaste parameter.

Ruby 3.3.5 en WEBrick 1.8.2

1. Gebruik die & en ; afdelers om parameters te skei.
2. Nie Erken naam[] nie.
3. Gee voorkeur aan die eerste parameter.

Spring MVC 6.0.23 EN Apache Tomcat 10.1.30

1. POST RequestMapping == PostMapping & GET RequestMapping == GetMapping.
2. POST RequestMapping & PostMapping Erken naam[].
3. Gee voorkeur aan naam as naam EN naam[] bestaan.
4. Koppel parameters byvoorbeeld eerste, laaste.
5. POST RequestMapping & PostMapping Erken query parameter met Content-Type.

NodeJS 20.17.0 EN Express 4.21.0

1. Erken naam[].
2. Koppel parameters byvoorbeeld eerste, laaste.

GO 1.22.7

1. NIE Erken naam[].
2. Gee voorkeur aan die eerste parameter.

Python 3.12.6 EN Werkzeug 3.0.4 EN Flask 3.0.3

1. NIE Erken naam[].
2. Gee voorkeur aan die eerste parameter.

Python 3.12.6 EN Django 4.2.15

1. NIE Erken naam[].
2. Gee voorkeur aan die laaste parameter.

Python 3.12.6 EN Tornado 6.4.1

1. NIE Erken naam[].
2. Gee voorkeur aan die laaste parameter.

JSON Injection

Duplikaat sleutels

obj = {"test": "user", "test": "admin"}

Die front-end mag die eerste voorkoms glo terwyl die backend die tweede voorkoms van die sleutel gebruik.

Sleutelbotsing: Karakterafsnijding en Kommentaar

Sekere karakters gaan nie korrek deur die frontend geïnterpreteer word nie, maar die backend sal hulle interpreteer en daardie sleutels gebruik, dit kan nuttig wees om sekere beperkings te omseil:

{"test": 1, "test\[raw \x0d byte]": 2}
{"test": 1, "test\ud800": 2}
{"test": 1, "test"": 2}
{"test": 1, "te\st": 2}

Let op hoe die voorkant in hierdie gevalle mag dink dat test == 1 en die agterkant sal dink dat test == 2.

Dit kan ook gebruik word om waardebeperkings te omseil soos:

{"role": "administrator\[raw \x0d byte]"}
{"role":"administrator\ud800"}
{"role": "administrator""}
{"role": "admini\strator"}

Gebruik van Kommentaar Afkorting

obj = {"description": "Duplicate with comments", "test": 2, "extra": /*, "test": 1, "extra2": */}

Hier sal ons die serialiseerder van elke parser gebruik om sy onderskeie uitvoer te sien.

Serialiseerder 1 (bv. GoLang se GoJay biblioteek) sal produseer:

• description = "Duplicate with comments"
• test = 2
• extra = ""

Serialiseerder 2 (bv. Java se JSON-iterator biblioteek) sal produseer:

• description = "Duplicate with comments"
• extra = "/*"
• extra2 = "*/"
• test = 1

Alternatiewelik kan eenvoudige gebruik van kommentaar ook effektief wees:

obj = {"description": "Comment support", "test": 1, "extra": "a"/*, "test": 2, "extra2": "b"*/}

Java se GSON biblioteek:

{ "description": "Comment support", "test": 1, "extra": "a" }

Ruby se simdjson biblioteek:

{ "description": "Comment support", "test": 2, "extra": "a", "extra2": "b" }

Inkonsekwente Prioriteit: Deserialisering vs. Serialisering

obj = {"test": 1, "test": 2}

obj["test"] // 1
obj.toString() // {"test": 2}

Float en Heelgetal

Die nommer

999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

kan na verskeie voorstellings gedecodeer word, insluitend:

999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9.999999999999999e95
1E+96
0
9223372036854775807

Wat dalk inkonsekwentheid kan skep

Verwysings

• https://medium.com/@shahjerry33/http-parameter-pollution-its-contaminated-85edc0805654
• https://github.com/google/google-ctf/tree/master/2023/web-under-construction/solution
• https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89
• https://bishopfox.com/blog/json-interoperability-vulnerabilities