Paweł Goleń, blog

Ostatnio w testowanej aplikacji znalazłem nietypowego XSS. Na formatce tej zastosowana była walidacja danych zarówno po stronie klienta (JavaScript), jak i po stronie serwera. Reguły walidacji były spójne, dotyczyły nawet pól typu "radio button". I choć wydaje się to mało prawdopodobne, to właśnie w tym polu był XSS. Jak to działało? Dość ciekawie - serwer stwierdzał, że wartość pola jest niepoprawna i nie następowało przejście do kolejnego kroku aplikacji, lecz powrót do wysłanej formatki z prośbą o poprawienie wpisanych danych. Na stronie tej znajdował się skrypt odpowiedzialny za ustawienie na formatce parametrów takich, jak poprzednio wpisane przez użytkownika. Wartość parametru (przycisku) wstawiana była bezpośrednio do tego skryptu (z częściowym, ale nie pełnym, encodingiem). W rezultacie odpowiednio przygotowana wartość przekazana do serwera jako wartość przycisku, była wpisywana do skryptu, który uruchamiany był za każdym razem po załadowaniu strony.

Jakiś czas temu Microsoft został napiętnowany za stwierdzenie, że "przewracanie się" aplikacji jest jednym z mechanizmów bezpieczeństwa. W tej chwili nie jestem na 100% pewny o co chodziło, ale wydaje mi się, że sytuacja taka miała miejsce w przypadku, gdy jedna z aplikacji Microsoft Office przetwarzała "uszkodzony" dokument (Office 2007 security plans make it crash, Crashes Are Bad, OK?, Is a DoS a valid security problem?). Wbrew pozorom podejście takie jest sensowne. Oczywiście nie chodzi tutaj o to, by aplikacja "przewracała się" przy każdym napotkanym błędzie, ale w niektórych sytuacjach próba dalszego działania jest większym ryzykiem.

W omawianym przeze mnie przypadku mamy ewidentnie do czynienia z sytuacją, w której aplikacja usiłuje działać, w przypadku, gdy wystąpiły błędy. Błędy, które nie mają prawa wystąpić. Dlaczego? Aplikacja korzystała z walidatorów zarówno po stronie klienta, jak i serwera. Jeśli walidatory te są spójne (przynajmniej jeśli chodzi o format i zakres danych, bo być może pewna walidacja kontekstowa nie jest możliwa do wykonania po stronie klienta/serwera), to do serwera nie ma prawa dojść coś, co nie przejdzie przez walidator po stronie klienta. Jeśli coś takiego się dzieje, to sytuacja jest jasna - tampering. W takim przypadku lepiej jest przerwać działanie aplikacji i wylogować użytkownika, niż próbować działać dalej. W tym przypadku dane zostały wykorzystane, mimo tego, że system stwierdził, że są nieprawidłowe. W rezultacie pomimo zastosowania jednego środka zabezpieczającego (walidacja danych), to w wyniku wykorzystania zmodyfikowanych danych i nieskuteczności drugiego środka zabezpieczającego (encoding), pojawił się XSS.