Czasami zdarza się, że odnalezione przez nas błędy nie są możliwe do wykorzystania w normalnych warunkach.
Jednym z takich błędów jest self XSS, kiedy to użytkownik wchodzi na stronę internetową, otwiera konsole deweloperską przeglądarki i wkleja do niej złośliwy kod.
Dlatego tez niektóre strony - na przykład Facebook - wyświetlają w tej konsoli specjalną wiadomość, informując tym samym użytkownika, że nie powinien wklejać tutaj niczego jeżeli nie jest programistą.
Innym rodzajem ataków są XSS-y, które wykorzystują niektóre, specyficzne nagłówki ustawiane automatycznie przez przeglądarkę.
Dla przykładu USER-AGENT, czyli informacja na temat bieżącej przeglądarki.
Nagłówek ten ustawia sama przeglądarka i bez specjalnych rozszerzeń użytkownik wchodzący na stronę nie ma żadnego wpływu na jego zawartość i nie może go zmienić.
W dzisiejszym odcinku opisze atak Web Cache Poisoning, który sprawia, że jesteśmy w stanie ustawić te nagłówki, na takie zawierające złośliwą zawartość.
Zacznijmy od przykładu.
Jest to bardzo prosty kod, który pobiera wartość nagłówka user agent i wyświetla bez żadnej weryfikacji i walidacji na naszej stronie.
Standardowo widzimy tutaj wersje przeglądarki.
Możemy jednak ten nagłówek zmodyfikować - na przykład z poziomu narzędzia Burp -
wpisując w jego miejsce złośliwy kod JavaScript.
Ten kod zostanie wyświetlony na podatnej stronie - mamy więc potencjalny atak XSS, tylko że niemożliwy do przeprowadzenia, ponieważ musielibyśmy najpierw ręcznie przekonać użytkownika do zmodyfikowania treści tego nagłówka na przykład poprzez instalacje rozszerzenia do przeglądarki1.
Dlatego też przez długi okres czasu takie błędy były ignorowane przez twórców stron internetowych i nie traktowane jako prawdziwe błędy bezpieczeństwa.
Ale branża security to dynamiczna działka i tutaj wszystko szybko się zmienia.
Jeżeli bowiem strona jest popularna - istnieje duża szansa, że używa jakiegoś mechanizmu cache, aby nie odpytywać bazy danych za każdym razem gdy użytkownicy ciągle proszą o tą samą treść.
Zazwyczaj tego rodzaju mechanizmy opierają się na tak zwanych cache keys.
Jest to jakaś część żądania na podstawie której serwer stwierdza, że posiada już podana treść w pamięci podręcznej i może ją zwrócić użytkownikowi.
Najprostszym kluczem mogą być wartości GET przekazywane przez użytkownika w adresie URL.
Dla każdej unikalnej wartości - tworzony jest nowy cache.
Jeżeli wartości w adresie są takie same - zwracana jest poprzednia zawartość strony.
Innym przykładem może być nagłówek Accept-language, w którym przeglądarka wysyła informację na temat języka bieżącego użytkownika.
Jeżeli nasza strona dostępna jest w różnych językach nie wystarczy sam adres URL.
Treść różni się bowiem również ze względu na używany przez użytkownika język.
W takim wypadku cache keys musi także brać pod uwagę ten dodatkowy parametr.
No dobrze, ale dlaczego o tym wspominam?
Jeżeli wiemy jakie wartości cache keys używa dana strona możemy niejako kontrolować treść pamięci podręcznej.
Popatrzmy na kolejny przykład.
Tym razem strona wyświetla bieżącą datę oraz user agent przeglądarki.
Dane są zapisywane do pamięci podręcznej bazując na adresie URL.
Jeżeli wiec podajemy unikalny adres - zwracana jest bieżąca data.
Jeżeli jednak odświeżamy użyty już wcześniej adres - godzina nie zmienia się - co oznacza, że treść danej strony została zwrócona z pamięci cache.
Jak zatem wygląda atak Web cache poisoning?
Przy pomocy narzędzia Burp modyfikujemy nagłówek user agent tak, aby zawierał payload XSS.
Tak zmodyfikowane żądanie wysyłamy wykorzystując unikalny adres URLtak, aby serwer zachował naszą treść w pamięci.
Jak widać w odpowiedzi serwer zwrócił bieżącą datę oraz nasz złośliwy kod.
Teraz, wystarczy już tylko przekonać użytkownika do odwiedzenia podatnej strony przy pomocy unikalnego adresu, którego użyliśmy wcześniej.
Jego przeglądarka ma ustawiony normalny nagłówek user agent.
Ale to nie on zostanie wyświetlony na tej stronie ponieważ ten adres był już wcześniej użyty, serwer zwróci zawartość strony z pamięci podręcznej.
A tam zawartość nagłówka user-agent była przez nas kontrolowana i zawierała podatność XSS.
Dzięki temu mogliśmy wykorzystać podatność, która jeszcze parę chwil temu wydawała się niemożliwa do wykorzystania w normalnych warunkach.
Oczywiście atak ten działa jedynie jeżeli strona używa jakiegoś mechanizmu cache.
Icon made by Freepik, Smashicons, srip from www.flaticon.com
