Panel klienta WaveHost

WaveHost to dostawca hostingu, który potrzebował jednego miejsca dla swoich klientów: zamawiasz serwer, płacisz, polecasz dalej, wszystko z tego samego panelu. Sama ta część jest robotą rzemieślniczą, którą robiliśmy już wcześniej. Prawdziwe wyzwanie leżało obok: u dostawcy działał już osobny panel gier z własnymi kontami, i te dwa światy trzeba było spiąć tak, żeby klient poczuł jeden system, a nie dwa.

Najprościej byłoby kazać ludziom logować się dwa razy i ręcznie podpinać konto po mailu. To jednak prosta droga do pomyłek, a przy podpinaniu kont pomyłka ma konkretną cenę: podepniesz komuś cudze konto i masz problem, którego nie da się cofnąć zwykłym przepraszam. Chcieliśmy połączenia, któremu można zaufać. Ten case study jest głównie o tym połączeniu.

Fundament panelu to obsługa, do której klient wraca codziennie. Zamawianie i zarządzanie serwerami obejmuje zarówno VPS-y, jak i maszyny dedykowane, z ich stanem i konfiguracją widocznymi w jednym widoku. Klient nie skacze między narzędziami, żeby sprawdzić, co ma i w jakim jest stanie.

Wokół tego żyje reszta obsługi. Portfel i faktury są obok siebie, więc saldo, płatności i dokumenty tworzą jedną całość, a nie trzy osobne zakładki, które trzeba samemu godzić. Program poleceń dokłada link polecający i przejrzysty przepływ prowizji, wpięty w ten sam portfel. Całość stoi na nowoczesnym stosie z bezpiecznym uwierzytelnianiem, bo to jest panel, w którym leżą pieniądze i dostęp do serwerów.

Sedno projektu to spięcie panelu klienta z istniejącym panelem gier. Z perspektywy klienta problem jest banalny i wkurzający jednocześnie: dwa konta, dwa logowania, dwa światy, które go nie obchodzą, bo on chce po prostu zarządzać wszystkim w jednym miejscu. Z perspektywy inżynierskiej to jest właśnie ta część, w której łatwo zrobić coś niebezpiecznego.

Naiwne rozwiązanie brzmi: niech klient poda swój login z panelu gier, a my go podepniemy. Problem w tym, że w ten sposób każdy mógłby podać cudzy login i podpiąć się pod konto, które do niego nie należy. Ręczne podpinanie po mailu jest wolne i tak samo dziurawe. Potrzebowaliśmy sposobu, w którym to jeden system udowadnia drugiemu tożsamość klienta, bez zaufania do niczego, co przechodzi przez przeglądarkę.

Rozwiązaniem jest handshake oparty na HMAC. Kiedy klient klika "połącz konto" w panelu WaveHost, panel generuje link niosący identyfikator użytkownika, znacznik czasu i podpis policzony sekretem, który znają tylko oba panele. Panel gier odbiera ten link, przelicza podpis własnym sekretem i porównuje. Jeśli się zgadza, wie, że żądanie naprawdę wyszło z panelu WaveHost, a nie od kogoś, kto podrobił adres.

Kluczowe jest to, czego przeglądarka nigdy nie widzi. Sekret nie opuszcza serwerów, więc nawet ktoś, kto podejrzy albo przechwyci link, nie policzy poprawnego podpisu dla cudzego identyfikatora. Znacznik czasu domyka drugą dziurę: link jest krótkotrwały, a przeterminowany token panel gier po prostu odrzuca, więc podsłuchany link nie da się użyć później.

Warto rozłożyć to na scenariusze, bo dopiero wtedy widać, że wygoda naprawdę nie kosztuje bezpieczeństwa. Ktoś podmienia identyfikator w linku na cudzy, żeby podpiąć się pod nie swoje konto. Podpis przestaje pasować, bo policzono go dla innego identyfikatora, a nowego bez sekretu nie da się wygenerować. Panel gier odrzuca żądanie.

Drugi scenariusz: ktoś przechwytuje poprawny link jednego klienta i próbuje go użyć. Tu ratuje znacznik czasu. Link żyje krótko, więc przechwycony po czasie jest już bezwartościowy, a panel gier traktuje przeterminowany token dokładnie tak samo jak podrobiony. W obu przypadkach granica jest sprawdzana po stronie serwera, na wejściu, a nie w interfejsie, który zawsze da się obejść.

Klient prowadzi całą obsługę z jednego miejsca. Zamawia serwery, zarządza VPS-ami i dedykami, płaci, poleca dalej i pilnuje portfela bez skakania między narzędziami. Połączenie z panelem gier działa na jedno kliknięcie zamiast na wymianie maili, więc dwa systemy dostawcy czują się dla klienta jak jeden.

Pod spodem ta wygoda nie jest okupiona bezpieczeństwem, bo handshake jest krótkotrwały i podpisany, a sekret nigdy nie trafia do przeglądarki. Podrobiony albo przechwycony link nie podepnie cudzego konta, bo granicy pilnuje serwer na wejściu, a nie interfejs. To jest dokładnie ten rodzaj rozwiązania, o który chodziło: proste dla klienta, twarde tam, gdzie musi być twarde.