Podatności OpenReception

W oprogramowaniu OpenReception przed wersją 1.1.1 endpoint POST /api/auth/passkeys przyjmuje userId z treści żądania oraz klucz passkey dostarczony przez atakującego bez uwierzytelnionej sesji, nie wywołuje WebAuthnService.verifyRegistration i nie wiąże rejestracji z locals.user.id. Nieuwierzytelniony atakujący znający publiczny identyfikator tenanta i adres e-mail pracownika może wstrzyknąć kontrolowany klucz publiczny, zidentyfikować pasujący userId i utworzyć sesję STAFF.

Przed wersją 1.0.4 oprogramowania OpenReception do rezerwacji wizyt, nieuwierzytelniony atakujący mógł przechowywać własne klucze publiczne ML-KEM-768 dla dowolnego najemcy, bez logowania. Nawet bez ciasteczka sesji lub rejestracji, żądanie POST do /api/tenants/{tenantId}/staff/{staffId}/crypto zapisywało klucz, a wariant z pominięciem pola email całkowicie ukrywał ostrzeżenie o nieautoryzowanej próbie. To łamie deklarację szyfrowania end-to-end, ponieważ atakujący staje się dodatkowym odbiorcą szyfrowania przyszłych wizyt pacjentów.

Podatność w OpenReception (przed wersją 1.0.2) w rejestracji WebAuthn pozwala nieuwierzytelnionemu atakującemu na przypisanie własnego poświadczenia do konta ofiary poprzez manipulację parametrem userId w URL. Walidacja nie sprawdza, czy userId należy do adresu email z ciasteczka.

Podatność w oprogramowaniu do rezerwacji wizyt OpenReception pozwala administratorowi dzierżawy (TENANT_ADMIN) na awansowanie siebie lub innego pracownika do roli globalnego administratora (GLOBAL_ADMIN) poprzez pojedyncze żądanie PUT. Brakuje kontroli uprawnień, która wymagałaby, aby tylko istniejący GLOBAL_ADMIN mógł nadawać tę rolę. Po ponownym zalogowaniu administrator dzierżawy uzyskuje pełny dostęp do wszystkich innych dzierżaw na platformie.

Oprogramowanie do rezerwacji wizyt OpenReception przed wersją 1.0.1 pozwala nieuwierzytelnionemu atakującemu na utworzenie konta GLOBAL_ADMIN poprzez wysłanie żądania POST do `/setup/create-admin-account`, bez weryfikacji, czy administrator już istnieje. Atakujący może uzyskać pełną kontrolę administracyjną nad platformą, a nowe konto jest aktywne i nie wymaga potwierdzenia e-mail.

OpenReception przed wersją 1.0.2 nie ogranicza liczby nieudanych prób logowania hasłem. Atakujący może wysyłać nieograniczoną liczbę błędnych haseł dla znanego adresu e-mail, z szybkością około 10 prób na sekundę. Brak throttlingu w gałęzi hasła, podczas gdy endpoint WebAuthn ma throttling, umożliwia ataki brute-force i słownikowe na konta użytkowników. Problem naprawiono w wersji 1.0.2.

Oprogramowanie do rezerwacji wizyt OpenReception przed wersją 1.0.2 ma podatność w punkcie końcowym `/api/log`, który akceptuje nieuwierzytelnione żądania POST, nie stosuje walidacji schematu do treści wiadomości, zapisuje treść kontrolowaną przez atakującego bezpośrednio do dziennika stdout aplikacji, interpretuje znaki nowej linii jako rzeczywiste przerwy linii i nie egzekwuje limitów rozmiaru ani szybkości. Istnieją trzy tryby nadużycia: wstrzykiwanie logów (fałszowanie wpisów logów), DoS przez zalanie logów (setki żądań na sekundę) oraz przesyłanie bardzo dużych danych (100 KB). Najbardziej szkodliwy jest wstrzykiwanie logów, umożliwiające atakującemu wstrzyknięcie fałszywych wpisów, które operator może pomylić z prawdziwymi błędami systemowymi, maskując własną aktywność lub zanieczyszczając reguły alertów SIEM. Wersja 1.0.2 naprawia problem.

OpenReception przed wersją 1.0.6 ma zbyt słaby proof-of-work (16 bitów) w endpointcie bootstrap-challenge, co pozwala na łatwe obejście rate-limitu i automatyzację ataków na proces rezerwacji.

Przed wersją 1.0.2 oprogramowania OpenReception do rezerwacji wizyt, administrator dzierżawy (TENANT_ADMIN) może zapisać adresy URL `javascript:` w konfiguracji linków (`website`, `imprint`, `privacyStatement`). Te wartości są zwracane na stronę pacjenta przez `/api/public`, osadzane w komponencie SvelteKit Button i renderowane jako `<a href="javascript:...">` bez filtrowania schematu URL. Kliknięcie takiego linku przez pacjenta powoduje wykonanie skryptu atakującego w przeglądarce pacjenta, gdzie dane formularza są odczytywane przed szyfrowaniem po stronie klienta.

