Dziennik bezpieczeństwa.

Wewnętrzny przegląd przed startem programu

15 lipca 2026 roku rozpoczęliśmy wewnętrzny przegląd bezpieczeństwa CreateYourVPN. Poprawki, które ukończyliśmy i ponownie zweryfikowaliśmy, publikujemy poniżej; kolejne będą się pojawiać w miarę ich wdrażania i potwierdzania.

Dodano zabezpieczenie przed niebezpieczną konfiguracją cross-origin

Obecna konfiguracja production nie zezwalała na dowolne origins, jednak kod dopuszczał niebezpieczną kombinację parametrów, gdyby operator błędnie ją skonfigurował. Taka kombinacja jest teraz odrzucana przy starcie i objęta zautomatyzowanym testem.

Zmniejszono publiczną powierzchnię production API

Interaktywna dokumentacja techniczna API była dostępna bez uwierzytelniania. Nie dawała dostępu do chronionych danych, ale ułatwiała badanie wewnętrznej struktury API. W production dokumentacja jest teraz wyłączona, pozostając dostępna w izolowanym środowisku na potrzeby programowania.

Rozdzielono klucze kryptograficzne platformy według przeznaczenia

Wewnętrzny przegląd wykazał, że jeden sekret był używany do dwóch różnych zadań kryptograficznych. Nie tworzyło to bezpośredniego obejścia, ale poszerzało skutki kompromitacji klucza. Oba przeznaczenia zostały rozdzielone i każde jest teraz rotowane niezależnie.

Zagwarantowano czyszczenie klucza zarządzającego po usunięciu serwera

Czyszczenie zaszyfrowanego klucza zarządzającego uruchamiało się po operacjach sieciowych w tle i mogło się nie powtórzyć, jeśli operacje te zawiodły. Oddzieliliśmy czyszczenie klucza od kaskady sieciowej i dodaliśmy gwarantowane ponowienie. Scenariusze niedostępnego serwera i przerwanego procesu są objęte testami.

Usunięto nieużywaną ścieżkę autoryzacji partnerskiego API

API obsługiwało dodatkową ścieżkę autoryzacji opartą na cookie, której obecna architektura server-side nie potrzebowała. W production nie stwierdzono ataku międzywitrynowego, ale dodatkowa ścieżka poszerzała powierzchnię przyszłych błędów. API korzysta teraz z jednej, jawnie zdefiniowanej metody autoryzacji, objętej testami negatywnymi.

Ograniczono dostęp do panelu zarządzania infrastrukturą

Zewnętrzny badacz zgłosił, że interfejs administracyjny do zarządzania infrastrukturą odpowiadał z publicznego internetu. Interfejs był chroniony uwierzytelnianiem, nie znaleziono śladów nieuprawnionego dostępu. Zgłoszenie zostało przyjęte, a dostęp ograniczony.

Interfejs jest teraz dostępny wyłącznie z zatwierdzonych adresów, wymagania uwierzytelniania zostały wzmocnione, a zaangażowane komponenty zaktualizowane. Wynik zweryfikowano spoza naszej sieci. Dodatkowo przejrzeliśmy naszą powierzchnię publiczną i wprowadziliśmy jej regularną kontrolę. Nagrodę wypłacono w najwyższym progu.

Adresy e-mail użytkowników witryn nie są już przechowywane

Osoba wpisuje swój e-mail, aby zalogować się do witryny partnera, ale adres u nas nie zostaje: wiadomość z kodem wychodzi, a adres jest od razu usuwany. Konto rozpoznajemy po nieodwracalnym odcisku, z którego adresu nie da się odtworzyć, a nazwa konta również go nie zawiera.

Użytkownik może samodzielnie zresetować swój link subskrypcji

Link subskrypcji jest sekretem: kto go ma, uzyskuje taki sam dostęp jak jego właściciel. Użytkownik może zresetować go samodzielnie w swoim koncie — poprzedni link przestaje działać, a powiązane dane dostępowe są wydawane na nowo. Tak zamknięty link pozostaje zamknięty, także po przywróceniu danych z kopii zapasowej.

Nagłówki bezpieczeństwa na stronach sklepów

Sklepy partnerów nie wysyłały nagłówków bezpieczeństwa, które panel i API wysyłały już wcześniej — w tym tego, który zabrania obcym witrynom wyświetlania strony w ramce. Tą drogą nie dało się odczytać danych konta ani sesji. Teraz pełny zestaw towarzyszy każdej odpowiedzi sklepu, a twierdzenie SR-15 wymienia każdy hostowany przez nas frontend.

Zarządzanie sesjami i wysyłka kodów logowania

Na podstawie zgłoszeń zewnętrznego badacza przejrzeliśmy dwa sąsiadujące obszary: cykl życia sesji partnera oraz drogę wiadomości z kodem logowania. Żadne ze zgłoszeń nie dawało dostępu do kont, danych partnerów ani ruchu użytkowników.

Zmiany w wysyłce kodów logowania są wdrożone i zweryfikowane. Osobna akcja „wyloguj na wszystkich urządzeniach” jest w przygotowaniu; do jej wydania wylogowanie kończy bieżącą sesję.