W odpowiedzi na jeden z komentarzy Pawła Krawczyka odpisałem:
(...) Można też z góry wykluczyć pewne grupy podatności jako nieistotne w przypadku danej aplikacji. Przykładowo: "podatność" wyszukiwarki Google na CSRF. (...)
Dziś krótko o tym, dlaczego nie miałem racji, czyli dlaczego podatność wyszukiwarki na CSRF mogłaby być istotna.
Pierwszy scenariusz - uruchamiam nową wyszukiwarkę, a robię to po to oczywiście dla pieniędzy. Staję przed problemem - jak przekonać użytkowników, by korzystali z mojej wyszukiwarki, a nie z Google? Jakość wyników wyszukiwania? Może i tak, ale podejrzewam, że w świadomości wielu przeciętnych użytkowników internetu wyszukiwarka == Google. Dokładnie tak, jak dla wielu Internet to ta niebieska ikonka na pulpicie (IE oczywiście). Może w takim razie trzeba nie tyle zachęcić użytkowników do korzystania z mojej wyszukiwarki, ale zniechęcić ich do wykorzystania Google? Jak to zrobić?
Korzystał ktoś z Was z Goolag Scanner? Po pewnym (krótkim) czasie Google prosiło o podanie kodu z wyświetlonej CAPTCHA, bo wysyłane żądania "zbyt przypominały wirusa": 'We're sorry...' (error 403). Być może (bo nie sprawdzałem) mógłbym zmusić potencjalnych klientów do "zirytowania" Google przez wysłanie sporej ilości podejrzanych żądań. Wówczas z kolei zirytowani klienci (sam bym się zirytował, gdyby przy każdej próbie wyszukiwania pojawiała się CAPTCHA) postanowiliby znaleźć inną wyszukiwarkę, która nie powoduje takich "problemów". Oczywiście moją :) Mogłoby mi wówczas również zależeć na umieszczeniu kodu wysyłającego "podejrzane" żądania do Google na możliwie dużej ilości często odwiedzanych stron. Wszystko po to, by ilość zirytowanych użytkowników Google, a więc moich potencjalnych klientów, była jak największa.
Czy taki scenariusz jest możliwy? Tak, jak najbardziej. Żądanie wysyłane przez przeglądarkę do Google wygląda mniej więcej tak:
GET /search?hl=en&q=bezpiecze%C5%84stwo+aplikacji+internetowych HTTP/1.1
Jak widać nie ma w nim żadnego unikalnego fragmentu (losowego tokenu), więc sfałszowanie takiego żądania jest trywialne. Do pełnego sukcesu brakuje prostego skryptu oraz listy "przydatnych" zapytań, które będą wyglądały jak wygenerowane przez wirusy lub spyware.
Drugi scenariusz jest już mniej wydumany. Chodzi o pozycjonowanie, czyli znów o pieniądze. Nie jestem ekspertem od SEO, nie zgłębiam informacji i plotek na temat działania algorytmu Google (i innych wyszukiwarek). Być może wyniki i zwracane przez wyszukiwarki zależą po części od akcji, które wcześniej wykonali użytkownicy na wynikach wyszukiwania. Być może w przypadku, gdy częściej klikany będzie 5 link od góry niż ten na pierwszym miejscu, kolejność wyników zmieni się. A wiadomo, że lepiej lepiej być w pierwszej trójce niż "tylko" w drugiej piątce.
Wygenerowanie żądania do wyszukiwarki jest zadaniem trywialnym, co się już udało ustalić wcześniej. Co się dzieje, gdy użytkownik klika w wybrany przez siebie rezultat? Generowane jest między innymi następujące żądanie:
GET /url?sa=T&source=web&ct=res&cd=9&url=http%3A%2F%2Fthreats.pl%2Fbezpieczenstwo-aplikacji-internetowych&ei=pFPKSq6PFZSomgOOzZRG&sig2=-KaUMGjySPZ6CRwkcNDkpQ HTTP/1.1
Warto zwrócić uwagę na dwa parametry: ei oraz sig2. Wyglądają one na losowe, tak więc (prawdopodobnie) nie jestem w stanie symulować operacji "kliknięcia" w link znajdujący się w wynikach. Oczywiście znów prawdopodobnie, bo ani sprawdzania losowości tych parametrów, ani rzeczywistego wpływu "klikania" (prawdziwego lub sfałszowanego) na rezultaty kolejnych wyszukiwań nie sprawdzałem.
Na zakończenie jedna uwaga. Jest to przykład, dlaczego przy testach penetracyjnych warto patrzeć przez pryzmat celów intruza, a nie podatności (a przynajmniej nie tylko). Odpowiednie "wypromowanie" treści może być celem intruza, CSRF natomiast sposobem realizacji tego celu.