Podatność w OpenReception przed wersją 1.0.2 ujawnia pełny rekord dzierżawcy (tenant) przez endpoint `GET /api/tenants/{id}` każdemu uwierzytelnionemu administratorowi tego dzierżawcy, w tym pole `databaseUrl` zawierające string połączenia z bazą PostgreSQL. W domyślnym wdrożeniu docker-compose string zawiera użytkownika `postgres` z uprawnieniami superusera i hasło w plaintext, co pozwala na pełny dostęp do wszystkich baz danych w instancji PostgreSQL.

Przed wersją 1.0.2 OpenReception, podczas nawigacji do strony `/logout`, handler ładowania po stronie serwera usuwa ciasteczko `access_token` przed wywołaniem `/api/auth/logout` przez wewnętrzny `event.fetch()`. Wewnętrzne żądanie jest wykonywane bez ciasteczka uwierzytelniającego, więc `apiAuthHandle` odrzuca je, handler wylogowania nie wykonuje się, a `SessionService.revokeSession()` nie jest wywoływany dla bieżącej sesji. Sesja w bazie danych pozostaje ważna do naturalnego wygaśnięcia (domyślnie tydzień). Użytkownik widzi poprawne wylogowanie (ciasteczko usunięte, UI wraca do logowania), ale każda strona posiadająca kopię usuniętego tokena może kontynuować uwierzytelnione wywołania API do naturalnego wygaśnięcia sesji.

Przed wersją 1.0.5 nieuwierzytelniony endpoint `/api/tenants/{id}/schedule` zwraca wszystkie niearchiwizowane kanały dla dzierżawcy, ignorując flagę `isPublic`. Kanały oznaczone jako `isPublic = false` są celowo ukrywane przed publicznymi użytkownikami, ale endpoint ujawnia ich nazwy, opisy, identyfikatory, powiązania z agentami, status pauzy, wymagania potwierdzenia oraz dostępność slotów. Wersja 1.0.5 naprawia ten problem.

Przed wersją 1.1.0 handler GET w `/api/tenants/{id}/appointments/{appointmentId}` nie wykonuje żadnej kontroli autoryzacji przed zwróceniem rekordu wizyty. Każda osoba, która zna lub zdobędzie ważny UUID wizyty, otrzymuje pełny rekord, w tym identyfikatory kanału i agenta, czas i strefę czasową, status oraz składniki szyfrogramu AES-GCM (`encryptedPayload`, `iv`, `authTag`, `dataKey`). Wersja 1.1.0 naprawia ten problem.

Podatność w oprogramowaniu do rezerwacji wizyt OpenReception (wersje 1.0.1 i wcześniejsze) pozwala nieuwierzytelnionemu atakującemu na dodanie rezerwacji do prywatnego kanału (gdzie `isPublic = false`). Proces rejestracji nowego klienta nie wiąże tokenu dostępu z `channelId`, a walidacja w `createNewClientWithAppointment` nie sprawdza flagi `channel.isPublic`, co umożliwia obejście zabezpieczeń. Atak wymaga jedynie rozwiązania 16-bitowego proof-of-work (łatwego do wykonania) i znajomości identyfikatora kanału, który można uzyskać z innej podatności (V-10).

Podatność w oprogramowaniu do rezerwacji wizyt OpenReception przed wersją 1.0.5 pozwala nieuwierzytelnionemu atakującemu na dodanie dowolnej rezerwacji do dowolnego tunelu klienta. Endpoint `add-to-tunnel` nie weryfikuje tożsamości wywołującego, a jedynie istnienie tunelu z podanym `emailHash`, co umożliwia wstawienie rezerwacji ze statusem CONFIRMED, kontrolowanymi polami szyfrogramu, datą, czasem trwania i wybranym agentem.

OpenReception przed wersją 1.0.6 ma podatność w usuwaniu pracownika przez TENANT_ADMIN, która usuwa zaproszenia użytkowników w innych tenantach o tym samym adresie email.

Przed wersją 1.0.4 mechanizm ograniczania prób dla wyzwań PIN używa `emailHash` jako jedynego klucza, a tabela `challenge_throttle` jest współdzielona między wszystkimi dzierżawcami. Atakujący, znając adres e-mail pacjenta, może zablokować tego pacjenta w innym dzierżawcy, wysyłając nieudane odpowiedzi na wyzwania w jednym dzierżawcy. Blokada eskaluje z powtarzającymi się niepowodzeniami, prowadząc do długotrwałego ataku DoS. Wersja 1.0.4 naprawia ten problem.