Bayinin Panelinden Admin Verisi Çekilebiliyor mu? E-pin Scriptinde Yetki Yükseltme Açıklarını Kendi Ellerinle Test Etmenin Sessiz Yöntemi

Çoğu panel sahibi güvenliği giriş kapısında bitmiş sanır. Şifre güçlü, iki faktör açık, oturum süreli; dolayısıyla içeride her şey yolunda kabul edilir. Oysa sahada gördüğümüz en pahalı açıklar kapıda değil, koridorda oluşuyor. Geçerli bir bayi hesabıyla giren biri, adres çubuğundaki tek bir sayıyı değiştirerek başka bayinin siparişini görebiliyorsa; ya da gizlenmiş bir menü öğesinin arkasındaki uç noktaya doğrudan istek atıp fiyat listesini değiştirebiliyorsa, kimlik doğrulamanın hiçbir önemi kalmaz.

Bu yazıda bir e-pin scripti üzerinde yetki yükseltme açıklarını nasıl sistematik biçimde arayacağını anlatıyoruz. Yatay ve dikey yükselmenin farkı, IDOR testinin somut adımları, arayüzde saklamanın neden güvenlik olmadığı, API ve webhook uçlarında kaçırılan kontroller ve bulduklarını kalıcı olarak kapatmak için kurman gereken merkezi yetki katmanı. Kendi yazılımını geliştiriyorsan bu bir yol haritası; Pinova gibi lisanslı bir e-pin satış yazılımı kullanıyorsan yine de bu testleri yapmalısın, çünkü kendi eklentin ve özelleştirmen bu katmanı delebilir.

Yatay mı dikey mi: neyi aradığını biliyor musun?

İki ayrı sorunu tek isimle anmak, testin en yaygın hatasıdır. Yatay yükselme, aynı seviyedeki başka bir kullanıcının verisine erişmektir: bayi A'nın bayi B'nin siparişini, faturasını, müşteri listesini görmesi. Dikey yükselme ise seviyenin üstüne çıkmaktır: bayinin yönetici işlevini çalıştırması, fiyat tanımlaması, bakiye eklemesi, kullanıcı rolü değiştirmesi.

Ayrımı bilmek testi yönlendirir. Yatay açıklar neredeyse her zaman nesne kimliğinin sahipliğinin doğrulanmamasından doğar; sorgu "bu kayıt var mı" diye bakar, "bu kayıt bu kullanıcıya mı ait" diye bakmaz. Dikey açıklar ise rol kontrolünün merkezî olmamasından, her denetleyicide elle tekrarlanmasından doğar. Bir yerde if bloğu yazmayı unuttun ve kapı orada açık kaldı. Bu yüzden dikey testleri, kodda tekrarın en yoğun olduğu yeni eklenmiş özelliklerde yoğunlaştırmalısın.

IDOR testini nasıl elle yaparsın?

Kuruluma iki test bayisi aç: A ve B. Her ikisiyle de birer sipariş oluştur, birer destek talebi yaz, birer fatura üret. Sonra A'nın tarayıcı oturumuyla, B'ye ait kayıtların kimliklerini tek tek dene. Sipariş detayı, fatura indirme, destek talebi görüntüleme, kod listesi, log kaydı, dosya eki. Dönen yanıt 200 ise ve içerik B'ye aitse bulgunu yazdın.

Dikkat edilmesi gereken üç incelik var. Birincisi, sayfa boş görünse bile ağ sekmesindeki JSON yanıtına bak; arayüz veriyi göstermese de uç nokta göndermiş olabilir. İkincisi, yalnızca GET ile yetinmeyin; silme, güncelleme ve iptal uçlarını da dene, en tehlikeli bulgular oralardadır. Üçüncüsü, kimlik alanı gövdedeyse orayı da değiştir; birçok dijital ürün satış scripti URL'deki kimliği doğrular ama form gövdesindeki ikinci kimliği sessizce güvenilir kabul eder.

Arayüzde gizlemek güvenlik sayılır mı?

