İş mantığı açığı: güvenlik tarayıcısı görmüyor, rezervasyon ve sepet kırılıyor

Bir rezervasyon sitesindeki ya da sipariş sistemindeki en pahalı açıklar doğru kod gibi görünür. Sunucu siparişi numarasıyla veriyor ve kimin olduğunu sormuyor. Profildeki “rol” alanı istemcinin gönderdiğini kabul ediyor. Tutarı tarayıcı hesaplıyor, sunucu inanıyor. Güvenlik tarayıcısı burada susuyor, çünkü arayacağı bir şey yok: kontrol yok ve kodun yokluğu hiçbir şablona oturmuyor. Bu hafta bunu GitLab, Cloudflare ve Shopify yazdı. Benim de araç kiralamadan ve kahve siparişlerinden ekleyeceklerim var.

Ne çıktı

GitLab 20 Ekim'de Business Logic Security Analyzer'ı tanıttı; şimdilik GitLab.com'daki Ultimate müşterileri için erken erişimde. Çıkış noktaları doğru: nesne düzeyinde yetkilendirme ihlali OWASP API Security Top 10'da ilk sırada ve sıradan SAST böyle şeyleri bulmuyor. Metinden üç örnek: endpoint sipariş ID'sini istekten alıp siparişi sahibini kontrol etmeden döndürüyor; rol alanı herhangi bir JSON kabul ediyor; kullanıcı ID'si ardışık bir tam sayı. Tek tek bakınca geçerli kod, birlikte bakınca bütün müşterilerin bütün siparişleri ve yönetici hakları. Analizör depoyu bütünüyle okuyor ve her handler'ı kimin ne yapabileceği modeline göre kontrol ediyor. Demolarında refunded=1'i sahibini kontrol etmeden koyan refund_order'ı buluyor ve CWE-639 olarak işaretliyor.

Cloudflare 21 Ekim'de WAF'a bütün işlemin kontrolünü ekledi: isteğe yanıtla birlikte bakılıyor ve kural, sunucunun yanıtını isteyen kişiye ulaşmadan engelleyebiliyor. Metinden örnek: ../../config/database.ini dosyasına istek tek başına henüz bir şey kanıtlamıyor, ama veritabanı kullanıcı adı ve şifresiyle dönen 200 yanıtı her şeyi kanıtlıyor. Bunu ücretsiz plan dahil herkese verdiler. Aynı yerden bir çekince: yanıt engellenebilir, ama sunucunun çoktan yaptığı şey geri alınamaz. Başkasının siparişine para iadesi o ana kadar çoktan geçmiş olur.

Shopify 20 Ekim'de bütün uygulama geliştiricilerinden bu hafta güvenlikle ilgilenmelerini istedi: yeni kontrolü çalıştırmak, yakında herkese açık uygulamalar için zorunlu olacak süresi dolan erişim token'larına geçmek, istek loglarına müşteri IP'sine göre bakmak ve iki faktörlü korumayı her yerde açmak. Kontrolün kendisi 15 Ekim'de Shopify CLI'da shopify app security check komutu olarak çıktı: yerelde çalışıyor, koda, yapılandırmaya ve bağımlılıklara bakıyor. Deneyen partnerler kendilerinde kimlik doğrulamada ve mağazalar arası veri izolasyonunda boşluklar bulmuş. Aracın kodu açık.

Ve tezgâhın öbür tarafından bir haber. CNews 20 Ekim'de Kaspersky Lab'in uyarısını aktardı: kablosuz barkod okuyuculardaki açıklar üzerinden depo bilgisayarlarına, oradan da sipariş işleme ve sevkiyata erişilebiliyor. Aynı yol veri toplama terminalleri ve termal yazıcılar üzerinden de var.

Araç kiralamada bu nasıl görünür

