P

odgląd linków (ang. link previews) został zaimplementowany w wielu (web)aplikacjach służących do czatowania i komunikacji – Discord, Facebook, Twitter, LinkedIn, Signal, Slack itd. Każdy nowy lub stary komunikator stara implementować się tą funkcjonalność w swoich produktach. Jeśli ta funkcja nie zostanie wykonana prawidłowo, może prowadzić do różnego rodzaju problemów np. wyciekania adresów IP, ujawnianie odnośników w szyfrowanych rozmowach, czy niepotrzebne pobieranie gigabajtów danych w tyle. Talal Haj Bakry oraz Tommy Mysk przeprowadzili badanie pokazujące, że ta prosta funkcja może stwarzać zagrożenie dla prywatności i bezpieczeństwa.

Wiele aplikacji umożliwiających konwersację w internecie potrafi wyświetlić pogląd linków (i nie chodzi tutaj o rozwijanie skracarek), które wysłałeś swojemu rozmówcy lub odwrotnie – on Tobie. Niezależnie od tego, czy jest to artykuł z wiadomości, dokument, czy śmieszna grafika GIF – (web)aplikacja wygeneruje nam obraz podglądu oraz krótkie podsumowanie treści (tytuł, wstęp) – wszystko to bez konieczności klikania w przesłany link. Pozwala to na zaprezentowanie bardziej przyjaznej wersji suchego odnośnika dla oka. W dłuższych konwersacjach jesteśmy też je w stanie szybciej znaleźć – “pamiętam, że był tam czarny obrazek z jaskrawo zielonym napisem…”. Brzmi, jak fajna funkcja prawda? Ale, czy taka prosta funkcja może wiązać się z kilkoma nieoczekiwanymi obawami dotyczącymi prywatności i bezpieczeństwa?

Podejście 0: Brak generowania linków

Najprostszy i najbezpieczniejszy sposób: w ogóle nie generuj podglądu w aplikacji. Po prostu pokaż link w takiej postaci, w jakiej został wysłany (bez skracania). To najbezpieczniejszy sposób obsługi linków, ponieważ aplikacja nie wchodzi w żadną interakcję z linkiem, chyba że go wyraźnie klikniemy. Od strony użytkownika – najlepiej od razu poszukać możliwości wyłączenia tej funkcjonalności.

Zagrożenia:

– Takie podejście musi zakładać, że osoba wysyłająca link musi być zaufaną, ponieważ to aplikacja nadawcy będzie otwierać link. W przypadku przejęcia konta link ten może być złośliwy.

Podejście 1: Nadawca wiadomości generuje podgląd

W tej wersji, gdy Ty jako nadawca wyślesz komuś odnośnik – aplikacja pobierze zawartość łącza, utworzy podsumowanie i obraz podglądu witryny, który wyśle jako załącznik wraz z linkiem. Gdy aplikacja odbiorcy otrzyma wiadomość, wyświetli podgląd otrzymany od nadawcy (Ciebie) bez konieczności otwierania linku. W ten sposób odbiorca byłby chroniony przed ryzykiem, gdyby sam proces generowania podglądu był złośliwy.

Zagrożenia:

– Takie podejście musi zakładać, że osoba wysyłająca link musi być zaufaną, ponieważ to aplikacja nadawcy będzie otwierać link. W przypadku przejęcia konta link ten może być złośliwy.
– Możliwość wycieku adresu IP nadawcy – aplikacja nadawcy otwiera łączę do wygenerowania podglądu. Serwer poznaje adres IP nadawcy. Może to nie stanowić problemu, jeśli założymy, że nadawca ufa linkowi, który wysyła i to on podejmuje działania, aby wysłać łączę.

Podejście 2: Odbiorca wiadomości generuje podgląd

Najgorszy wariant. Takie podejście oznacza, że za każdym razem, gdy otrzymasz od kogoś link – Twoja aplikacja automatycznie otworzy łącze, aby wygenerować jego podgląd. Stanie się to zanim jeszcze klikniesz w link – wystarczy, że zobaczysz wiadomość.

Zagrożenia:

– Możliwość niekontrolowanego wycieku Twojego adresu IP – nasza aplikacja otwiera łączę pytając zdalny serwer o jego zawartość. Aby serwer wiedział, gdzie odesłać dane, aplikacja musi podać mu swój adres IP (nawet jeśli komunikacja pomiędzy rozmówcami jest szyfrowana). W tym podejściu osoba atakująca może wysłać Ci unikalne łącze do własnego serwera, na którym może zarejestrować Twój adres IP. Twoja aplikacja z radością wygeneruje podgląd linku, nawet jeśli go nie klikniesz – teraz osoba atakująca wie gdzie jesteś oraz może bezpośrednio zaatakować Twój system.
– Łącze może wskazywać na duży plik (video, archiwum zip itd.). Błędnie napisana aplikacja może próbować pobrać (w tle) cały plik, nawet jeśli ma rozmiar gigabajtów, powodując zużycie miejsca, baterii i pakietu danych telefonu.
– Łącze może wskazywać na złośliwy link, który wykorzystuje lukę w procesie generowania poglądu przez (web)aplikację. W zależności od poziomu błędu może dojść do zawieszenia aplikacji lub wykonania dowolnego kodu po jej stronie.

Podejście 3: Serwer pośredni generuje podgląd

Jest to kompromis dla pierwszego i drugiego podejścia. Kiedy wysyłamy odnośnik w wiadomości, aplikacja komunikuje się najpierw z zewnętrznym serwerem i prosi go o wygenerowanie podglądu. Następnie serwer odsyła pogląd z powrotem zarówno do nadawcy, jak i odbiorcy.

Zagrożenia:

– Załóżmy, że chcemy wysłać komuś prywatny link do wrażliwych danych i nie chcemy, aby ktokolwiek inny widział, co zawiera. W tym podejściu serwer będzie musiał wykonać kopię (całą lub częściową) tego, co znajduje się na końcu linku, aby wygenerować podgląd. Czy posiadamy świadomość i informację tego jak długo serwer pośredni przechowuję tę kopię? Czy nie przetwarza tych danych w innych celach? Co, jeśli zaliczy wyciek? To podejście nie powinno być stosowane w aplikacjach, które używają szyfrowania komunikacji, ponieważ żaden serwer pomiędzy nadawcą, a odbiorcą nie powinien być w stanie zobaczyć, co jest przesyłane pomiędzy nimi.

Wspólne zagrożenie dla 1,2,3:

Większość dzisiejszych witryn internetowych zawiera kod JavaScript, aby uczynić je bardziej interaktywnymi (czasami też w celu wyświetlania reklam lub śledzenia Cię). Podczas generowania podglądu linków, bez względu na to, które z powyższych podejść zostanie zastosowane – aplikacja lub serwer odwiedzający stronę nie powinen uruchamiać jakiegokolwiek kodu z tych witryn. Ponieważ jako twórca takiego rozwiązania nie możesz ufać kodowi, który można znaleźć we wszystkich losowych linkach, jakie pojawią się w komunikacji. Nawet te zaufane mogą zostać skompromitowane i podmienione na złośliwe.

Więcej informacji: Link Previews: How a Simple Feature Can Have Privacy and Security Risks