Unicode Injection
Inleiding
Afhankelijk van hoe de back-end/front-end zich gedraagt wanneer het vreemde unicode-karakters ontvangt, kan een aanvaller mogelijk beveiligingsmaatregelen omzeilen en willekeurige karakters injecteren die kunnen worden gebruikt om injectiekwetsbaarheden zoals XSS of SQLi te misbruiken.
Unicode-normalisatie
Unicode-normalisatie treedt op wanneer unicode-karakters worden genormaliseerd naar ASCII-karakters.
Een veelvoorkomend scenario van dit type kwetsbaarheid doet zich voor wanneer het systeem de invoer van de gebruiker aanpast nadat deze is gecontroleerd. Bijvoorbeeld, in sommige talen kan een eenvoudige oproep om de invoer in hoofdletters of kleine letters te zetten de gegeven invoer normaliseren en de unicode zal worden omgezet in ASCII, waardoor nieuwe karakters worden gegenereerd. Voor meer informatie, zie:
pageUnicode Normalization\u
naar %
\u
naar %
Unicode-karakters worden meestal weergegeven met het voorvoegsel \u
. Bijvoorbeeld het karakter 㱋
is \u3c4b
(controleer het hier). Als een back-end de prefix \u
transformeert in %
, zal de resulterende string %3c4b
zijn, wat URL-gecodeerd is als: <4b
. En, zoals je kunt zien, wordt er een <
-teken geïnjecteerd.
Je kunt deze techniek gebruiken om elk soort teken in te voegen als de back-end kwetsbaar is.
Bekijk https://unicode-explorer.com/ om de karakters te vinden die je nodig hebt.
Deze kwetsbaarheid komt eigenlijk voort uit een kwetsbaarheid die een onderzoeker heeft gevonden, voor een meer gedetailleerde uitleg zie https://www.youtube.com/watch?v=aUsAHb0E7Cg
Emoji-injectie
Back-ends gedragen zich soms vreemd wanneer ze emoji's ontvangen. Dat is wat er gebeurde in deze write-up waar de onderzoeker erin slaagde om een XSS te bereiken met een payload zoals: 💋img src=x onerror=alert(document.domain)//💛
In dit geval was de fout dat de server na het verwijderen van de schadelijke karakters de UTF-8-string van Windows-1252 naar UTF-8 converteerde (in feite kwam de invoerencodering niet overeen met de conversie-encodering). Hierdoor wordt er geen juist <-teken gegeven, maar een vreemd unicode-teken: ‹
``Dus ze namen deze uitvoer en converteerden deze opnieuw van UTF-8 naar ASCII. Dit normaliseerde de ‹
naar <
, zo kon de exploit werken op dat systeem.
Dit is wat er gebeurde:
Emoji-lys:
Last updated