Otel Rezervasyon Pentesti: Web, API ve İş Mantığı Testleri

Rezervasyon sitesinin çalışması, işlemlerin güvenli olduğu anlamına gelmez. Yetki, fiyat, iptal, ödeme bildirimi ve PMS tutarlılığını sınayan otel pentest rehberi.

Hızlı Cevap

Hızlı cevap: Otel rezervasyon pentesti, web sitesi ve API üzerinden yürüyen rezervasyon işlemlerinin doğru kullanıcı, fiyat, tesis ve ödeme durumuyla tamamlanıp tamamlanmadığını sınar. Değerlendirme; hesap yetkilerini, rezervasyon değişikliklerini, iptal ve iadeyi, entegrasyon bildirimlerini ve PMS ile veri tutarlılığını kapsamalıdır. Testler sentetik misafirler ve kontrollü rezervasyonlarla yapılmalı; her senaryo için beklenen sonuç ve düzeltme sonrası kabul ölçütü belirlenmelidir.

Bir rezervasyon ekranı kusursuz görünebilir. Tarih seçilir, oda bulunur, ödeme sayfasına geçilir ve onay epostası gelir. Fakat kullanıcıya gösterilen akış, sistemin yalnızca beklenen kullanım biçimidir. Pentest, bu akışın arkasındaki kararları inceler: Oda fiyatına hangi sistem karar veriyor? Rezervasyonu değiştirme yetkisi nasıl doğrulanıyor? Ödeme tamamlanmadan konaklama kaydı kesinleşebiliyor mu?

Otel açısından değerli soru, sitenin açılıp açılmadığından daha derindir. Satış, misafir hizmeti ve finans aynı rezervasyonun durumunu aynı şekilde görüyor mu? Bu yazı, mevcut otel rezervasyon ve kanal yöneticisi güvenliği rehberini test senaryoları ve kabul ölçütleriyle tamamlar. Aşağıdaki örnekler eğitim amaçlıdır; belirli bir otelde veya ürünün belirli sürümünde açık bulunduğu iddiası taşımaz.

Önce rezervasyonun yaşam döngüsünü çizin

Rezervasyon tek bir veritabanı satırından ibaret değildir. Arama, fiyat teklifi, geçici oda ayırma, ödeme, onay, değişiklik, iptal ve iade farklı sistemlerde yürüyebilir. Bu adımların hangi sırayla gerçekleştiği ve hangi koşulda geri alınabildiği testin temelidir.

Bir rezervasyon için örnek durumlar “taslak”, “ödeme bekliyor”, “onaylandı”, “iptal edildi” ve “iade tamamlandı” olabilir. Bunlar bütün otellerin kullanması gereken sabit durum adları değildir. Amaç, tesisteki gerçek akışın çizilmesi ve her geçişi kimin onayladığının bilinmesidir.

İş sahibi, iptal edilmiş bir kaydın tekrar onaylanmasına hangi koşulda izin verildiğini açıklayamıyorsa test uzmanı da doğru davranışı varsayamaz. Kapsam toplantısına yalnızca yazılım ekibinin değil, rezervasyon ve finans sorumlularının katılması bu nedenle önemlidir. Otomatik tarama teknik kusurları işaret edebilir; işletmenin hangi fiyat ve iptal kuralını kabul ettiğini kendiliğinden bilemez.

Web sitesi, rezervasyon motoru ve PMS sınırı

Otelin tanıtım sitesi kendi alan adında, rezervasyon motoru başka bir sağlayıcıda, ödeme formu ise üçüncü bir hizmette bulunabilir. Bu yapıdaki güvenlik değerlendirmesi, sistemlerin sahipliğini ve aralarındaki veri akışını göstermelidir. Sağlayıcının kendi altyapısı için izin verilmemiş testler, otelin marka sahibi olmasıyla kendiliğinden kapsam içine girmez.

