2

7 lutego 2017 badacz bezpieczeństwa Omer Gil opublikował wpis opisujący atak “Web Cache Deception” (Oszukanie Pamięci Podręcznej Strony Internetowej). Wykorzystuje on funkcjonalność buforowania stron internetowych w celu potencjalnego ujawnienia poufnych informacji lub umożliwienia przejęcia konta (ang. Account Takeover). Buforowanie stron (ang. Web Caching) jest często używane w celu zmniejszenia obciążenia serwerów WWW i czasu ładowania treści stron. Atak Web Cache Deception pokazuje sposoby, w których biorąc pod uwagę pewne konfiguracje serwerów funkcja buforowania może być niewłaściwie użyta do udostępnienia treści nieprzeznaczonych do informacji publicznej. Zarówno buforujący serwer proxy, jak i strona źródłowa indywidualnie mogą mieć poprawne konfiguracje. Jednak w połączeniu ich w jeden system może dojść do nieoczekiwanego zachowania w świetle tej nowej metody ataku.

Załóżmy, że strona https://www.taf.it.life/ jest skonfigurowana tak, aby łączność klienta z nią przechodziła przez odwrotne proxy (ang. Reverse Proxy). Dynamiczna strona https://www.taf.it.life/user.php, która jest umieszczona na serwerze web (np. nginx + php-fpm) zwraca personalne dane zalogowanych użytkowników (oczywiście dla każdego inny wpis). Tego rodzaju dane, a przynajmniej ich spersonalizowane części nie są buforowane w pamięci podręcznej serwera proxy. Bardziej sensowną techniką i powszechnie stosowaną jest umieszczanie w pamięci cache publicznie dostępnych, statycznych plików typu: arkuszy stylów (.css), skryptów (.js), plików graficznych (.jpg, .png) itd. Ma to sens, ponieważ pliki tego rodzaju nie zawierają żadnych poufnych informacji. Ponadto w wielu dokumentach odnoszących się do dobrych praktyk konfiguracji serwerów proxy zaleca się buforowanie wszystkich statycznych plików, które mają być publiczne oraz ignorowania ich nagłówków HTTP.

Jeśli zalogujemy się na swoje konto do serwisu taf.it.life i w przeglądarce ręcznie przejdziemy do adresu URL typu: https://www.taf.it.life/user.php/ten_plik_nie_istnieje.css – ciekawą rzeczą może być reakcja serwera – jak zinterpretuje on adres URL żądania HTTP? W zależności od technologii i konfiguracji (struktura adresu URL może wymagać zbudowania go w nieco innej formie dla różnych serwisów i serwerów) może on zwrócić “czystą” stronę 404, co jest OK lub treść strony https://www.taf.it.life/user.php, co oznacza prawdopodobieństwo podatności na atak oszukania pamięci podręcznej. Bo jeśli adres URL pozostanie w przeglądarce pod postacią: https://www.taf.it.life/user.php/ten_plik_nie_istnieje.css, ale treść strony i nagłówki HTTP będą takie same jak dla bezpośredniego dostępu do https://www.taf.it.life/user.php/ – to może oznaczać to, że właśnie wstrzyknęliśmy ją do pamięci cache serwera proxy.

Mając świadomość takiej luki w konfiguracji wystarczy teraz, że atakujący zwabi zalogowanego użytkownika do wywołania strony https://www.taf.it.life/user.php/nic_tu_nie_ma.css – powodując, że strona ta – zawierająca osobiste treści użytkownika – będzie przechowywana w pamięci podręcznej serwera proxy, a tym samym publicznie dostępna. Wariant ten może być jeszcze groszy – jeśli w treści odpowiedzi (źródle strony lub nagłówkach HTTP) znajdą się informacje typu: identyfikator sesji, tokeny CSRF, czy odpowiedzi na inne mechanizmy bezpieczeństwa – wówczas atakujący będzie w stanie sam uzyskać dostęp do tej strony i reszty nieujawnionych jeszcze danych.

Atak tego typu może zostać wywołany w dowolnej części strony, w której serwer źródłowy i pośredniczący nie zgadzają się, co do polityki buforowania. Problemy mogą stanowić różnorodne adresy URL i konfiguracje dynamicznych skryptów – różniące się w zależności od języka lub platformy programistycznej. Nie ma prostego testu zbiorczego dla tego typu luki. Podczas, gdy strona główna witryny może pozostać wolna od luk, inne jej elementy nadal mogą być podatne. Oznacza to, że w miarę możliwości powinniśmy zapoznać się i przetestować posiadaną konfigurację. Działania łagodzące powinny być skoncentrowane na przeglądzie konfiguracji, a nie na śledzeniu logów, aby wykryć wcześniejsze próby ataków. Warto pamiętać, aby:

– skrypty i aplikacje, które nie spodziewają się otrzymywać argumentów w URI po ich lokalizacji powinny przekierować (kody: 301, 302) z powrotem do adresu URL, który spodziewają się obsłużyć lub odpowiedzieć stroną 404,
– upewnić się, że serwery pośredniczące ściśle przestrzegają ustawień dotyczących buforowania plików z źródłowych serwerów, szczególnie gdy przekazywane są ustawienia: no-store lub no-cache,
– wyłączyć funkcje, które mogą powodować zamieszanie związane z rozszerzeniem plików między serwerem proxy, a źródłowym (np. AcceptPathInfo, złe reguły rewrite).

Więcej informacji: Web Cache Deception Attack, Web Cache Deception Attack revisited