Jesteśmy przyzwyczajeni, że dzisiejsze strony internetowe zawierają odnośniki do innych serwisów.
Ale czy automatyczne przekierowanie na zewnętrzną domenę może być szkodliwe?
Jeżeli część zasobów witryny dostępna jest tylko dla zalogowanych użytkowników - po przejściu na taką podstronę jako niezalogowana osoba jesteśmy przekierowywani do formularza logowania.
Często w adresie URL możemy dostrzec parametry nazwane redirect czy też next, wskazujące na podstronę, która ma się wyświetlić po autoryzacji.
Dziś porozmawiamy właśnie o tych parametrach i o błędzie "Open redirection" - czyli otwarte przekierowanie.
Opisywana funkcjonalność jest prosta w implementacji. Przeglądarka otrzymując nagłówek Location, przenosi nas na podany w nim adres.
Większość frameworków posiada funkcje do ustawienia tej wartości.
Przykład w Javie, gdzie do funkcji sendRedirect przekazujemy parametr redirect.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class RedirectionExample extends HttpServlet {
@Override
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
response.sendRedirect(request.getParameter("redirect"));
}
}Standardowo przekazuje się tu adres strony, która ma być wyświetlona po zalogowaniu.
Nic jednak nie stoi na przeszkodzie, aby w parametrze tym przekazać inną domenę niż obecnie używana.
Dla przykładu google.pl.
Można sobie teraz zadać pytanie: ale co w tym złego?
Zamiast przejść na naszą stronę użytkownik zostanie jedynie przeniesiony na inną witrynę.
Żadne dane jednak nie wyciekną. Konto odwiedzającego jest bezpieczne - o co zatem tyle hałasu?
Żeby zrozumieć dlaczego - musimy opisać atak phishingowy.
Phishing - czyli metoda oszustwa, w której podszywamy się pod kogoś lub coś, aby wyłudzić jakieś interesujące nas informacje.
Przykład: dostajemy email od naszego banku, że ktoś próbował się włamać na nasze konto i ze względów bezpieczeństwa należy zmienić hasło do konta.
Jako iż jesteśmy świadomi niebezpieczeństwa - sprawdzamy adres domeny, na którą kieruje odnośnik w wiadomości.
Domena się zgadza - jest identyczna z domeną naszego banku.
Klikamy więc w link i przystępujemy do procedury zmiany hasła.
Trafiamy jednak na stronę przestępców - którzy chcą wyłudzić nasze dane.
Jak do tego doszło? Witryna banku zawierała błąd open redirection.
Atakujący korzystając więc z zaufania jakim darzy się instytucje finansowe, przekazał odpowiednio spreparowany parametr redirection.
Użytkownik sprawdzając nazwę domeny widział prawdziwą domenę banku, nie sprawdził jednak parametrów, które były do niej przekazywane.
Wiemy już dlaczego powinniśmy sprawdzać w jakie miejsca kierujemy użytkownika.
Pora przedstawić metody obejścia zabezpieczeń.
Najpopularniejszą metodą jest sprawdzanie czy link zaczyna się od "/".
Takie linki bowiem odnoszą się do treści w naszej domenie.
Ten filtr można obejść dokładając do "/" dodatkowy "/". Podwójny znak "//" przekieruje nas na prawidłową nazwę domeny.
Kolejnym pomysłem jest sprawdzanie, czy adres zaczyna się od http albo https.
W adresie url może być zawarty login i hasło, którymi użytkownik może się zalogować do danego serwisu.
Używając tej funkcjonalności możemy po wymaganym ciągu http podać @, a dalej domenę do której chcemy przekierować.
Wszystko przed małpką zostanie potraktowane jako login i hasło do serwisu.
Ostatnim często spotykanym filtrem jest sprawdzanie, czy w przekazywanym przez użytkownika linku znajduje się nazwa naszej domeny.
Da przykładu: czy w nazwie jest google.pl.
Jeżeli taki ciąg jest poszukiwany w całym linku, nic nie stoi na przeszkodzie aby stworzyć subdomenę google.pl która będzie hostowana w ramach innej domeny.
Ciąg do ataku będzie zatem wyglądał następująco: google.pl.szurek.pl.
Pamiętajmy aby przekierowywać użytkownika tylko w zaufane miejsca.
Icon made by Freepik, Maxim Basinski from www.flaticon.com
