Kilka dni temu dostałem kawałek kodu napisanego w PHP 5 oraz pytanie "czy to jest OK?". Kod zajmował się walidacją pól formularza (tj. tzw user input), a konkretniej, sprawdzał czy user input składa się tylko z liter, łacińskich (A-Z) oraz polskich liter diakrytyzowanych (czyli Ą Ż Ś Ź Ę Ć Ń Ó Ł oraz małych wersji tychże liter: ą ż ś ź ę ć ń ó ł). Dodatkowo, weryfikacji podlegała ilość wprowadzonych liter - limit był stosunkowo niewielki. Jak zapewne się już domyśliliście, kod był "nie OK", a błąd był na tyle ciekawy, iż zdecydowałem się go opisać.

Istotne informacje zanim zaczniemy: Kod miał docelowo działać pod PHP 5, a zarówno strona jak i sam plik z źródłem były kodowane w UTF-8.

Samo sprawdzanie wyglądało tak (w wersji uproszczonej, tj. zmieniłem limit znaków do 5, oraz ograniczyłem regexp tak aby oczekiwał dokładnie jednego słowa):
preg_match('/^[a-zA-Zążśźęćń󳥯ŚŹĘĆŃÓŁ]{1,5}$/', $input_text)
Moim zdaniem intencja autora kodu jest jasna:
- tylko polskie i łacińskie litery są dozwolone,
- minimalna ilość oczekiwanych liter to 1, a maksymalna dopuszczona to 5

Na pierwszy rzut oka wszystko wygląda OK, ale niestety... preg_match nie działa domyślnie w trybie UTF-8, więc nie wie, że niektóre z podanych liter mogą zajmować więcej niż jeden bajt.
Rzućmy okiem jak różne polskie litery diakrytyczne są kodowane w UTF-8:
ą: C4 85    ż: C5 BC    ś: C5 9B    ź: C5 BA
ę: C4 99    ć: C4 87    ń: C5 84    ó: C3 B3
ł: C5 82    Ą: C4 84    Ż: C5 BB    Ś: C5 9A
Ź: C5 B9    Ę: C4 98    Ć: C4 86    Ń: C5 83
Ó: C3 93    Ł: C5 81
Taak, każda z nich zajmuje dokładnie dwa bajty. A jak pisałem, preg_match o tym nie wie, więc oczywistą konsekwencją tego jest fakt, że regexp /[Ł]/ zostanie potraktowany jako /[\xC5\x81]/, czyli zarówno bajt (znak) \xC5 jak i \x81 są zgodne z niniejszym regexpem, nawet jeśli nie są podane razem!

Podsumujmy co nie zadziała zgodnie z myślą autora kodu:
1. Skoro możemy (oprócz liter łacińskich) korzystać ze znaków: 81 82 83 84 85 86 87 93 98 99 9A 9B B3 B9 BA BB BC C4 C5 (posortowane względem wartości), to każda dowolna kombinacja tychże bajtów przejdzie przez filtry (z dokładnością do długości kombinacji oczywiście).
Czyli, możemy albo podać jako input sekwencje bajtów które nie stanowią prawidłowych znaków UTF-8, np. można zacząć od 80-BF, czyli przedziału zarezerwowanego na drugi, trzeci lub czwarty bajt poprawnej sekwencji UTF-8 (a nie pierwszy), albo złożyć sekwencje składającą się tylko z bajtów C4 lub C5, które są zarezerwowane jako bajty rozpoczynające sekwencje. Może nam się poszczęści i dostaniemy nawet jakiś warning/error bazy danych (a tym samym trochę info/path disclosure)? Kto wie :)
Lub... możemy też jako input podać prawidłowe znaki UTF-8, rozpoczynające się od C4 lub C5, w których drugim i ostatnim bajtem będzie jakiś inny bajt z wyżej wymienionej listy (poza C4 i C5 ofc). Stosując różne poprawne kombinacje dozwolonych wartości, możemy otrzymać jeden z poniższy znaków:
grupa C4:
ā: C4 81    Ă: C4 82    ă: C4 83    Ą: C4 84
ą: C4 85    Ć: C4 86    ć: C4 87    ē: C4 93
Ę: C4 98    ę: C4 99    Ě: C4 9A    ě: C4 9B
ij: C4 B3    Ĺ: C4 B9    ĺ: C4 BA    Ļ: C4 BB
ļ: C4 BC
grupa C5:
Ł: C5 81    ł: C5 82    Ń: C5 83    ń: C5 84
Ņ: C5 85    ņ: C5 86    Ň: C5 87    œ: C5 93
Ř: C5 98    ř: C5 99    Ś: C5 9A    ś: C5 9B
ų: C5 B3    Ź: C5 B9    ź: C5 BA    Ż: C5 BB
ż: C5 BC
2. Drugą rzeczą która nie pójdzie po myśli autora, jest limit ilości znaków. Autor chciał, aby górny limit wynosił 5 liter, niestety, wynosi on 5 bajtów. Czyli np. 5-cio literowy string ŁŁŁŁŁ nie przejdzie, ponieważ ma 10 bajtów (5 * 2 = 10 >). Również dolny limit się nie sprawdzi, ponieważ można podać np. samo C5 (1 bajt), czyli "pół litery".

Więc... jak to naprawić?
1. Użyć jakiejś funkcji z zestawu mb_*, które rozumieją UTF-8, np. mb_ereg (należy pamiętać aby ustawić mb_regex_encoding lub mb_internal_encoding na UTF-8!).
2. Wygląda na to, że dodanie na początku regexpa stringu (*UTF8) również załatwia sprawę (w tym wypadku powinno być preg_match('/(*UTF8)^[a-zA-Zążśźęćń󳥯ŚŹĘĆŃÓŁ]{1,5}$/', $input_text)), jednak z tego co słyszałem, to czy to działa czy nie, zależy od tego jak PHP był skompilowany (nie znam niestety szczegółów), więc może to nie ruszyć na niektórych hostingach, lub np. na naszym localhoscie.
3. Jak podpowiada komentarz po angielskiej stronie lustra, dodanie u na koniec regexpa również rozwiąże problem (preg_match('/^[a-zA-Zążśźęćń󳥯ŚŹĘĆŃÓŁ]{1,5}$/u', $input_text)). Natomiast nie testowałem czy działa to wszędzie (patrz uwagi punkt wyżej).
4. PHP 6 ma być natywnie wspierać unicode... ale to jeszcze trochę :)

By the way...
On 22nd Nov'24 we're running a webinar called "CVEs of SSH" – it's free, but requires sign up: https://hexarcana.ch/workshops/cves-of-ssh (Dan from HexArcana is the speaker).

OK, to tyle na dziś.

P.S. testy (i kod testów) które robiłem do tego postu można znaleźć tutaj
Tests
Tests (source code)

P.S.2. ale wiecie że strlen('string w utf-8') zwraca ilość bajtów a nie liter, tak? tak??? właśnie dlatego powstała funkcja mb_strlen() :)