Business Logic ve Business Logic Flaws Nedir?
Business Logic zafiyetlerini anlamak için öncelikle “Business Logic” teriminin ne olduğunu ve ne ile ilişkilendirileceğini anlamamız gerekiyor. Zira Business Logic’in ne olduğu hakkında temel birikimimizin olması ilerleyen süreçte bu zafiyetleri doğru anlamlandırmamıza yardımcı olacak.
Türkçeye genellikle “iş mantığı” veya “etki alanı mantığı” olarak çevrilen (ne kadar doğru bilmiyorum) Business Logic, uygulamaların sistemlerini anlamlandırma kısmında, bir uygulamanın nasıl çalışacağından, veritabanı ile kullanıcı arasındaki tüm etkileşimlerinden, uygulamada bulunan görevli tüm nesnelerin birbirlerinden nasıl etkileneceğine kadar uzanan geniş bir kavramdır.
Kavramın isminden de anlayacağımız gibi, Business Logic sistemin çalışma mantığını oturtan bu kavram başka bir anlamda da kullanıcının uygulamada doğru yönetilmesini sağlar diyebiliriz.
Business Logic kusurları da tam burada devreye giriyor, kullanıcı sistemin dışında bir mantıkla davrandığında ve bunu güzelce yedirdiğinde, yine uygulamanın işleyişine aykırı ilerlediğinden bazı ayrıcalıklara sahip olabiliyor.
Yani kısacası, Busines Logic kusurları uygulamanın çalışma mantığına ters düşen davranışlar üzerinden ayrıcalık elde etme yöntemidir. Buna da terim olarak “Business Logic Flaws” (iş mantık hataları) denir.
Business Logic Kusurlarının Tespiti
Business Logic kusurların tespiti genellikle, giriş ve kayıt sayfalarında, sipariş & satın alım sayfalarında, 2FA üzerinde ve bakiye tutarı üzerinden yapılabilecek manüplasyonlarla sağlanabilir. Bu teknikleri 2. kısımda listeleyip ayrıntılı şekilde ele alacağım.
Örneğin bir site düşünün -yine örneklerle daha iyi inceleyeceğiz- bu site üzerinde mevcut bakiyenizin üzerindeki bir ürünü (mesela 1000$) satın almak istiyorsunuz.
Almak istediğiniz ürünü sepete ekledikten sonra “sepetiniz” kısmına geliyor ve siparişinizi gönderiyorsunuz. Bu esnada da Burp üzerinden gönderdiğiniz isteğe müdahale ediyor ve HTTP isteğinin data kısmında beliren “&price=1000” tarzında bir parametre görüyorsunuz. Evet, fiyat 1000$ olarak tanımlanmış.
Bizde var 0$. Peki ne yapacağız? Tanımlanan fiyata müdahale edecek ve düşürmeye çalışacağız, isteğimizi göndereceğiz ve sistem tarafından “yetersiz bakiye” tarzında bir hata alacağız.
Peki bunun yerine, tanımlanan fiyatın önüne bir eksi koyarsak? Evet evet, bildiğin eksi. Yani yeni parametre “&price=-1000” şekline dönüşecek ve bu noktada bakiyemiz alacağımız ürünün fiyatını karşıladığı için -1000$’lık bir ürünü satın alabileceğiz.
Burada örneklediğim fiyat manüplasyonu, döviz miktarları üzerinden de yapılabilirdi, yani kullanıcı para birimleri arasındaki birim farklarını kullanarak almak istediği ürünü çok daha ucuza da sipariş edebilirdi.
Business Logic Kusurlarının Sömürülme Senaryoları
İşin teorik kısmı konusunda pek iyi değilimdir, yine de elimden geldiğince anlaşılabilir olmaya çalıştım. Şimdi gelelim işin pratik kısmına. İşe PortSwigger’ın labı üzerindeki bazı “Business Logic Flaws” örneklerine bakarak başlayabiliriz.
I) Yetersiz İş Akışı Doğrulaması (Insufficient workflow validation)
Basit bir örnekle başlayalım, bu senaryomuzda satın alma sırasındaki mantık hatası yüzünden, hedefimiz olan “l33t” ceket ürününü bakiyemiz eksilmeden sipariş verebilmiş olacağız.
Öncelikle sisteme giriş yapalım ve bakiyemiz(100$) altındaki bir ürünü satın alarak satın alma akışının nasıl gerçekleştiğini keşfedelim:
Gördüğümüz gibi sipariş GET metodu ile doğrudan (order-confirmed=true) şeklinde doğrulanıyor. Yani bu uygulama, satın almak istediğimiz tüm ürünleri yeterli şekilde doğrulamadan siparişimizi gerçekleştiriyor olabilir. Bir denemekte fayda var.
Hedef ceketimizi sepetimize ekleyelim ve satın almayı gerçekleştirelim, ardından isteğimize müdahale edelim ve siparişi onaylayalım.
Karşımıza gelen yetersiz bakiye cevabını (err=INSUFFICIENT_FUNDS) kaldıralım ve yerine işlemi başarıyla gerçekleştirdiğimiz (order-confirmed=true) cevabını girelim.
Ve gördüğümüz gibi siparişimizi başarıyla gerçekleştirebildik.
II) Üst Düzey Mantık Hatası (High-level logic vulnerability)
İkinci örneğimizde, hedefimiz olan ceketi almak için yine bazı kurnazlıklar peşine gireceğiz. Yine bakiyemiz(100$) ve istediğimiz ceket (1337$) uyuşmadığı için bakiyemiz üzerinden bir manipülasyona girişeceğiz. Şimdi ceketimizi sepetimize ekleme anını daha dikkatli ele alalım:
Gördüğümüz gibi ceketimizi sepetimize eklerken bir POST isteği gönderiyoruz, burada dikkatimizi çeken kısım miktar kısmı olmalı. Zira önüne bir eksi koyarsak yani (&quantity=-1) -1 tane ceket alırsak ve uygulama buna izin verirse, bakiyemiz -1337$ olabilir.
Ve evet, gerçekten de eksideyiz fakat bu şekilde sipariş vermeye çalıştığımızda uygulamamız total miktarımızın sıfırdan küçük olamayacağını söylüyor. Peki biz pes mi edeceğiz? Hayır. Sepetimize değeri daha az olan başka bir ürün ekleyelim ve total bakiyemizi sıfır ila yüz arasında bir değere eşitleyelim.
Vee evet, her şey tam da istediğimiz gibi, siparişimizi veriyoruz.
Bu yazıyı ikinci kısmında sürdürmek üzere burada noktalıyorum. Görüşmek üzere.
