11 Jan 07 Problemy z kodowaniem UTF-7
Jedna z ostatnich luk SQL-injection w Wordpress zainspirowała mnie do przeprowadzenia krótkiego testu kilku polskich serwisów pocztowych. W tego typu aplikacjach naturalna jest konwersja treści listów z dowolnego kodowania. Jeżeli listy w postaci HTML są filtrowane z niebezpiecznego kodu przed konwersją kodowania, wówczas może wystąpić w serwisie luka XSS (a w skrajnym przypadku także SQL-injection).
Wyniki są pozornie pozytywne - podczas testu (obejmującego tylko UTF-7, i naprawdę bardzo pobieżnego) nie znalazłem luki spowodowanej błędną kolejnością filtrowania/konwersji. Dlaczego “pozornie pozytywne”?
- Większość testowanych serwisów w ogóle nie konwertuje listów w kodowaniu UTF-7 (test obejmował wyłącznie HTML, bez alternatywy tekstowej). Efektem są “krzaczki”.
- Jeden z wyjątków (Wirtualna Polska) zamiast konwersji stosuje ramkę z kodowaniem UTF-7, przy czym filtry nie obejmują znaków specjalnych HTML w tym kodowaniu. Powoduje to podatność na XSS.
Na marginesie: wszystkie testowane serwisy pocztowe wymagają włączenia obsługi JavaScript do poprawnego funkcjonowania.
Aktualizacja (11 stycznia): Więcej informacji na temat luk XSS w serwisach pocztowych (i nie tylko) można znaleźć na blogach Michała Majchrowicza i Michała Ławickiego.
Ponad rok temu podobna luka występowała w Google. Prostą próbkę błędnego kodu można znaleźć na stronie Chrisa Shifletta. W podanym tam przykładzie problem jest dokładnie odwrotny - ponieważ “obce” kodowanie dotyczy danych wyjściowych, a nie wejściowych, więc prawidłowa kolejność to filtrowanie-konwersja (w szczególnych przypadkach mogą wystąpić wyjątki od tej reguły).
Leave a Comment
