Business Logic
“Business Logic” terimi, uygulamanın nasıl çalıştığını tanımlayan kurallar kümesini ifade eder. Bu kurallar her zaman bir business doğrudan ilişkili olmadığından, ilişkili güvenlik açıkları “application logic vulnerabilities” veya basitçe “logic flaws”olarak da bilinir.
Yukarıdaki şemayı yorumlayarak daha iyi anlayalım. Kullanıcılarımızı projelerimizin arayüzlerinde karşılamaktayız. Projeye gelen kullanıcılar belli işlemler için servis ile etkileşime girmektedir. Kullanıcı tarafından gelen isteklerimizi Uygulama katmanlarında(Application Layer) karşılamaktayız. Kullanıcıların isteklerini gerçekleştirmeden önce Business Logic uğramaktayız. Bu şekilde kontroller sağlanarak Veri Tabanı erişiminin olup olmadığını öğrenmiş olacağız. Örnek ile açıklamak gerekirse;
Departmanların bilgisini tutan bir şirket yönetim projesi hazırlıyoruz. Projemizde her departman görevlisinin sadece bulunduğu departmanın bilgilerini görmesini istemekteyiz. A departmanında çalışan bir kullanıcı B departmanı bilgisi görüntülemek için istek atıyor, Business Logic üzerinde kontrol sağlanıyor ve Veri tabanı izini olmadığından isteğimiz sonlandırılıyor.
Güvenlik açıkları nasıl oluşuyor?
İstemci tarafına aşırı güven
Yukarıdaki şemayı açıklayarak anlatmak istiyorum. Front-end tarafında React, Back-end tarafında NodeJS ile çalışan e-ticaret projesi bulunmaktadır. Bu proje REST API aracılığıyla iletişim kurmaktadır. Kullanıcı bir ürün beğenip sepetine eklemiştir, oluşan sepeti daha sonra ödeme yapmak için onayla butonuna basmıştır. Kullanıcı giden HTTP Request incelediğinde body içersinde Price,Quantity ve Product ID gittiğini görmektedir. Kullanıcı ürünün front-end tarafından gönderildiğini anladığında price değeri örneğin 200 TL olan ürünün Price=0 olarak düzenlemiştir. Servis gelen Request’i istediği formda olduğu için kabul etmiş ve kullanıcı bu şekilde bedava ürün almıştır. Aynı senaryo body değilde Query Parameters üzerinden gerçekleşebilirdi. Şemamızın “İyi Senaryo” Kısmında bu zaafiyetten bahsedemeyiz
Beklenmedik inputların gelmesi
Front-end tarafından beklemediğimiz inputlar gelebilmektedir. Örneğin, sayısal bir veri türü negatif değerleri kabul edebilir. Uygulama sunucu tarafında yeterli input doğrulaması yapmazsa ve bu girişi reddetmezse, saldırgan negatif bir değer iletebilir ve istenmeyen davranışlara neden olabilir. İki banka hesabı arasında para transferi gerçekleşmektedir. Aktarımı tamamlamadan önce gönderenin yeterli paraya sahip olup olmadığını neredeyse kesin olarak kontrol edilmesi beklenmektedir
Gelen Miktarın değeri -1000 olduğunu varsayalım Varolan Bakiyemizinde 0. Normal şartlar altında bakiyemizin 0 olduğu durumda herhangi para yollama işlemi yapılamayacaktır. Fakat negatif input girişi kontrol edilmediğinden transfer gerçekleşecektir 🤷
Kullanıcıların davranışları hakkında hatalı varsayımlar yapmak
Şirketimize yönetim uygulaması yapmaya karar veriyoruz. Bu uygulama kullanıcı yönetimi yapabilecek ve iş yönetimini sağlayacaktır. Biz şirket için kullanımı olacağı için herhangi bir Authorization(Yetkilendirme) vermeyeceğiz. İsteyen çalışan buradan gelip hesap açıp her yetkiye sahip olacaktır. Burada beklentimiz her çalışan kendi hesabının yönetimini yapıp diğer hesaplar için işlem yapmaması. Şirket çalışanlarından birisi cinnet geçirmiş olabilir ve ya bilgisayarında bulunan trojan aracılığıyla oluşturulan uygulamanın URL ve hesap bilgilerini ele geçirmiş olabilir. Çalışan hesabıyla bütün hesapların silinmesi ve bilgilerin alınması an meselesi olabilicektir bu durumda
Alana özgü kusurlar
Bu güvenlik açığında örnek ile ilerlemek mantıklı olacaktır. Bir e-ticaret uygulamamız bulunmaktadır ve bu e-ticaret sitemiz düzenli olarak kampanyalar yapıp müşterilerinin ilgisini çekmek istemektedir. Sitemizde 2 tane kupon olanağı vardır. Bunlardan biri ilk siparişe özel 10 TL indirim diğeriyse iletişim izinleri veren kullanıcıların 30 TL indirim kazanabilmesi. Biz ürünlerimizi sepete ekledik daha sonra sipariş işlemini gerçekleştireceğiz ödeme kısmına gelmeden kupon kodunun girişini yapmaktayız daha sonra bu kuponu tekrar algılayacak mı diye kontrol edip girişi yapıyoruz fakat bize dönen hatada “Bu kupon kodu zaten girilmiştir” diye uyarı mesajı geldi. Biz elimizdeki diğer kupon kodunu giriyoruz 2 indirim kazanmış olduk. Buradaki Business Logic kupon kodu kullanıldı mı diye servisin son kupon koduna bakması. Biz 2 kupon kodu girmiştik bu sefer tekrar ilk girdiğimiz kuponu giriyoruz bu durumda son kupona bakıyor servis aynı kupon kodu olmadığından kabul ediyor ve 1 kuponu tekrar tekrar girebilmemiz için açığı buluyoruz. Böylelikle tekrardan bedava ürün alma şansına sahip oluyoruz
Race Condition
Teorik olarak Race Condition, birbirinden ayrı çalışan sistemlerin bir veriyi işleme ve iletmesi sırasındaki uyumsuzluğundan(async)
kaynaklanan bir davranış biçimidir.
Yukarıdaki şemayı örnek ile ele almamız daha doğru olacaktır. Kullanıcıların hediye ürün talep ettiği bir servis bulunmaktadır. Bu servis her kullanıcı için 1 hediye ürün ayıracaktır. Adımlara bakarsak;
1- Kullanıcı hediye ürün ister
2- Servis gelen kullanıcının daha önce hediye ürün alıp almadığını kontrol eder
3- Eğer hediye ürün almadıysa hediye ürün alma servisi başlatılır ve kullanıcıya hediye ürün iletilir, daha önce aldıysa bu isteği sonlandırılır
4- Hediye ürün alma servisi alınabilir eşyaları listeler herhangi bir eşyayı seçer ve müşteriye tanımlar. Kullanıcının hakkı bitmiş olarak kaydedilir
5- Tanımlanan hediye ürün müşteriye iletilir
Senaryomuz bu şekilde gerçekleşmektedir. Buradaki paralel olarak atılan isteklerin çakışmasıdır. Kullanıcı aynı anda bu servise 10 istek yollamaktadır. Servis ilk önce hediye ürün alıp almadığını kontrol edecektir, kullanıcının hediye ürün almadığını görüp 10 isteği içeriye alacaktır. Daha sonra bu kullanıcıya alınabilir hediye ürünler listelecektir, birer tane seçildikten sonra paralel şekilde hediye ürün kayıt işlemi yapacaktır. Kullanıcımıza 10 servis hediye ürün dönüşü yapacaktır ve artık bir daha kullanıcı istek attığında hediye ürün alamayacaktır. Fakat Race Condition oluşması sebebiyle kullanıcı 1 hakkı varken 10 tane hediye ürün alabilmiştir. Bu bize “Business Logic Vulnerabilities” problemini göstermektedir.
İyi senaryoyu yorumlarsak, kullanıcı ilk önce servise istek atacaktır daha sonra hediye ürün verme servisi çağrılmayacak gelen istekler kuyruğa alınacaktır. Kuyruğa giren istekler bir sonraki işlemin bitmesini bekleyecek ve işlem bittikten sonra kontrol’a tabir tutulacaktır. Böylelikle kullanıcılar paralel şekilde servis isteklerinde bulunsada kuyruk yapımız ile bu soruna engel olmuş olduk 💂
Göz önünde bulundurmadığımız böyle durumlar canımızı sıkabilir. Yaptığımız işlemler basit ya da zor olsun tekrar gözden geçirmeyi unutmayalım 💪
