Trumpai: Jei jūsų viešbučio svetainė nulaužta, kalbama mažiau apie pradžios puslapį, o daugiau apie viską, kas prie jos prijungta: įterptą rezervacijos sistemą, dovanų kuponų parduotuvę, užklausų formas šventėms ir konferencijoms. Patikrinkite pataisų būseną ir įterpimus, išsaugokite žurnalus ir dalykiškai įspėkite svečius, jei jų duomenys galėjo būti paveikti.
Kokios PHP sistemos veikia viešbučiuose ir maitinime
Viešbučio ar restorano svetainė dažniausiai veikia ant WordPress ar kito PHP CMS. Rezervacijos sistema dažnai yra viešbučio programinės įrangos ar kanalų valdytojo (channel manager) teikėjo ir įterpiama per skriptą ar iframe. Greta nuosavame serveryje dažnai veikia dovanų kuponų parduotuvė ant WooCommerce, formos konferencijų ir vestuvių užklausoms, staliukų rezervacijos, naujienlaiškių prenumeratos ir sezoniniai darbo skelbimai.
Būtent nuosavų ir svetimų dalių mišinys daro svetingumo sektorių pažeidžiamą: nuosavame serveryje nebūtina būti rezervacijos duomenims, kad būtų pavojingas svečiams. Pakanka, kad jis nustato, kur veda mygtukas „Rezervuoti“.
Kokie svečių duomenys pastatyti ant kortos
Per viešbučių svetaines keliauja vardai, adresai, telefono numeriai, kelionės datos ir palydovai. Užklausose dažnai yra specialių pageidavimų, tokių kaip alergijos, prieinamumas neįgaliesiems ar mitybos reikalavimai. Tokia sveikatos informacija priklauso specialioms kategorijoms pagal BDAR 9 straipsnį. Dovanų kuponų parduotuvėje prisideda užsakymo ir sąskaitų duomenys.
Kortelių duomenys paprastai yra pas mokėjimo paslaugų teikėją ar viešbučio programinėje įrangoje, o ne svetainėje. Tačiau kas gali pakeisti JavaScript savo puslapyje, gali ir skaityti įvestis formose arba nusiųsti svečius į apgaulingai tikrą mokėjimo puslapį.
Konferencijų ir renginių užklausos dažnai ateina iš įmonių ir turi dalyvių sąrašus, eigos planus bei biudžetus. Vestuvių užklausose nurodomos datos, svečių skaičius ir šeimų pavardės. Tokia informacija retai suvokiama kaip jautri, bet vertinga tiksliniams sukčiavimo bandymams, pavyzdžiui, suklastotai avanso sąskaitai prieš pat renginį. Todėl patikrinkite, ar užklausos nuolat guli svetainės duomenų bazėje ir ar to reikia.
Viešbučio svetainė nulaužta: tipinės pasekmės įmonei
- Suklastoti rezervacijos ir mokėjimo puslapiai: Svečiai moka sukčiams ir kaltina viešbutį.
- Tikslinės sukčiavimo žinutės: Su tikrais kelionės duomenimis suklastoti mokėjimo reikalavimai atrodo patikimi.
- Tiesioginių rezervacijų praradimas: Google įspėjimas ar gedimas nustumia svečius į rezervavimo portalus, kuriems mokate komisinį.
- Vertinimai: Apgauti svečiai tai aprašo viešai, nepriklausomai nuo to, kur buvo klaida.
Po pataisos patikrinkite ir tai, ar jūsų rezervacijos sistemos įterpimas vis dar rodo į teisingą adresą. Pakeistas skriptas ar nukreipta nuoroda kasdienybėje beveik nepastebimi.
Kas atsakingas: agentūra, programinės įrangos teikėjas, hostingo teikėjas?
| Dalis | Paprastai atsakingas | Atviras klausimas |
|---|---|---|
| Viešbučio svetainė ir dovanų kuponų parduotuvė | Agentūra ir hostingo teikėjas | PHP pataisa ir paleidimas iš naujo patvirtinti? |
| Rezervacijos sistema | Viešbučio programinės įrangos teikėjas | Ar įterpimas nepakeistas? |
| Viešbučio programinė įranga patalpose | Programinės įrangos teikėjas arba IT prižiūrėtojas | Ryšiai su svetaine? |
| Registratūros pašto dėžutės | Hostingo teikėjas arba IT prižiūrėtojas | Nežinomi peradresavimai? |
Viešbučių grupėse ir franšizės įmonėse prisideda centriniai nurodymai. Dažnai pagrindinį puslapį eksploatuoja centras, o atskiri viešbučiai išlaiko savo dovanų kuponų ar renginių puslapius, kurių niekas centralizuotai nemato.
Sezoniniai darbuotojai, bendros prieigos ir dovanų kuponai
Svetingumo sektoriuje komandos dažnai keičiasi. Prieigos prie svetainės, dovanų kuponų parduotuvės ir rezervavimo platformų dalijamos registratūroje ir retai keičiamos, kai kas nors išeina. Po incidento visos šios prieigos turėtų būti atnaujintos ir, kur įmanoma, perkeltos į asmenines paskyras.
Nepakankamai įvertinta rizika yra dovanų kuponai. Kas turi prieigą prie parduotuvės duomenų bazės, gali nuskaityti kuponų kodus, keisti vertes ar kurti savo kodus, kurie išperkami registratūroje. Po išvalymo leiskite patikrinti, ar nebuvo sukurta ar pakeista kuponų, kurių negalima priskirti jokiam užsakymui. Palyginimas su jūsų buhalterija tokius nukrypimus paprastai parodo greitai.
Pirmosios valandos po įspėjimo
- Iš hostingo teikėjo raštu gauti patvirtinimą, kad PHP yra 8.5.12, 8.4.27, 8.3.36 ar 8.2.35 arba pataisytas, ir kad visi procesai paleisti iš naujo.
- Be patvirtinimo: pakeisti svetainę informaciniu puslapiu su telefonu ir tiesiogine nuoroda į teikėjo rezervacijos sistemą.
- Išsaugoti žurnalus nuo 2026-10-20 ir patikrinti rezervacijos sistemos bei mokėjimo puslapių įterpimus.
- Informuoti registratūros komandą, kad atpažintų ir dokumentuotų įtartinus svečių pasiteiravimus.
- Esant sukčiavimo požymių, dalykiškai įspėti svečius. Formuluočių pagalbą siūlo puslapis apie krizių komunikaciją.
Kaip konkrečiai padeda PHP SOS?
- Tikriname jūsų žiniatinklio serverio pataisų būseną, paleidimą iš naujo ir veikimo režimą bei derinamės su agentūra ir hostingo teikėju.
- Kontroliuojame svetainę, dovanų kuponų parduotuvę ir įterpimus dėl pakeisto JavaScript, svetimų nukreipimų ir webshell bei pašaliname kenkėjišką kodą.
- Tikriname, ar pašto dėžutės negavo peradresavimo taisyklių, kurių nežinote.
- Po to pageidaujant įrengiame saugumo stebėseną, kuri praneša apie failų ir skriptų pakeitimus.
Dažni klausimai
Ar mano rezervacijos sistemą veikia PHP2Shell?
Daug rezervacijos sistemų eksploatuoja teikėjas ir tik įterpia į viešbučio svetainę. Tuomet už savo serverį atsako teikėjas. Jūsų pačių svetainė vis tiek išlieka rizika, nes užpuolikas ten gali pakeisti įterpimą arba nukreipti į suklastotą rezervacijos puslapį.
Svečiai gavo keistų mokėjimo reikalavimų. Ar tai susiję su svetaine?
Įmanoma, bet įrodyti galima tik po patikros. Tokios žinutės gali atsirasti ir per rezervavimo platformas ar pažeistas pašto dėžutes. Išsaugokite žinutes, įspėkite paveiktus svečius ir leiskite patikrinti svetainę, pašto dėžutes ir platformų prieigas.
Ar galiu išjungti svetainę pagrindinio sezono metu?
Jei PHP nėra įrodomai pataisytas, BSI (Vokietijos federalinė informacijos saugumo tarnyba) rekomenduoja laikinai atjungti žiniatinklio serverius nuo tinklo. Informacinis puslapis su telefonu ir tiesiogine nuoroda į teikėjo rezervacijos sistemą išlaiko veiklą. Nepastebėtai pažeista svetainė sezono metu kainuoja daugiau pasitikėjimo nei kelios priežiūros valandos.