threats.pl > Bezpieczeństwo aplikacji internetowych > Lekcja 17: Wyzwanie II > Lekcja 17: Wyjaśnienie, część pierwsza

Lekcja 17: Wyjaśnienie, część pierwsza

Wprowadzenie do tematu: External Control of Critical State Data

Główną podpowiedzią do tego zadanie jest odesłanie do znajdującego się na liście 2009 CWE/SANS Top 25 Most Dangerous Programming Errors punktu CWE-642: External Control of Critical State Data.

Sposób obsługi sesji

Obserwując działanie przykładu http://bootcamp.threats.pl/lesson17/ można zauważyć, że aplikacja w żadnym momencie nie ustawia cookie. Z drugiej strony aplikacja musi obsługiwać w jakiś sposób stanowość. Brak cookie oznacza, że obsługa sesji w tym przypadku nie jest prawdopodobnie zrealizowana w sposób standardowy.

W kodzie zwracanych stron można znaleźć następujący fragment:

<input type="hidden" name="SessionState"
value="eJxlybsRgCAQBcBergBGDvk9ImtxOIwYJSDAsXcxNt2tWHELPOjMrZZ2UerQbKN2JjpOgg(...)" />

Analiza sposobu przechowywania stanu sesji

Sama nazwa parametru, SessionState, sugeruje, że może być on elementem implementacji niestandardowej obsługi sesji. Kluczem do rozwiązania zadania będzie więc stwierdzenie czym jest wartość parametru SessionState.

Wartość zawarta w SessionState zakodowana jest przy pomocy base64, kodowanie to można spotkać często w przypadku aplikacji internetowych. Przykładem może być na przykład ViewState znane z ASP.NET lub JSF.

Po zdjęciu kodowania base64 otrzymuje się dane binarne. Dane te można poddać różnym analizom, na przykład analizie losowości, w celu ustalenia czym one w rzeczywistości są. Można też spróbować innego często stosowanego algorytmu - gzip. Można przypuszczać, że programiści chcieli zminimalizować ilość przesyłanych danych. W tym celu mogli wykorzystać kompresję, a gzip jest jednym z bardziej popularnych algorytmów często wykorzystywanych do tego właśnie celu. W efekcie otrzymuje się dane następującej postaci:

n:4:{f:7:"perngrq";v:1259165418;f:9:"gvzrfgnzc";v:1259165418;f:2:"vc";f:11:"10.20.30.40";f:4:"hfre";A;}

Otrzymane dane nie są zbyt czytelne, ale można z dużym prawdopodobieństwem przypuszczać, że wynika to z zastosowania algorytmu rot13. Po zdjęciu "szyfrowania" otrzymuje się bardziej czytelną postać:

a:4:{s:7:"created";i:1259165418;s:9:"timestamp";i:1259165418;s:2:"ip";s:11:"10.20.30.40";s:4:"user";N;}

Można przypuszczać, że zastosowana została serializacja danych, co można w łatwy sposób zweryfikować przy pomocy funkcji serialize oraz unserialize.

Brak zabezpieczenia danych sesji przed modyfikacją

Kluczowym problemem w tej implementacji sesji jest brak jakiegokolwiek zabezpieczenia przed modyfikacją danych sesji przez użytkownika. Pozostaje sprawdzić jakie dane są przechowywane w sesji i jak aplikacja reaguje na ich modyfikację.