Przyjmując założenie, iż serwer podejmuje działania na podstawie określonego warunku, analizujmy sytuację, w której serwer wykonuje obliczenia w zależności od wyniku tego warunku i następnie przekazuje odpowiedź użytkownikowi. W obu przypadkach, czyli zarówno gdy obliczenia są wykonywane, jak i gdy nie są, serwer zwraca odpowiedź użytkownikowi. Warto zauważyć, iż w sytuacji, gdy serwer wykonuje obliczenia, zużywa określoną ilość zasobów, co prowadzi do wydłużenia czasu odpowiedzi serwera. Zwykle różnice te w czasie odpowiedzi są na tyle niewielkie, iż nie są zauważalne dla użytkownika końcowego. Niemniej jednak, ujawnienie tych subtelnych różnic w czasie odpowiedzi może doprowadzić do niezamierzonego wycieku danych.
Rozważmy teraz praktyczny przykład tej sytuacji, który opiera się na procesie logowania do aplikacji. Załóżmy, iż podany login jest poprawny, ale hasło jest błędne: w takim przypadku serwer może podjąć decyzję o wykonaniu obliczeń, na przykład weryfikacji hasła. jeżeli serwer przeprowadza te obliczenia, może to wymagać dodatkowych zasobów i spowodować dłuższy czas odpowiedzi w porównaniu z przypadkiem, gdy obliczenia nie są wykonywane. Chociaż różnice w czasie odpowiedzi są zwykle małe, są one obecne i mogą być mierzone przez atakującego.
Ten sam proces, ale gdy także login jest błędny:
W przypadku tak subtelnych różnic w czasie odpowiedzi atakujący może próbować wykorzystać tę informację do wnioskowania o poprawności loginu. Na przykład, atakujący może przeprowadzić atak typu timing attack, analizując czas, który serwer potrzebuje na odpowiedź na zapytania z różnymi loginami. Poprzez porównanie czasów odpowiedzi, atakujący może wywnioskować, które zapytanie zajęło więcej czasu, co sugeruje, iż login był poprawny. Ujawnienie loginu użytkownika umożliwia atakującym przeprowadzenie ataku siłowego zgadywania hasła. W niektórych przypadkach może również oznaczać ujawnienie wrażliwych informacji, zwłaszcza gdy loginem jest adres e-mail powiązany z konkretną osobą, a testowana aplikacja to portal z kontrowersyjnymi treściami.
Testowanie dzięki Burp Suite – Request Timer
Podczas poszukiwań tego rodzaju podatności, przydatna będzie wtyczka do Burpa o nazwie Request Timer. Ta wtyczka pozwoli nam zbadać czas odpowiedzi serwera dla określonych przez nas żądań.
Pierwszym krokiem będzie przechwycenie żądania odpowiedzialnego za logowanie użytkownika i przesłanie go do modułu Intruder:
Następnie zmieniamy hasło na długi ciąg znaków, aby zwiększyć obciążenie serwera podczas generowania hasha hasła. Wskazujemy miejsce, gdzie znajduje się login użytkownika. W przypadku badanej aplikacji konieczne jest także dodanie nagłówka „X-Forwarded-For” i przypisanie mu losowego adresu IP, aby ominąć blokadę wielokrotnych prób logowania z tego samego adresu IP. W związku z tym musimy zmienić typ ataku na „Pitchfork”.
Dodajemy listę loginów do sprawdzenia:
We wtyczce Request Timer definiujemy, żeby nasłuchiwła ona modułu Intrudera:
Po uruchomieniu testu, w zakładce pojawią się wygenerowane żądania wraz z czasem odpowiedzi. Jak można zauważyć, dla poprawnego loginu czas odpowiedzi jest znacznie dłuższy. W ten sposób udowodniliśmy, iż aplikacja jest podatna na enumerację loginów użytkowników poprzez analizę czasu odpowiedzi serwera.
Co zrobić, jak żyć?
Jednym z rozwiązań tego typu problemu jest dodanie funkcji odpowiedzialnej za losowe opóźnianie odpowiedzi serwera:
Niemniej jednak, problemem w przypadku tego typu rozwiązania jest to, iż przez cały czas nie mamy kontroli nad sytuacjami, takimi jak zwolnienie sieci podczas próby połączenia z bazą danych lub różnice pojawiające się, gdy baza danych rośnie w znaczący sposób.
Lepszym rozwiązaniem wydaje się wykonywanie operacji sprawdzania poprawności danych podanych przez użytkownika asynchronicznie w tle i natychmiastowe powiadamianie użytkownika o próbie zalogowania. W takim przypadku obliczenia i opóźnienia z tym związane pozostaną niewidoczne dla atakującego.