İlk çıktı bir bağlantı haritasıdır: tarayıcı, rezervasyon API'si, kanal yöneticisi, ödeme hizmeti, PMS ve bildirim sistemi. Her bağlantı için hangi bilgi taşındığı, hangi kimlikle işlem yapıldığı ve hata durumunda ne olduğu kaydedilir. Kişisel verinin nerede tutulduğu kadar, rezervasyon kararının hangi noktada kesinleştiği de önem taşır.

PMS tarafındaki görev ayrımı, otel PMS ve misafir verisi güvenliği yazısıyla birlikte değerlendirilebilir. Bu makalenin konusu ise satıştan kayda uzanan yol üzerinde güvenlik varsayımlarının ölçülmesidir.

Yetki testinde üç ayrı sınır aranır

Misafirler arasındaki sınır

İki sentetik misafir hesabı oluşturulur ve her biri için ayrı rezervasyon kaydı hazırlanır. Beklenen kural açıktır: misafir yalnızca kendi yetkili işlemlerini yapabilmelidir. Rezervasyon ayrıntısı, fatura, belge indirme ve değişiklik ekranları aynı kayıt için ayrı ayrı değerlendirilir.

Rastgele görünen rezervasyon numarası güvenlik kontrolünün yerine geçmez. Asıl soru, sunucunun her işlemde erişim hakkını doğrulayıp doğrulamadığıdır. OWASP API1:2023, nesne düzeyindeki yetkilendirme sorununu bu çerçevede tanımlar. Otelde test nesnesi bir rezervasyon veya fatura olabilir; değerlendirme gerçek misafir verisini toplamayı gerektirmez.

Personel rolleri arasındaki sınır

Rezervasyon görevlisi oda tarihini değiştirebilir, fakat her işletmede finansal iade yetkisi taşıması beklenmez. Teknik destek hesabının misafir pasaportlarına erişmesi de iş ihtiyacıyla ayrıca gerekçelendirilmelidir. Test, kullanıcı arayüzündeki menülerle sınırlanırsa arka plandaki yetki kusurları gözden kaçabilir.

Tesisler arasındaki sınır

Bir otel grubunda A tesisinin hesabı, B tesisinin rezervasyonunu veya fiyat planını görmemelidir; merkez kullanıcıları için tanımlanmış istisnalar ayrı tutulur. Burada yalnızca kullanıcı kimliği değil, tesis bağlamı da kontrol edilir. Merkezi rapor ekranındaki meşru toplu erişim, şube personeline aynı yetkinin verilebileceği anlamına gelmez.

Fiyat ve kampanya güvenliği nasıl değerlendirilir?

Bir oda fiyatının oluşumunda tarih, kişi sayısı, para birimi, yemek planı, kampanya, kurumsal anlaşma ve iptal koşulu bulunabilir. Test planı bunların tamamını rastgele zorlamak yerine, işletmenin geçerli ve geçersiz kabul ettiği durumları örneklemelidir.

Örneğin bir kurumsal fiyat yalnızca ilgili şirket hesabıyla kullanılabiliyorsa, başka bir test hesabında uygulanmaması beklenir. Süresi bitmiş kampanyanın eski bir bağlantıdan sürdürülmesi veya farklı para birimindeki teklifin yanlış toplamla kesinleşmesi de ayrı senaryolardır. Beklenen sonuç, rezervasyon ekibi tarafından onaylanmalıdır; daha düşük fiyat görmek tek başına güvenlik açığını kanıtlamaz.

Senaryo	Beklenen güvenlik davranışı	Kontrollü kanıt
Başka misafirin rezervasyonu	Erişim ve değişiklik reddedilir	İki sentetik hesapla sonuç kaydı
Yetkisiz kurumsal fiyat	Fiyat planı uygun hesapla sınırlandırılır	Test teklifleri ve hesap rolleri
İptalden sonra geç gelen bildirim	İş kuralına aykırı yeniden onay oluşmaz	Olay zamanı ve durum geçmişi
Tekrarlanan ödeme bildirimi	Aynı işlem ikinci kez uygulanmaz	Sağlayıcının test ortamındaki kayıtlar
Başka tesisin raporu	Şube yetkisi tesis sınırını aşmaz	Kontrollü tesis hesabıyla deneme
Süresi dolmuş değişiklik bağlantısı	Bağlantı öngörülen süre sonunda reddedilir	Test kaydı ve süre bilgisi

