Furkan Öztürk tarafından yazılmıştır.
Business logic zafiyetlerine giriş yapmadan önce Business Logic kavramına ve ne olduğuna değinelim.
Business Logic, Türkçesiyle İş Mantığı, mevcut bir yazılımda verilerin, oluşturulma, yorumlama, depolanma, işleme koyulma gibi kurallarını, bir senaryo karşısında uygulamanın nasıl tepki vereceğini belirler. Kısaca sistemin çalışma mantığına ait kuralların koyulmasına denir de diyebiliriz.
Business Logic’ten bahsettiğimize göre şimdi Business Logic Flaws’i ele alalım. Türkçesiyle “İş Mantığı Kusurları” anlamına gelmektedir. Bir sistemin, çalışma mantığına aykırı bir davranış ile sistemde normal şartlar altında gerçekleştirilemeyecek bir aksiyon gerçekleştirilirse burada İş Mantığı Kusurları ya da diğer bir deyişle İş Mantığı Güvenlik Açıkları var diyebiliriz.
Business Logic zafiyetleri genellikle aşırı karmaşık sistemlerde geliştiricilerin, kullanıcıların uygulamayla nasıl etkileşimde bulunacağı konusunda hatalı varsayımlarda bulunması nedeniyle ortaya çıkar. Bu hatalı varsayımlar, kullanıcıların gerçekleştirdiği aksiyonların sistem tarafından yetersiz doğrulanmasına sebebiyet verebilir. Bunun sonucunda geliştirilen uygulamanın, kullanıcı etkileşimlerine karşı gerekli güvenliği sağlamadığı saptanır ve bu uygulamada bir Business Logic zafiyetinden söz edilebilir. İlerleyen başlıklarda bu zafiyet çeşidinin nasıl önlenebileceği ile ilgili bahsedeceğiz.
Business Logic zafiyetleri, önceki başlığımızda da belirttiğimiz gibi sistemin çalışma prensibine aykırı senaryolarla aykırı davranışlar gerçekleştirilerek tespit edilebilir. Bu durumda saldırgan,sunucuyla, geliştiricilerin beklemediği bir etkileşim kurarak davranışsal tuhaflıklardan yararlanabilir. Örneğin; Herhangi bir E-Ticaret sitesinde bulunan satın alma kurallarını aşarak hiç para vermeden ya da ürünün değerinden daha az bir miktarla alışveriş yapmak buna örnek olarak verilebilir. Diğer zafiyet türlerinde de olduğu gibi bu zafiyet türünde de geliştiricinin akıl etmediği ya da olmasına ihtimal vermediği kullanıcı-sunucu etkileşimlerini bahsi geçen uygulamada gerçekleştirerek zafiyet tespiti yapılabilir.
Şimdi artık Business Logic’i de kavradığımıza göre istismar aşamasına geçebiliriz. Bu başlık altında kullanacağımız lab ortamı PortSwigger üzerinde bulunan “High-level logic vulnerability” isimli lab olacak. (https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-high-level)
Bu lab ortamında, E-Ticaret sitesindeki satın alma kurallarında bulunan bir business logic zafiyetinden faydalanarak bir ürünü istenen ücretinden farklı bir ücret ödeyerek satın alacağız. laboratuvarımıza eriştikten sonra bize verilen kimlik bilgilerini ilgili alana yazarak giriş yapıyoruz
Siteye Giriş
Ardından rastgele ucuz bir ürünü açıyoruz. Ben “All-in-One Typewriter” isimli ürünü seçtim.
Sepetime ürün eklemeden önce BurpSuite yazılımımı çalıştırıyorum. Tarayıcımda Proxy ayarlarını da yaptıktan sonra artık ürünümü sepete ekleyebilirim. Ürünü sepete ekledikten sonra burp’e dönelim. HTTP History kısmından POST /cart isteğini inceleyelim. Aşağıda da gördüğünüz üzere çeşitli parametreler bizi karşılıyor. Burada “quantity” parametresinin aldığımız ürünün adedini verdiğini anlıyoruz.
quantity parametresi
Şimdi sepete ekleme işlemini tekrarlayalım. Fakat bu sefer isteği sunucuya göndermeden önce yakalayarak “quantity” parametresindeki değeri değiştirmeye çalışalım.
Sepete ekleme işlemini tekrarlayıp isteği yakaladığımda yine aşağıdaki gibi bir istekle karşılaşıyorum. Fakat bu sefer “quantity” parametresini 5’e eşitledim.
parametre değerinin değiştirilmesi
Şimdi isteği gönderelim. Bakalım sepetimize aynı üründen +5 adet eklenecek mi?
İsteği gönderip sepetimi görüntülediğimde sepetimde daha önceki işlemle beraber toplamda 6 adet “All-in-One Typewriter” ürünü olduğunu görüyorum. Demek ki yaptığımız değişiklik sunucuda tekrar kontrol edilmeden işleme alındı ve isteği değiştirerek aynı üründen +5 adet daha ekleyebildim.
sepet
Şimdi sepetimi temizliyorum. Çünkü aklıma ürün adedini negatif bir değer yapmak geliyor. Bu sayede ücreti de negatif bir değere düşürebilmiş olacağım. Aynı ürünü sepetime tekrar ekleyip burp ile giden isteği yakalıyorum ve quantity parametresinin değerini -39 yapıyorum.
negatif değer verme
isteği yollayıp sepetimi görüntülediğimde karşımdaki manzara aşağıdaki gibi oluyor. Gördüğünüz gibi aynı üründen sepetime -39 adet eklemiş görünüyorum.
sepet – 2
Şimdi ise almak istediğimiz ürünü sepete normal bir şekilde ekleyelim. PortSwigger görevine göre hareket ettiğimizde bizden “Lightweight l33t leather jacket” isimli ürünü istenmeyen bir fiyattan almamız söyleniyor. Bu sebeple “Lightweight l33t leather jacket” isimli ürünü sepetime ekledim ve sepetimin son hali aşağıdaki gibi oldu.
sepetin son hali
Yani mağazadaki fiyatı 1337$ olan bir ürünü Business Logic zafiyetini sömürerek 19,97$‘a almış oldum.
sipariş onaylandı
Bu yazımızın da sonuna geldik. Başka başlıklarda görüşmek dileğiyle…
[TR] BUSINESS LOGIC ZAFİYETLERİ VE İSTİSMAR EDİLMESİ
BUSINESS LOGIC NEDİR ?
Business logic zafiyetlerine giriş yapmadan önce Business Logic kavramına ve ne olduğuna değinelim.
Business Logic, Türkçesiyle İş Mantığı, mevcut bir yazılımda verilerin, oluşturulma, yorumlama, depolanma, işleme koyulma gibi kurallarını, bir senaryo karşısında uygulamanın nasıl tepki vereceğini belirler. Kısaca sistemin çalışma mantığına ait kuralların koyulmasına denir de diyebiliriz.
BUSINESS LOGIC FLAWS NEDİR ?
Business Logic’ten bahsettiğimize göre şimdi Business Logic Flaws’i ele alalım. Türkçesiyle “İş Mantığı Kusurları” anlamına gelmektedir. Bir sistemin, çalışma mantığına aykırı bir davranış ile sistemde normal şartlar altında gerçekleştirilemeyecek bir aksiyon gerçekleştirilirse burada İş Mantığı Kusurları ya da diğer bir deyişle İş Mantığı Güvenlik Açıkları var diyebiliriz.
BUSINESS LOGIC ZAFİYETLERİ NASIL OLUŞUR ?
Business Logic zafiyetleri genellikle aşırı karmaşık sistemlerde geliştiricilerin, kullanıcıların uygulamayla nasıl etkileşimde bulunacağı konusunda hatalı varsayımlarda bulunması nedeniyle ortaya çıkar. Bu hatalı varsayımlar, kullanıcıların gerçekleştirdiği aksiyonların sistem tarafından yetersiz doğrulanmasına sebebiyet verebilir. Bunun sonucunda geliştirilen uygulamanın, kullanıcı etkileşimlerine karşı gerekli güvenliği sağlamadığı saptanır ve bu uygulamada bir Business Logic zafiyetinden söz edilebilir. İlerleyen başlıklarda bu zafiyet çeşidinin nasıl önlenebileceği ile ilgili bahsedeceğiz.
BUSINESS LOGIC ZAFİYETLERİNİN TESPİT EDİLMESİ
Business Logic zafiyetleri, önceki başlığımızda da belirttiğimiz gibi sistemin çalışma prensibine aykırı senaryolarla aykırı davranışlar gerçekleştirilerek tespit edilebilir. Bu durumda saldırgan,sunucuyla, geliştiricilerin beklemediği bir etkileşim kurarak davranışsal tuhaflıklardan yararlanabilir. Örneğin; Herhangi bir E-Ticaret sitesinde bulunan satın alma kurallarını aşarak hiç para vermeden ya da ürünün değerinden daha az bir miktarla alışveriş yapmak buna örnek olarak verilebilir. Diğer zafiyet türlerinde de olduğu gibi bu zafiyet türünde de geliştiricinin akıl etmediği ya da olmasına ihtimal vermediği kullanıcı-sunucu etkileşimlerini bahsi geçen uygulamada gerçekleştirerek zafiyet tespiti yapılabilir.
BUSINESS LOGIC ZAFİYETLERİNİN İSTİSMAR EDİLMESİ
Şimdi artık Business Logic’i de kavradığımıza göre istismar aşamasına geçebiliriz. Bu başlık altında kullanacağımız lab ortamı PortSwigger üzerinde bulunan “High-level logic vulnerability” isimli lab olacak. (https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-high-level)
Bu lab ortamında, E-Ticaret sitesindeki satın alma kurallarında bulunan bir business logic zafiyetinden faydalanarak bir ürünü istenen ücretinden farklı bir ücret ödeyerek satın alacağız. laboratuvarımıza eriştikten sonra bize verilen kimlik bilgilerini ilgili alana yazarak giriş yapıyoruz
Siteye Giriş
Ardından rastgele ucuz bir ürünü açıyoruz. Ben “All-in-One Typewriter” isimli ürünü seçtim.
Sepetime ürün eklemeden önce BurpSuite yazılımımı çalıştırıyorum. Tarayıcımda Proxy ayarlarını da yaptıktan sonra artık ürünümü sepete ekleyebilirim. Ürünü sepete ekledikten sonra burp’e dönelim. HTTP History kısmından POST /cart isteğini inceleyelim. Aşağıda da gördüğünüz üzere çeşitli parametreler bizi karşılıyor. Burada “quantity” parametresinin aldığımız ürünün adedini verdiğini anlıyoruz.
quantity parametresi
Şimdi sepete ekleme işlemini tekrarlayalım. Fakat bu sefer isteği sunucuya göndermeden önce yakalayarak “quantity” parametresindeki değeri değiştirmeye çalışalım.
Sepete ekleme işlemini tekrarlayıp isteği yakaladığımda yine aşağıdaki gibi bir istekle karşılaşıyorum. Fakat bu sefer “quantity” parametresini 5’e eşitledim.
parametre değerinin değiştirilmesi
Şimdi isteği gönderelim. Bakalım sepetimize aynı üründen +5 adet eklenecek mi?
İsteği gönderip sepetimi görüntülediğimde sepetimde daha önceki işlemle beraber toplamda 6 adet “All-in-One Typewriter” ürünü olduğunu görüyorum. Demek ki yaptığımız değişiklik sunucuda tekrar kontrol edilmeden işleme alındı ve isteği değiştirerek aynı üründen +5 adet daha ekleyebildim.
sepet
Şimdi sepetimi temizliyorum. Çünkü aklıma ürün adedini negatif bir değer yapmak geliyor. Bu sayede ücreti de negatif bir değere düşürebilmiş olacağım. Aynı ürünü sepetime tekrar ekleyip burp ile giden isteği yakalıyorum ve quantity parametresinin değerini -39 yapıyorum.
negatif değer verme
isteği yollayıp sepetimi görüntülediğimde karşımdaki manzara aşağıdaki gibi oluyor. Gördüğünüz gibi aynı üründen sepetime -39 adet eklemiş görünüyorum.
sepet – 2
Şimdi ise almak istediğimiz ürünü sepete normal bir şekilde ekleyelim. PortSwigger görevine göre hareket ettiğimizde bizden “Lightweight l33t leather jacket” isimli ürünü istenmeyen bir fiyattan almamız söyleniyor. Bu sebeple “Lightweight l33t leather jacket” isimli ürünü sepetime ekledim ve sepetimin son hali aşağıdaki gibi oldu.
sepetin son hali
Yani mağazadaki fiyatı 1337$ olan bir ürünü Business Logic zafiyetini sömürerek 19,97$‘a almış oldum.
sipariş onaylandı
BUSINESS LOGIC ZAFİYETLERİNİN OLUŞMASI NASIL ÖNLENİR ?
- Kullanıcı davranışı veya uygulamanın diğer bölümlerinin davranışı hakkında üstü kapalı varsayımlarda bulunmaktan kaçının. Bu hatalı varsayım ihtimalini düşürecektir.
- Geliştiricilerin ve test uzmanlarının, uygulamanın hizmet verdiği etki alanını anladığından emin olun
- Her aşamada yapılan varsayımları not ederek tüm işlemler ve iş akışları için net tasarım belgeleri ve veri akışları sağlayın.
- Geliştiricilerin kodu olabildiğince anlaşılır yazdığından emin olun. Karmaşık yazılan kodlar mantık kusurunun tespit edilmesini zorlaştıracaktır.
PRATİK ÇALIŞMALARI İÇİN DİĞER ÖRNEK SENARYOLAR
- https://portswigger.net/web-securit...flaws-excessive-trust-in-client-side-controls
- https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-low-level
- https://portswigger.net/web-securit...ws-inconsistent-handling-of-exceptional-input
- https://portswigger.net/web-securit...ab-logic-flaws-inconsistent-security-controls
- https://portswigger.net/web-securit...gic-flaws-weak-isolation-on-dual-use-endpoint
- https://portswigger.net/web-securit...-logic-flaws-insufficient-workflow-validation
- https://portswigger.net/web-securit...uthentication-bypass-via-flawed-state-machine
- https://portswigger.net/web-securit...ic-flaws-flawed-enforcement-of-business-rules
- https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-infinite-money
- https://portswigger.net/web-securit...s-authentication-bypass-via-encryption-oracle
Bu yazımızın da sonuna geldik. Başka başlıklarda görüşmek dileğiyle…
Moderatör tarafında düzenlendi: