Krótko: Jeśli strona Państwa hotelu została zhakowana, chodzi mniej o stronę główną, a bardziej o wszystko, co się z nią wiąże: osadzony silnik rezerwacji, sklep z bonami, formularze zapytań o przyjęcia i konferencje. Proszę sprawdzić stan poprawek i osadzenia, zabezpieczyć logi i rzeczowo ostrzec gości, jeśli ich dane mogły zostać dotknięte.
Jakie systemy PHP działają w hotelach i gastronomii
Strona hotelu lub restauracji działa zwykle na WordPressie lub innym CMS w PHP. Silnik rezerwacji pochodzi często od dostawcy oprogramowania hotelowego lub channel managera i jest osadzany przez skrypt lub iframe. Obok tego na własnym serwerze działają często sklep z bonami oparty na WooCommerce, formularze zapytań o konferencje i wesela, rezerwacje stolików, zapisy na newsletter i oferty pracy sezonowej.
Właśnie mieszanka własnych i obcych elementów czyni hotelarstwo podatnym: własny serwer nie musi zawierać danych rezerwacji, by zagrażać gościom. Wystarczy, że określa, dokąd prowadzi przycisk rezerwacji.
Jakie dane gości są stawką
Przez strony hoteli przechodzą imiona i nazwiska, adresy, numery telefonów, daty podróży i osoby towarzyszące. Zapytania zawierają często szczególne życzenia, takie jak alergie, dostępność dla osób z niepełnosprawnościami lub wymogi dietetyczne. Takie informacje o zdrowiu należą do szczególnych kategorii według art. 9 RODO. W sklepie z bonami dochodzą dane zamówień i rozliczeniowe.
Dane kart znajdują się zwykle u operatora płatności lub w oprogramowaniu hotelowym, a nie na stronie. Kto jednak może zmienić JavaScript na własnej stronie, może także podsłuchiwać dane wpisywane w formularzach lub kierować gości na łudząco prawdziwą stronę płatności.
Zapytania o konferencje i eventy pochodzą często od firm i zawierają listy uczestników, plany przebiegu i budżety. Zapytania weselne podają terminy, liczby gości i nazwiska rodzin. Takie informacje rzadko są postrzegane jako wrażliwe, ale są cenne dla ukierunkowanych prób oszustwa, na przykład sfałszowanej faktury za zaliczkę tuż przed wydarzeniem. Proszę więc sprawdzić, czy zapytania pozostają na stałe w bazie danych strony i czy jest to konieczne.
Strona hotelu zhakowana: typowe skutki dla działalności
- Sfałszowane strony rezerwacji i płatności: Goście płacą oszustom i obarczają odpowiedzialnością hotel.
- Ukierunkowane wiadomości oszukańcze: Z prawdziwymi danymi podróży sfałszowane wezwania do zapłaty wyglądają wiarygodnie.
- Utrata rezerwacji bezpośrednich: Ostrzeżenie Google lub awaria spychają gości do portali rezerwacyjnych, którym płacą Państwo prowizję.
- Opinie: Goście, którzy zostali oszukani, opisują to publicznie, niezależnie od tego, gdzie leżał błąd.
Po poprawce proszę sprawdzić także, czy osadzenie Państwa silnika rezerwacji nadal wskazuje właściwy adres. Zmieniony skrypt lub przekierowany link jest w codziennym użytkowaniu prawie niezauważalny.
Kto odpowiada: agencja, dostawca oprogramowania, firma hostingowa?
| Element | Zwykle odpowiada | Otwarte pytanie |
|---|---|---|
| Strona hotelu i sklep z bonami | Agencja i firma hostingowa | Poprawka PHP i restart potwierdzone? |
| Silnik rezerwacji | Dostawca oprogramowania hotelowego | Czy osadzenie jest niezmienione? |
| Oprogramowanie hotelowe na miejscu | Dostawca oprogramowania lub opiekun IT | Połączenia ze stroną? |
| Skrzynki pocztowe recepcji | Firma hostingowa lub opiekun IT | Nieznane przekierowania? |
W sieciach hotelowych i firmach franczyzowych dochodzą centralne wytyczne. Często centrala prowadzi stronę główną, podczas gdy poszczególne obiekty utrzymują własne strony z bonami lub wydarzeniami, których nikt centralnie nie ma na oku.
Pracownicy sezonowi, współdzielone dostępy i bony
W hotelarstwie zespoły często się zmieniają. Dostępy do strony, sklepu z bonami i platform rezerwacyjnych są współdzielone w recepcji i rzadko zmieniane, gdy ktoś odchodzi. Po incydencie wszystkie te dostępy należy odnowić i tam, gdzie to możliwe, przestawić na konta osobiste.
Niedocenianym ryzykiem są bony. Kto ma dostęp do bazy danych sklepu, może odczytywać kody bonów, zmieniać wartości lub zakładać własne kody, które są realizowane w recepcji. Po oczyszczeniu proszę kazać sprawdzić, czy nie utworzono lub nie zmieniono bonów, których nie można przypisać do żadnego zamówienia. Porównanie z księgowością zwykle szybko pokazuje takie nieprawidłowości.
Pierwsze godziny po ostrzeżeniu
- Kazać firmie hostingowej potwierdzić na piśmie, że PHP ma wersję 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo jest załatane i wszystkie procesy zostały zrestartowane.
- Bez potwierdzenia: zastąpić stronę stroną informacyjną z telefonem i bezpośrednim linkiem do silnika rezerwacji dostawcy.
- Zabezpieczyć logi od 20.10.2026 i sprawdzić osadzenia silnika rezerwacji i stron płatności.
- Poinformować zespół recepcji, aby rozpoznawał podejrzane zapytania gości i je dokumentował.
- Przy wskazówkach na oszustwo rzeczowo ostrzec gości. Pomoc w formułowaniu oferuje strona o komunikacji kryzysowej.
Jak PHP SOS pomaga w praktyce?
- Sprawdzamy stan poprawek, restart i tryb pracy Państwa serwera WWW oraz uzgadniamy działania z agencją i firmą hostingową.
- Kontrolujemy stronę, sklep z bonami i osadzenia pod kątem zmienionego JavaScript, obcych przekierowań i webshelli oraz usuwamy złośliwy kod.
- Sprawdzamy, czy skrzynki pocztowe nie otrzymały reguł przekierowania, których Państwo nie znają.
- Następnie na życzenie wdrażamy monitoring bezpieczeństwa, który zgłasza zmiany w plikach i skryptach.
Częste pytania
Czy mój silnik rezerwacji jest dotknięty przez PHP2Shell?
Wiele silników rezerwacji jest prowadzonych przez dostawcę i tylko osadzonych na stronie hotelu. Wtedy za swój serwer odpowiada dostawca. Państwa własna strona pozostaje mimo to ryzykiem, ponieważ atakujący może tam zmienić osadzenie lub przekierować na sfałszowaną stronę rezerwacji.
Goście dostali dziwne wezwania do zapłaty. Czy ma to związek ze stroną?
Jest to możliwe, ale da się to udowodnić dopiero po kontroli. Takie wiadomości mogą powstawać także przez platformy rezerwacyjne lub skompromitowane skrzynki pocztowe. Proszę zabezpieczyć wiadomości, ostrzec dotkniętych gości i kazać sprawdzić stronę, skrzynki pocztowe i dostępy do platform.
Czy mogę wyłączyć stronę w sezonie wysokim?
Jeśli nie ma dowodu, że PHP jest załatane, BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleca tymczasowe odłączenie serwerów WWW od sieci. Strona informacyjna z telefonem i bezpośrednim linkiem do silnika rezerwacji dostawcy utrzymuje działalność. Niezauważenie skompromitowany serwis kosztuje w sezonie więcej zaufania niż kilka godzin konserwacji.