Unserialize może zrobić krzywdę

Wampiryczny blog

Poniedziałek, grudnia 14. 2009

Unserialize może zrobić krzywdę

Zamieścił

w WebApps o 07:58 | Brak komentarzy | Brak Śladów

W drugim wyzwaniu na bootcamp została wykorzystana serializacja danych do przechowywania stanu sesji (patrz pierwsza część wyjaśnienia do zadania). Przykłady, które prezentuje mają przedstawiać typowe problemy z bezpieczeństwem aplikacji internetowych, a nie z konkretnym środowiskiem/językiem programowania, ten przykład jest praktyczną demonstracją problemu określanego jako CWE-642: External Control of Critical State Data, o czym już kilka razy wspominałem. Warto jednak zatrzymać się na chwilę przy funkcjach serialize/unserialize w PHP.

W przypadku serializacji obiektów wywoływane są dwie ich metody:

__sleep przy wywołaniu funkcji serialize,
__wakeup przy wywołaniu funkcji unserialize,

W sprzyjających warunkach pozwala to na wykonanie własnego kodu na serwerze. Przykłady takich przypadków można znaleźć we wspominanej już przeze mnie prezentacji Shocking News in PHP Exploitation, taki jest też mechanizm podatności Piwik Cookie unserialize() Vulnerability.

A jak sobie z tym problemem radzić? Trzeba wykorzystać mechanizm, który pozwoli na wykrycie próby tamperingu. Oczywiście nie może to być po prostu funkcja hashująca (jeśli jej wynik jest również przechowywany po stronie klienta). W przykładach z PHP często wykorzystywana jest konstrukcja typu md5($tajnehaslo.$dane), ja jestem zwolennikiem wykorzystania hmac. Niby efekt podobny, ale lepsza forma :)

Następny wpis: Nie pytaj o coś, co już wiesz
Poprzedni wpis: Wykorzystanie data: do wstawienia skryptu

Ślady

Użyj tego linku jeśli chcesz stworzyć Ślad (Trackback) do tego wpisu

Brak Śladów

Komentarze

Brak komentarzy

Dodaj komentarz