Bir araç kiralama sitesini ele alalım. Müşteri araç rezerve ediyor, 1041 numaralı sözleşmenin bağlantısını alıyor ve meraktan 1040'ı açıyor. Sunucu sözleşmeyi numarasıyla veriyor ve kimin olduğunu kontrol etmiyorsa, müşteri komşusunun kimlik bilgilerini okuyor. Sonra ödeme isteğinde price alanının gittiğini fark ediyor ve değiştiriyor. Tutarı tarayıcı hesaplıyor, sunucu geleni kaydediyorsa araç yarı fiyatına gidiyor. Bu açıkların hiçbiri koddaki bir hata gibi görünmüyor.

Sonuç: kimin neyi yapabileceği ve tutarın nasıl hesaplandığı kuralları sunucuda yaşamalı ve orada yürütülmeli. İstemci yalnızca sonucu gösterir.

Bende nasıl yapıldı

2025 yılı boyunca tam rezervasyon döngüsüne getirdiğim Cape Town'daki araç kiralama sitesinde rezervasyon, belgeler, imzalar ve araç kontrolü tek bir zincire bağlı. Ödeme, süreç içinde eklenen ekran görüntüsünden kontrol ediliyor. Bu bir görüntü kontrolü, bankayla karşılaştırma yapılmıyor ve bunu açıkça yazıyorum.

“Birlikte Kahve” iç servisinde kurallar daha sıkı, çünkü söz konusu olan çalışanların parası. Node.js üzerindeki gateway istemcinin gönderdiği kimlik başlıklarını siliyor ve kullanıcıyı imzalı HttpOnly cookie'den kendisi belirliyor. Yani istekteki “ben adminim” hiçbir şey ifade etmiyor. Sipariş formunda fiyat yok: tutar ancak organizatör tedarikçinin gerçek sepetini kontrol ettikten sonra beliriyor. Sipariş ancak organizatör paranın geldiğini kontrol ettikten sonra ödenmiş sayılıyor. “Sipariş verildi” işaretini ise servis yalnızca bütün ödemeler kontrol edildikten ve sipariş tedarikçiye gerçekten verildikten sonra koymaya izin veriyor. Teslim etmek yalnızca tamamı alınmış sipariş için mümkün. Her geçiş sunucuda bir kontrol ve tarayıcının görmediği şey tam da bu kontrollerin yokluğu.

Ne yapardım

Bütün giriş noktalarını yazardım: sayfalar, API, webhook'lar, tablolardan içe aktarma, depodaki okuyucular. Her biri için kimin hangi kayıtlara hakkı olduğuna cevap verirdim.

ID ile verdiği her nesnede sunucunun sahibini kendisinin kontrol ettiğini doğrulardım. İkinci bir hesap ve adres çubuğunda başkasının sipariş numarası bunu beş dakikada bulur.

Tutarı, indirimi, durumu ve rolü yalnızca sunucuda hesaplar ve değiştirirdim. İstemciden gelen alanları beyaz listeye göre kabul ederdim.

Sipariş durumlarını ve aralarındaki geçişleri kural olarak yazardım: hangi durumdan hangisine, hangi kontrolden sonra geçilebilir.

Shopify'ın önerdiği gibi loglara IP'ye ve hesaba göre bakardım.

Kontroller, durumlar ve haklar üzerine: İş mantığı: kurallar, durumlar ve haklar. Yönlere göre: işle bağlantılı müşteri ürünü ve veri aktarım kuralları net API entegrasyonları. Bu yazıdaki sistemler Güney Afrika'daki araç kiralama ve “Birlikte Kahve” vakalarında anlatılıyor. Yakın yazılardan: müşteri paneline giriş: passkey'ler, SSO ve şifresiz bağlantı, mağazalar vitrinlerini AI ajanlarına hazırlıyor ve 30 kişilik şirket için zero trust; daha önce ödeme öncesi sepet ve webhook güvenliği üzerine yazmıştım. Sipariş sisteminizde adres çubuğunda ID ve istemcinin gönderdiği bir tutar varsa, nasıl kurulu olduğunu anlatın, önce neyi kontrol edeceğinizi söyleyeyim. Görevi konuşalım.