[KacperSzurek]

Dzisiaj w #od0dopentestera o ataku: Cross-Site Websocket Hijacking na przykładzie #java
Dawniej, aby na stronie treści pojawiały się w czasie rzeczywistym należało z poziomu #javascript co kilka sekund wysyłać żądanie do serwera.
Teraz do tego celu wykorzystuje się websockety.

@ServerEndpoint(value="/endpoint")
public class socketer {
 @OnMessage
 public void onMessage(String message, Session session) {
 session.getBasicRemote().sendText("tajny socket:"+message);
 }
}

Jeżeli coś pojawi się na websockecie - odsyłam tą treść do użytkownika dodając do niej tekst.
Równocześnie mamy stronę, która próbuje się połączyć z endpointem.

var w = new WebSocket('ws://dobradomena.local/endpoint');
w.onmmessage = function(e) {
 alert(e.data);
};
w.onopen = function(e) {
 w.send('Hej!');
};

Jak działa taka komunikacja?

Nasza strona wysyła żądanie HTTP, w którym informuje, że chce przejść na websockety.
W odpowiedzi, serwer zwraca kod 101 i od tego momentu komunikacja odbywa się na podstawie ramek.

Gdzie jest błąd?

Aby uprościć przykład - nie jest w nim widoczna żadna metoda autoryzacji.
Załóżmy więc, że aby połączyć się z endpointem użytkownik musi posiadać prawidłowe ciasteczko.

Skopiujmy teraz nasz kod i umieśćmy go na innej domenie.
Tam również będzie działał prawidłowo. Dlaczego?

W kodzie #js odnosimy się do dobrejdomeny.
Podczas inicjalizacji połączenia z websocketem najpierw wysyłane jest żądanie HTTP.
Przeglądarka widząc więc dobradomena.local dołączyła do niej pasujące ciasteczko.
Serwer sprawdził ciasteczko i zwrócił odpowiedni socket.
Tym samym zła domena może odczytywać oraz zapisywać do niego dowolne dane.

Atakujący nie musiał posiadać hasła użytkownika.
Wystarczy, że atakowana osoba była wcześniej zalogowana.

Jak zatem uchronić się przed tym atakiem?

Przeglądarka do żądań dodaje również nagłówek origin, w którym zawiera nazwę domeny, od której pochodzi dane zapytanie.
Możemy zatem sprawdzać jego treść po stronie serwera - i weryfikować czy żądanie pochodzi z naszej witryny.
Wtedy - nawet jeżeli ciasteczko jest prawidłowe - a żądanie pochodzi z obcej domeny - będziemy je w stanie rozpoznać.

Jeżeli chcesz być wołany dodaj się do Mirkolisty.
Masz pytanie na temat bezpieczeństwa? Zadaj je na grupie od 0 do pentestera na Facebooku.

Ps. Zapraszam do obserwowania tagu autorskiego #od0dopentestera

#security #bezpieczenstwo #programowanie #informatyka #it #nauka #technologia #ciekawostki #hacking #gruparatowaniapoziomu

[KacperSzurek]

Wołam zainteresowanych (27) z listy od0dopentestera
Możesz zapisać/wypisać się klikając na nazwę listy.

Sponsor: Grupa Facebookowa z promocjami z chińskich sklepów

Masz problem z działaniem listy? A może pytanie? Pisz do IrvinTalvanen

! @KacperSzurek @Mashe @UrimTumim @porque @NERP @Smevios @Jakplus @Pioneer95 @ThatPart @szczeppan @Zielarz25 @press2210 @Dorrek @hiroszi @jerekp @Dyktus @bovver91 @Campell @ghostd @heow @Bakanany @znow_nowy_nick @arais_siara @Pies_Benek @HeinzDundersztyc @johnyboy @MojeTrzecieKonto

[Koryntiusz]

Wtedy - nawet jeżeli ciasteczko jest prawidłowe - a żądanie pochodzi z obcej domeny - będziemy je w stanie rozpoznać.

@KacperSzurek: Co z żadaniami nie wysłanymi z przeglądarki ale z programu gdzie możemy spreparować header origin?

[KacperSzurek]

@Koryntiusz: Wtedy ten atak nie jest istotny ponieważ oprócz spreparowania nagłówka origin musisz też znać prawidłowe ciasteczko. A skąd weźmiesz dobre ciasteczko zalogowanego użytkownika?

Tutaj chodzi o to, że jeżeli jesteś zalogowany na serwisie A i ktoś przekona Cię do przejścia na serwis B – to wtedy atakujący może połączyć się z serwisem A jako Ty – nie znając Twojego loginu, hasła oraz ciasteczka. Wystarczy tylko że klikniesz w link do

[billy0o]

@KacperSzurek: przeciez to zwykly atak XSS co ma do tego websocket?

[KacperSzurek]

@billy0o: To nie jest atak XSS - zaważ, że nigdzie nie podaje żadnego payloadu, który w jakikolwiek sposób kradł by cokolwiek od użytkownika.

[aka-mikado]

@billy0o: dokladnie, co ma do tego xss? to wlasnie wykorzystanie cechy websocketu...