Unicode Injection

Reading time: 5 minutes

Introduction

Afhangend van hoe die back-end/front-end optree wanneer dit weird unicode karakters ontvang, mag 'n aanvaller in staat wees om beskermings te omseil en arbitrêre karakters in te voeg wat gebruik kan word om invoegingskwesbaarhede te misbruik soos XSS of SQLi.

Unicode Normalization

Unicode normalisering vind plaas wanneer unicode karakters genormaliseer word na ascii karakters.

Een algemene scenario van hierdie tipe kwesbaarheid gebeur wanneer die stelsel die invoer van die gebruiker op 'n of ander manier aanpas nadat dit nagegaan is. Byvoorbeeld, in sommige tale kan 'n eenvoudige oproep om die invoer hoofletters of kleinletters te maak die gegewe invoer normaliseer en die unicode sal in ASCII omskep word, wat nuwe karakters genereer.
Vir meer inligting, kyk:

Unicode Normalization

\u na %

Unicode karakters word gewoonlik verteenwoordig met die \u voorvoegsel. Byvoorbeeld, die karakter 㱋 is \u3c4b(kyk dit hier). As 'n backend die voorvoegsel \u in % omskep, sal die resulterende string %3c4b wees, wat URL gedekodeer is: <4b. En, soos jy kan sien, is 'n < karakter ingesluit.
Jy kan hierdie tegniek gebruik om enige tipe karakter in te voeg as die backend kwesbaar is.
Kyk https://unicode-explorer.com/ om die karakters te vind wat jy nodig het.

Hierdie kwesbaarheid kom eintlik van 'n kwesbaarheid wat 'n navorser gevind het, vir 'n meer diepgaande verduideliking, kyk https://www.youtube.com/watch?v=aUsAHb0E7Cg

Emoji Injection

Back-ends gedra soms vreemd wanneer hulle emojis ontvang. Dit is wat gebeur het in hierdie skrywe waar die navorser daarin geslaag het om 'n XSS te bereik met 'n payload soos: 💋img src=x onerror=alert(document.domain)//💛

In hierdie geval was die fout dat die bediener, nadat dit die kwaadwillige karakters verwyder het, die UTF-8 string van Windows-1252 na UTF-8 omskep het (basies het die invoer kodering en die omskakeling van kodering nie ooreengestem nie). Dit gee dan nie 'n behoorlike < nie, net 'n vreemde unicode een: ‹
``So het hulle hierdie uitvoer geneem en weer van UTF-8 na ASCII omgeskakel. Dit het die ‹ na < genormaliseer, dit is hoe die ontploffing op daardie stelsel kon werk.
Dit is wat gebeur het:

<?php

$str = isset($_GET["str"]) ? htmlspecialchars($_GET["str"]) : "";

$str = iconv("Windows-1252", "UTF-8", $str);
$str = iconv("UTF-8", "ASCII//TRANSLIT", $str);

echo "String: " . $str;

Emoji lyste:

• https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv
• https://unicode.org/emoji/charts-14.0/full-emoji-list.html

Windows Beste-Pas / Sleg-Pas

Soos verduidelik in hierdie wonderlike pos, het Windows 'n kenmerk genaamd Beste-Pas wat unicode karakters wat nie in ASCII-modus vertoon kan word nie, met 'n soortgelyke een sal vervang. Dit kan lei tot onverwagte gedrag wanneer die agterkant 'n spesifieke karakter verwag, maar 'n ander een ontvang.

Dit is moontlik om beste-pas karakters te vind in https://worst.fit/mapping/.

Aangesien Windows gewoonlik unicode strings na ascii strings sal omskakel as een van die laaste dele van die uitvoering (gewoonlik van 'n "W" agtervoegsel API na 'n "A" agtervoegsel API soos GetEnvironmentVariableA en GetEnvironmentVariableW), sal dit aanvallers in staat stel om beskermings te omseil deur unicode karakters te stuur wat laastens in ASCII karakters omgeskakel sal word wat onverwagte aksies sal uitvoer.

In die blogpos word voorgestelde metodes aangebied om kwesbaarhede te omseil wat reggestel is met 'n swartlys van karakters, om pad traversals te benut met karakters wat na “/“ (0x2F) gekarteer is en karakters wat na “\“ (0x5C) gekarteer is of selfs om shell escape beskermings soos PHP se escapeshellarg of Python se subprocess.run te omseil met 'n lys, dit is byvoorbeeld gedoen met volledige breedte dubbele aanhalings (U+FF02) in plaas van dubbele aanhalings, sodat wat aan die einde soos 1 argument gelyk het, in 2 argumente omgeskakel is.

Let daarop dat vir 'n app kwesbaar te wees, dit "W" Windows APIs moet gebruik, maar uiteindelik 'n "A" Windows API moet aanroep sodat die "Beste-pas" van die unicode string geskep word.

Verskeie ontdekte kwesbaarhede sal nie reggestel word nie, aangesien mense nie saamstem wie hierdie probleem moet regstel nie.