Sayılmaz ve bu, denetimlerde en sık rastladığımız yanılgıdır. Menü öğesini role göre gizlemek bir kullanıcı deneyimi kararıdır, yetki kararı değildir. Tarayıcıda gizlenen bağlantının adresi kaynak kodda, JavaScript paketinde ya da bir eski ekran görüntüsünde duruyordur. Saldırgan menüyü hiç kullanmaz; isteği doğrudan atar.

Kural nettir: yetki kontrolü sunucuda, veriye dokunan katmanın hemen önünde yapılmalıdır. Şablon içinde rol sormak yerine, isteği karşılayan her uç noktanın başında hem kimliği hem sahipliği hem de eylem iznini doğrulayan tek bir merkezi kapı olmalı. Daha iyisi, varsayılanı "reddet" yapıp izin verilen eylemleri tek tek beyan etmektir. Böylece yeni bir özellik eklediğinde unuttuğun yer açık kalmaz, kapalı kalır; hata yönü seni korur. İyi tasarlanmış bir dijital ürün satış yazılımı bu kapıyı çerçeve düzeyinde zorunlu kılar.

API ve webhook uçları neden en çok kaçırılan yer?

Web arayüzünü dikkatle koruyup API tarafını unutmak klasik bir kör noktadır. Bayilerine entegrasyon için anahtar veriyorsan, o anahtarın kapsamı olmak zorundadır: hangi uçlara erişebilir, hangi işlemleri yapabilir, hangi IP'den gelebilir, saatte kaç istek atabilir. Kapsam tanımlamadığın anahtar, pratikte o hesabın tam yetkili ikinci şifresidir ve bir kere sızdığında iptal edene kadar her şeyi yapabilir.

Webhook tarafında ise iki test yap. Birincisi imza doğrulaması: imzayı bozup istek at, kabul ediliyorsa ödeme bildirimini taklit edebiliyorlar demektir. İkincisi tekrar oynatma: geçerli bir bildirimi aynen ikinci kez gönder, sistem aynı siparişi ikinci kez tamamlıyorsa bakiye üretme açığın var. Zaman damgası penceresi ve tek kullanımlık kimlik kontrolü bu iki testi kapatır. Bunlar bir epin yazılım kurulumunda gözden kaçtığında, zararı doğrudan stoktan ve kasadan çıkar.

Bulguları nasıl kalıcı olarak kapatırsın?

Tek tek yama atmak, aynı açığı altı ay sonra başka bir ekranda yeniden görmenin garantisidir. Kalıcı çözüm, yetki mantığını denetleyicilerden çıkarıp tek bir politika katmanına taşımaktır: "bu kullanıcı, bu nesne üzerinde, bu eylemi yapabilir mi?" sorusunu tek bir yerde yanıtlarsın. Sorgu düzeyinde de kapsamı daralt; listeleri baştan hesap kimliğiyle filtreleyen yöntemler kullan, sonradan kontrol etmeye güvenme.

Üstüne iki alışkanlık ekle. Birincisi regresyon testi: bulduğun her açık için, ikinci bir hesabın o kaydı çağırdığında 403 aldığını doğrulayan otomatik bir test yaz. Böylece açık bir daha geri gelmez. İkincisi sürüm öncesi kontrol listesi; her yeni ekran ve her yeni uç nokta yayına çıkmadan önce yatay ve dikey testten geçer. Yapman gereken şey kahramanlık değil, tekrarlanabilir bir rutin. Bu rutini kurduğunda, hangi e-pin satış scripti üzerinde çalıştığından bağımsız olarak risk eğrini kalıcı biçimde aşağı çekersin.

Yetki yükseltme, e-pin işinde sessiz ilerleyen bir hasardır: kimse kapıyı kırmaz, biri koridorda yanlış odaya girer ve aylarca fark edilmez. Bu yüzden testi bir defalık proje değil, her sürümün parçası yap. Kendi kurulumunda hangi kontrollerin hazır geldiğini karşılaştırmak istersen özellik listesini ve fiyat seçeneklerini incele, sonra rol matrisini ve bayi panelinin sınırlarını canlı demo üzerinde bizzat zorlayarak gör.