WebSockets - bezpieczeństwo

Protokół powinien być zaprojektowany ze względów bezpieczeństwa. WebSocket to zupełnie nowy protokół i nie wszystkie przeglądarki internetowe implementują go poprawnie. Na przykład niektóre z nich nadal pozwalają na mieszanie HTTP i WS, chociaż specyfikacja sugeruje coś przeciwnego. W tym rozdziale omówimy kilka typowych ataków bezpieczeństwa, o których użytkownik powinien wiedzieć.

Odmowa usługi

Ataki typu „odmowa usługi” (DoS) mają na celu uniemożliwienie dostępu do komputera lub zasobu sieciowego użytkownikom, którzy o to proszą. Załóżmy, że ktoś wysyła nieskończoną liczbę żądań do serwera WWW bez żadnych lub w niewielkich odstępach czasu. Serwer nie jest w stanie obsłużyć każdego połączenia i albo przestanie odpowiadać, albo będzie odpowiadał zbyt wolno. Można to określić jako atak typu „odmowa usługi”.

Odmowa usługi jest bardzo frustrująca dla użytkowników końcowych, którzy nie mogli nawet załadować strony internetowej.

Atak DoS może nawet dotyczyć komunikacji peer-to-peer, zmuszając klientów sieci P2P do jednoczesnego łączenia się z serwerem internetowym ofiary.

Człowiek w środku

Zrozummy to na przykładzie.

Przypuśćmy osobę A rozmawia ze swoim przyjacielem Bza pośrednictwem komunikatora internetowego. Jakaś trzecia osoba chce przejrzeć wymieniane wiadomości. Więc tworzy niezależne powiązania z obiema osobami. Wysyła również wiadomości do osobyA i jego przyjaciel B, jako niewidzialny pośrednik w komunikacji. Jest to znane jako atak typu man-in-the-middle.

Atak typu man-in-the-middle jest łatwiejszy w przypadku połączeń niezaszyfrowanych, ponieważ intruz może bezpośrednio odczytać pakiety. Gdy połączenie jest szyfrowane, osoba atakująca musi odszyfrować informacje, co może być zbyt trudne.

Z technicznego punktu widzenia atakujący przechwytuje wymianę wiadomości z kluczem publicznym i wysyła wiadomość, zastępując żądany klucz własnym. Oczywiście solidną strategią utrudniającą pracę napastnika jest użycie SSH z WebSockets.

Przede wszystkim przy wymianie krytycznych danych preferuj bezpieczne połączenie WSS zamiast niezaszyfrowanego WS.

XSS

Cross-site scripting (XSS) to luka w zabezpieczeniach, która umożliwia atakującym wstrzykiwanie skryptów po stronie klienta do stron internetowych lub aplikacji. Osoba atakująca może wysłać kod HTML lub Javascript za pomocą centrów aplikacji i pozwolić na wykonanie tego kodu na komputerach klientów.

Natywne mechanizmy obronne WebSocket

Domyślnie protokół WebSocket jest zaprojektowany jako bezpieczny. W prawdziwym świecie użytkownik może napotkać różne problemy, które mogą wystąpić z powodu złej implementacji przeglądarki. W miarę upływu czasu dostawcy przeglądarek natychmiast naprawiają wszelkie problemy.

Dodatkowa warstwa zabezpieczeń jest dodawana, gdy używane jest bezpieczne połączenie WebSocket przez SSH (lub TLS).

W świecie WebSocket głównym problemem jest wydajność bezpiecznego połączenia. Chociaż na wierzchu nadal znajduje się dodatkowa warstwa TLS, sam protokół zawiera optymalizacje do tego rodzaju zastosowań, a ponadto WSS działa bardziej elegancko dzięki serwerom proxy.

Maskowanie klient-serwer

Każda wiadomość przesyłana między serwerem WebSocket a klientem WebSocket zawiera określony klucz, nazwany kluczem maskującym, który umożliwia wszystkim pośrednikom zgodnym z protokołem WebSocket zdemaskowanie i sprawdzenie wiadomości. Jeśli pośrednik nie jest zgodny z protokołem WebSocket, nie ma to wpływu na wiadomość. Przeglądarka, która implementuje protokół WebSocket, obsługuje maskowanie.

Zestaw narzędzi bezpieczeństwa

Wreszcie, można przedstawić przydatne narzędzia do badania przepływu informacji między klientami WebSocket a serwerem, analizowania wymienianych danych i identyfikowania możliwych zagrożeń.

Narzędzia dla programistów przeglądarek

Chrome, Firefox i Opera to świetne przeglądarki pod względem wsparcia programistów. Ich wbudowane narzędzia pomagają nam określić prawie każdy aspekt interakcji i zasobów po stronie klienta. Odgrywa wielką rolę ze względów bezpieczeństwa.