Fiyat, sahiplik ve işlem sırası gibi güvenlik açısından belirleyici kararların sunucuda doğrulanması, OWASP iş mantığı güvenliği rehberinin temel yaklaşımıyla uyumludur. Buradaki otel tablosu bu ilkenin örnek bir uygulamasıdır.

Ödeme bildirimi ile rezervasyon onayı aynı şey değildir

Tarayıcının “ödeme başarılı” sayfasına gelmesi, finansal işlemin güvenilir biçimde doğrulandığını tek başına göstermez. Otelin hangi kaynaktan ödeme durumunu aldığı, bildirimi nasıl doğruladığı ve bunu doğru rezervasyona nasıl bağladığı incelenmelidir.

Bu değerlendirme sağlayıcının test ortamı, test işlem kimlikleri ve dokümante edilmiş entegrasyon davranışıyla yapılır. Aynı olayın tekrar gelmesi, bildirimlerin farklı sırada ulaşması veya bir işlemin zaman aşımına uğraması gibi durumlar planlanır. Amaç, gerçek kartlarla deneme yapıp finansal karmaşa yaratmak değil, kayıtlar arasındaki tutarlılığı ölçmektir.

Örnek bir hata düşünelim: misafir rezervasyonunu iptal eder, fakat gecikmiş bir ödeme bildirimi daha sonra ulaşır. Sistemin rezervasyonu yeniden açıp açmayacağı açık bir iş kuralıyla belirlenmelidir. Ödeme, iptal ve oda stoğu arasındaki ilişki bilinmiyorsa yalnızca entegrasyon imzasını kontrol etmek yeterli olmaz. Ödeme alanının ayrıntıları otel POS ve ödeme pentesti yazısında ele alınır.

Oda stoğu ve eş zamanlı işlemler

Otel sistemlerinde aynı son oda için birden fazla işlem yürüyebilir. Eş zamanlılık değerlendirmesi, sınırsız istek göndermek anlamına gelmez. Test ortamında veya otelin ayırdığı kontrollü envanterde, önceden kararlaştırılmış az sayıda işlemle sonuçların tutarlılığı gözlenebilir.

Test öncesinde geçici oda tutma süresi, rezervasyon kesinleşme anı ve başarısız ödeme sonrasında stoğun serbest kalması tanımlanır. Başarısız akışın oda satışını gereksiz yere engellemesi de iş etkisidir. Ancak bunun normal satış yoğunluğunda olup olmayacağı, ayrıca performans ve kapasite değerlendirmesi gerektirebilir; sınırlı bir pentest gözlemi bütün kapasiteyi ölçmez.

Güvenlik ve yük testinin amacı farklıdır. İkisi aynı projede yer alabilir, fakat yöntem, izin ve başarı ölçütleri ayrı yazılmalıdır. Bir güvenlik testini farkında olmadan kapasite testine dönüştürmek, otelin hangi sonuca dayanarak karar vereceğini belirsizleştirir.

İptal, iade ve belge indirme akışları unutulmamalı

Rezervasyon onaylandıktan sonra güvenlik işi bitmez. Misafir tarih değiştirebilir, konuk ekleyebilir, fatura isteyebilir veya rezervasyonu iptal edebilir. Bu işlemler mobil görünümde, eposta bağlantısında ve personel panelinde farklı yollarla sunulabilir.

Her yol için aynı yetki ve iş kuralı beklenir. Eposta bağlantısında hassas veri bulunup bulunmadığı, bağlantının süresi ve yeniden kullanılabilirliği değerlendirilir. Fatura belgesine erişim, rezervasyon ekranından bağımsız olarak kontrol edilir. Bir panelde düzeltilen kusurun başka indirme yolunda sürmesi, kapsamın yeterince geniş tutulmadığını gösterir.

