Читать книгу Na tropie błędów. Przewodnik hakerski - Peter Yaworski - Страница 13

Otwarte przekierowania pojawiają się wtedy, gdy deweloper błędnie zaufa wejściu kontrolowanemu przez potencjalnego atakującego i przekierowuje użytkownika na inną stronę, zazwyczaj za pomocą parametrów URL, znaczników odświeżających HTML <meta> lub własności lokalizacji okna DOM.

Wiele stron celowo odsyła użytkowników na inne strony, umieszczając docelowy adres URL jako parametr w oryginalnym URL-u. Aplikacja wykorzystuje ten parametr, żeby powiedzieć wyszukiwarce, by wysłała żądanie GET do docelowego adresu URL. Na przykład załóżmy, że Google ma możliwość przekierowywania użytkowników do Gmaila przez odwiedzenie następującego adresu URL:

https://www.google.com/?redirect_to=https://www.gmail.com

W tym przypadku, gdy odwiedzisz ten link, Google otrzyma żądanie HTTP GET i użyje parametru redirect_to, by zdecydować, gdzie przekierować Twoją przeglądarkę. Po zrobieniu tego serwery Google zwracają odpowiedź HTTP z kodem statusu instruującym Twoją przeglądarkę do przekierowania użytkownika. Zazwyczaj jest to kod 302, ale w niektórych przypadkach może to być 301, 303, 307 lub 308. Wszystkie te kody HTTP mówią Twojej przeglądarce, że strona została znaleziona; jednakże kod również informuje przeglądarkę, by wykonała żądanie GET do adresu znalezionego w wartości parametru redirect_to, https://www.google.com/, który jest oznaczony w nagłówku odpowiedzi HTTP Location. Nagłówek Location określa, gdzie przekierować żądanie GET.

Teraz przypuśćmy, że atakujący zmienił oryginalny link na poniższy:

https://www.google.com/?redirect_to=https://www.attacker.com

Jeśli Google nie weryfikuje, czy parametr redirect_to należy do jednego z jego prawowitych serwerów, gdzie zazwyczaj odsyła użytkowników, atakujący mógłby podmienić wartość parametru z jego własnym URL-em. W wyniku tego odpowiedź HTTP mogłaby instruować Twoją przeglądarkę do wysłania żądania GET na stronę https://www.<attacker>.com/. Kiedy atakujący wreszcie przyciągnął Cię na swoją złośliwą stronę, jest w stanie wykonać na Tobie kolejne ataki.

Gdy poszukujesz podatności tego rodzaju, miej na uwadze parametry URL włączające pewne nazwy, takie jak url=, redirect=, next= i tym podobne, mogące wskazywać na URL, do którego użytkownicy będą przekierowywani. Również pamiętaj o tym, że parametry nie będą zawsze oczywiście nazwane; parametry będą się różniły od siebie na różnych stronach, a nawet w obrębie jednej. W niektórych przypadkach parametry mogą być oznaczone tylko jednym znakiem, takim jak r= czy u=.

W dodatku do ataków bazujących na parametrach, tagi HTML <meta> i JavaScript mogą również przekierowywać przeglądarkę. Tagi <meta> HTML mówią przeglądarce, aby odświeżyć stronę i wykonać żądanie GET na adres URL zdefiniowany w atrybucie content. Oto jak może wyglądać jeden z nich:

<meta http-equiv="refresh" content="0; url=https://www.google.com/">

Atrybut content definiuje, jak przeglądarka wykona żądanie HTTP, na dwa sposoby. Po pierwsze, content określa, jak długo przeglądarka czeka przed wysłaniem żądania HTTP pod wskazany adres; w tym przypadku 0 sekund. Po drugie, atrybut content wyznacza parametr URL strony, do której wysyła żądanie GET; w tym przypadku http://www.google.com. Atakujący mogą wykorzystać te zachowania w sytuacjach, w których kontrolują atrybut content w tagu <meta> lub dodać własny tag przez inną  podatność.

Atakujący może również użyć kodu JavaScript, by przekierować użytkowników przez modyfikację właściwości location okna przez obiektowy model dokumentu (DOM – Document Object Model). DOM jest interfejsem programowania dla dokumentów HTML i XML, który pozwala deweloperom na modyfikowanie struktury, stylów i zawartości strony internetowej. Ponieważ właściwość location wskazuje, gdzie żądanie powinno zostać przekierowane, przeglądarka niezwłocznie zinterpretuje szkodliwy JavaScript i przekieruje do określonego adresu URL. Atakujący może modyfikować własność location okna, używając jednego z wybranych skryptów:

window.location = https://www.google.com/

window.location.href = https://www.google.com

window.location.replace(https://www.google.com)

Zazwyczaj możliwość zmiany wartości window.location pojawia się jedynie tam, gdzie atakujący może wykonać kod JavaScript, przez podatność cross-site scripting (XSS), albo tam, gdzie strona celowo pozwala użytkownikom decydować o adresie URL do przekierowania, podobnie jak w podatności serwisu HackerOne omawianej później w tym rozdziale, na stronie 16.

Kiedy szukasz podatności na otwarte przekierowanie, najczęściej będziesz monitorował swoją historię proxy, szukając żądań GET wysłanych do strony, którą testujesz.