İade konusunda finans ekibinin rolü kritiktir. Kimin hangi işlemi başlatabildiği, kimin onayladığı ve tutarın hangi kaynaktan hesaplandığı belirlenmeden anlamlı bir test yapılamaz. Gerçek iade yerine ödeme sağlayıcısının test imkânları ve sentetik kayıtlar tercih edilir.

Raporun kullanılabilir olması için ne istenmeli?

Rapor, ekran görüntülerinin arkasındaki iş kuralını açıklamalıdır. “Yetki kontrolü eksik” başlığına şu bilgiler eşlik etmelidir: beklenen rol, etkilenen kayıt türü, gözlenen davranış, kanıt sınırı ve düzeltmenin hangi katmanda gerektiği. Aynı kusurun birden fazla ekranda görülmesi, ortak bir yetkilendirme bileşenine işaret edebilir; bu bağ teknik ekipçe doğrulanmalıdır.

Teslimatta başarılı kontroller ve kapsam dışında kalan akışlar da görünür olmalıdır. On senaryodan üçü sağlayıcı izni olmadığı için yapılamadıysa, sonuç “yedi kontrolde sorun görülmedi, üç kontrol yapılmadı” şeklinde anlatılmalıdır. Bu ayrım yönetimin kalan riski anlamasını sağlar.

Düzeltme sonrası tekrar değerlendirme, normal müşterinin rezervasyon yapabildiğini de kapsamalıdır. Güvenliği artıran bir değişiklik meşru iptali veya geçerli kurumsal fiyatı bozmuş olabilir. Güvenlik kabulü ile iş kabulü birlikte tamamlanır. Genel kapsamı kurmak için otellerde pentest rehberine başvurulabilir.

KAOS ve DSET yaklaşımı

DSET ile planlanacak rezervasyon değerlendirmesinde KAOS destekli teknik analiz, işletmenin tanımladığı kurallarla birlikte ele alınmalıdır. Araçların gösterebildiği yüzey, hangi misafirin hangi işlemi yapması gerektiğini tek başına açıklamaz. Rezervasyon, finans ve yazılım ekiplerinin aynı test matrisi üzerinde uzlaşması, sonuçların düzeltmeye dönüşmesini kolaylaştırır.

Proje başlangıcında örnek rezervasyonlar, rol listesi ve entegrasyon sınırlarının hazır olması önemlidir. Böylece çalışma, yalnızca web güvenlik başlıkları sıralayan bir raporla kalmaz; otelin satış ve hizmet süreçlerindeki güvenlik kararlarını görünür kılar.

Sık Sorulan Sorular

Hazır rezervasyon motoru kullanmak pentest ihtiyacını kaldırır mı?

Hazır bir ürün, otelin entegrasyonlarının ve rol ayarlarının otomatik olarak doğru olduğu anlamına gelmez. Otelin kontrolündeki alanlar değerlendirilir; sağlayıcı altyapısı için gerekli izin ve test koşulları ayrıca belirlenir. İnceleme, sağlayıcının geçmiş raporlarıyla tamamlanabilir ancak bunların kapsamı ve tarihi kontrol edilmelidir.

WAF varsa rezervasyon iş mantığı korunmuş olur mu?

WAF bazı saldırı türlerinin tespitine ve engellenmesine katkı sağlar. Bir misafirin belirli bir rezervasyonu değiştirmeye yetkili olup olmadığı veya bir indirimin hangi hesaba ait olduğu gibi kararlar uygulamanın iş kurallarına bağlıdır. Bu nedenle WAF varlığı, yetki ve iş mantığı testlerinin yerine geçmez.

Test sırasında gerçek rezervasyonlar kullanılmalı mı?

Öncelik sentetik misafirler, test hesapları ve kontrollü rezervasyonlardır. Üretim davranışının doğrulanması gerekiyorsa kayıtlar ve işlemler otel tarafından açıkça belirlenir. Gerçek kişisel veriyi toplamak veya gerçek tahsilat oluşturmak, kanıt üretmenin varsayılan yöntemi değildir.

Kaynaklar

Rezervasyon akışlarınızı Ankara Hacettepe Teknokent merkezli DSET ile değerlendirmek ve test kapsamını netleştirmek için DSET ile iletişime geçin.