Güvenli uygulamaların en büyük rakibinin karmaşıklık olduğu bir sır değil. Web uygulamaları daha karmaşık hale geldikçe mantık hatalarının ortaya çıkması için sayısız fırsat yaratıyor. Kolayca otomatikleştirilebilen teknik güvenlik açıklarından farklı olarak iş mantığı hataları, geliştiricilerin sistemlerin nasıl davranmasını beklediği ile saldırganların bunları nasıl manipüle edebileceği arasındaki boşluktan ortaya çıkar.
Bu makalede, kısıtlamaları aşmak, ayrıcalıkları yükseltmek ve istismar edilebilir davranışları ortaya çıkarmak için iş mantığı kusurlarını nasıl belirleyeceğimizi ve bunlardan nasıl yararlanacağımızı araştırıyoruz.
Hadi dalalım!
İş mantığındaki güvenlik açıkları, kod tam olarak yazıldığı gibi çalışsa bile, bir uygulamanın iş akışının amaçlanan iş kurallarını ihlal edecek şekilde kullanılması durumunda ortaya çıkar. Bunlar, geliştiricilerin kullanıcıların nasıl davranacağına ilişkin varsayımlarda bulunduğu ancak uç durumları hesaba katamadığı veya karmaşık iş akışları genelinde durum geçişlerini tutarlı bir şekilde doğrulamadığı durumlarda, uygulama ile gerçek davranış arasındaki boşluktan kaynaklanır.
Ancak, tüm belgelenmemiş davranışların mutlaka bir güvenlik açığıyla sonuçlanmayacağını unutmamak önemlidir. Bu nedenle, özellikle hata ödül programlarına katıldığınızda, tanımlanan mantık hatasının ne zaman kuruluş için bir güvenlik tehdidi oluşturduğunu ve ne zaman oluşturmadığını anlamak çok önemlidir.
Bunun için 3 ciddiyet puanlama metriğine göz atmalı ve belirlenen davranışın bunlardan herhangi biri üzerinde etkisi olup olmadığını kendimize sormalıyız:
Gizlilik: Tanımlanan mantık kusuru, normalde erişilemeyen gizli bilgilerin görüntülenmesine izin veriyor mu (örneğin, diğer siparişlerin hassas bilgilerine erişim sağlamak için ödeme sırasında sayısal sipariş kimliğini değiştirebilmek)?
Bütünlük: Tanımlanan mantık hatası, normalde korunan verilerin değiştirilmesine izin veriyor mu (örneğin, davet işlevindeki ilginç bir mantık hatasından yararlanarak hesabınızı başka bir kiracıya atayabilmek)?
Kullanılabilirlik: Tek bir bileşene, hatta uygulamanın tamamına erişimi kısmen veya tamamen reddederek onu kullanılamaz hale getirebilir misiniz (örneğin, bir kiracı içinde, uygulamayı sürekli olarak çökertecek ve platformu kullanılamaz hale getirecek geçersiz bir kayıt oluşturmak)?
Bu soruları yanıtlamak, gerçek bir güvenlik zayıflığıyla mı yoksa basit, işlevsel bir hatayla mı karşı karşıya olduğunuzu belirlemenize yardımcı olacaktır. Birkaç pratik örneğe daha göz atın:
Karmaşık bir erişim matrisi. İzin profilleri kurumsal uygulamalarda önemlidir. Bileşen ve kullanıcı başına ayrıntılı izin kontrollerinin gerekliliği, karmaşıklığı ciddi şekilde etkiler ve genellikle karmaşık izin profilleri kullanıldığında erişim kontrolü güvenlik açıklarına neden olur.
İş kurallarının eksik doğrulanması. Geri ödeme sistemi, bir siparişin mevcut olup olmadığını kontrol edebilir ancak zaten geri ödeme yapılıp yapılmadığını kontrol edemez; bu da mükerrer geri ödemelere izin verir. Her ne kadar bu tür hassas işlemsel işlemler için insan katılımı gerekli olsa da, kuruluşlar bazen tamamen otomatik sistemlere güvenmeye zorlanır ve bu da geniş ölçekte finansal dolandırıcılık olasılığını ortaya çıkarır.
İstemci tarafı verilerine güvenme. Sunucu tarafı doğrulaması olmadan kullanıcı tarafından sağlanan fiyatlara, para birimine, miktarlara veya kullanıcı kimliklerine dayanan uygulamalar kendilerini potansiyel manipülasyona açık hale getirir. Sunucu tarafı doğrulamanın olmaması, (No)SQLi, XXE, SSRF ve XSS gibi enjeksiyon saldırılarına da izin verebilir.
Kritik operasyonlarda yarış koşulları. Hesap bakiyesi kontrolü uygun şekilde kilitlenmediğinde, kredili mevduatlara izin verilmediğinde, eşzamanlı iki para çekme talebinin her ikisi de başarılı olabilir.
Hatalı devlet yönetimi. Ödeme akışları gibi çok adımlı süreçler, kullanıcıların adımları atlamalarına, adımları yeniden yürütmelerine veya ulaşmamaları gereken durumlara erişmelerine olanak tanıyarak, örneğin bir satın alma işleminin ödeme yapılmadan tamamlanmasına olanak sağlayabilir.
İstismar edilemez davranış örnekleri
Daha önce de belirtildiği gibi, tüm mantık kusurları güvenlik zaafı olarak değerlendirilmez. Bazıları yalnızca daha fazla iletilemeyecek tuhaf davranışlar sergiler ve genellikle dahili QA testleri sırasında tespit edilemeyen işlevsel hatalardır.
Kuruluş için güvenlik tehdidi oluşturduğu düşünülemeyecek birkaç pratik örneğe bakalım:
Uygulamanın ön ucunun değiştirilmesini engellemesine rağmen yalnızca size ait olan verileri değiştirmek. Bu davranış her zaman bir güvenlik zafiyeti teşkil etmeyebilir. Kısıtlanmış giriş alanlarını bir proxy müdahale aracı aracılığıyla değiştirmeyi başarsanız bile etki hala sınırlıdır. Ancak bu, XSS veya SQLi gibi enjeksiyon saldırılarına izin verebilecek tutarsız giriş doğrulamasını kontrol etmemiz için bir fırsattır.
Yetkiyi veya parayı etkilemeyen yanlış hesaplamalar. Yakılan kaloriler gibi keyfi değerler sağlamanıza yardımcı olan bir fitness uygulaması veya hesaplamaları keyfi olarak değiştirilebilen kişisel puanlama sistemine sahip bir e-öğrenme platformu.
Performans veya verimlilik sorunları. Sınırsız sayıda veri nesnesi oluşturma yeteneği, bunun tek etkisi istemci tarafında performansın (biraz) düşmesidir.
Daha önce bahsedilen örneklerin tümü, gerçek bir güvenlik etkisi olmayan mantıksal kusurların örnekleridir. Bazı kuruluşların bu tür kusurların farkında olmak isteyebileceğini, diğerlerinin ise bunları kabul edilmiş riskler olarak kabul edeceğini unutmamak önemlidir.
Kullanılabilir mantık kusurları vs Kullanılamaz davranış
İstismar edilebilir mantık kusurlarını istismar edilemeyen mantık kusurlarından doğru bir şekilde ayırt etmek için, gerçek bir saldırganın tanımlanan davranıştan ne şekilde yararlanabileceğini her zaman sormalısınız.
Örneğin, eskisinden daha fazla ayrıcalığa sahip olabilir misiniz? Tanımlanan davranış enjeksiyon saldırılarına izin veriyor mu (örn. tutarsız giriş doğrulaması nedeniyle)? Niteliği itibarıyla hassas olan ve varsayılan olarak yasaklanan eylemlerin (örneğin, tek bir ürün için birden fazla para iadesi talep edilmesi) gerçekleştirilmesi mümkün müdür? Belirli bir kaynağa veya uygulamaya erişimi reddedebilir misiniz (örn. uygulama içi hizmet reddi yoluyla)?
Artık mantık kusurlarının ne olduğu (ve nelerin bu şekilde değerlendirilemeyeceği) konusunda temel bir anlayışa sahip olduğumuza göre, bu zayıflıklardan yararlanmaya devam edebiliriz.
İzin profilleri web uygulamalarında o kadar da nadir değildir. Tek bir kiracı içindeki kullanıcılar veya gruplar için izinleri ayarlamak üzere bir yönetici hesabı sağlarlar. Ancak izinler ne kadar ayrıntılı tanımlanırsa işler o kadar karmaşık hale gelir. Bu, özellikle tek bir kullanıcı veya kullanıcı grubuna birden fazla izin kuralı uygulandığında, bozuk erişim kontrolü sorunlarının ortaya çıkmasına neden olabilir.
Başka bir örnek, istenmeyen davranışlar ortaya çıktığında erişim kontrollerinin uygulanmamasıdır. Aşağıdaki kod parçasını dikkate alın. Sorunu fark edebiliyor musun?
Erişim kontrollerinin bozulmasına izin veren mantık hatası güvenlik açığı
Yukarıdaki kod parçacığında, ödeme onay yolunun, oturum nesnesindeki sipariş kimliğine göre sipariş bilgilerini aldığını görebiliriz. Ödeme sürecindeki bir önceki adıma daha yakından baktığımızda sipariş ID’sinin order_initiation_id body parametresinden okunduğunu fark edebiliriz. Buradaki sorun, geliştiricilerin bu sipariş kimliğinin benzersiz olduğundan, var olmadığından ve en önemlisi mevcut müşteriye ait olduğundan emin olmak için doğrulamayı asla düşünmemiş olmalarıdır.
Bunu akılda tutarak, ayarlayabiliriz. order_initiation_id istediğimiz herhangi bir değere göre satın alma işlemini tamamlayabilir ve muhtemelen diğer müşterilerin gizli verilerine erişebiliriz.
Tutarsız giriş doğrulaması genellikle enjeksiyon saldırılarına yol açar. Bunu aklınızda tutarak, giriş doğrulamanın sınırlı olduğu veya mevcut olmadığı yerlere dikkat etmelisiniz. Aşağıdaki örneği dikkate alın.
Aşağıdaki uygulama XSS, SSTI veya SQLi verileri içeren hatalı biçimlendirilmiş e-posta adreslerine izin vermeyecek şekilde tasarlanmıştır.
Enjeksiyon saldırılarına izin veren mantık hatası güvenlik açığı
Ancak kaydolduktan sonra, tüm pazarlama e-postalarının aboneliğinden çıkmaya karar verirsiniz ve burada e-postanızı değiştirmek de dahil olmak üzere tüm e-posta tercihlerinizi yapılandırmanıza olanak tanıyan yeni bir portal sunulur. Aynı portal, değişiklikleri ana uygulamayla senkronize ederse, girişinizi hiçbir şekilde doğrulamayabilir ve önceki girişimimize benzer şekilde e-postanızı bir veri yükü içerecek şekilde değiştirmenize izin verebilir:
SSTI saldırılarına izin veren mantık hatası güvenlik açığı
Bu tutarlı giriş doğrulama eksikliği, yukarıdaki örnekte gözlemlediğimiz gibi enjeksiyon saldırılarına izin verebilir.
Enjeksiyon saldırılarına benzer şekilde, mantık kusurları da öncelikle kullanıcı parametrelerinin yanlış işlenmesi nedeniyle fiyat manipülasyonu güvenlik açıklarına neden olabilir. Aşağıdaki örneğe bir göz atın. Zayıflığı tespit edebilir misiniz?
Fiyat manipülasyonuna izin veren mantık hatası güvenlik açığı
Yukarıdaki kod parçacığında şunu görebiliriz: 15. satırpara birimi kodu kullanıcı tarafından kontrol edilebilen bir kaynaktan okunur. Ancak kodu daha yakından incelediğimizde ödeme fiyatını hesaplamaktan sorumlu olan kodun bunu hesaba katmadığını görebiliriz. Bunun yerine, ödemeyi tamamlamak için bu değeri başka bir doğrulama olmaksızın üçüncü taraf ödeme ağ geçidine iletir.
Pratik olarak bu, para birimi kodunu şuradan ayarlayabileceğimiz anlamına gelir: USD ile JPY ve ödeme fiyatımızı düşürün.
Bahsi geçen kusur, kötü niyetli alıcıların satılan ürünleri yüksek oranda indirimli fiyatlarla satın almasına olanak tanıyan basit bir dikkatsizlikten kaynaklanmaktadır.
Mantık hataları, örneğin zayıf rastgele oluşturma veya hassas belirteçlerin güvenli olmayan şekilde depolanması nedeniyle kriptografik kusurlara da yol açabilir. Yanlış işlem aynı zamanda güvenlik açıklarını da açarak saldırganların tamamen yeni tokenleri tahmin etmesine veya oluşturmasına olanak tanıyabilir.
Bu tür kusurlara bir örnek, JSON Web Token uygulamalarında none algoritmasının desteklenmesidir. Bir örneğe daha yakından bakalım.
JWT Hiçbiri algoritma saldırısı
Açık 27. satırgeliştiricinin, bir saldırganın kimliği doğrulanmış bir uç noktaya imzasız bir JWT belirteci gönderdiği senaryoyu nasıl hesaba katmadığını yakından gözlemleyebilirsiniz. Uygun işlem yapılmaması, bu örnekte tam kimlik doğrulamanın atlanmasıyla sonuçlanan bir dikkatsizlikten kaynaklanmaktadır.
Bu tür durumları test etmek için geliştiricilerin uygulamalar içindeki belirli işlevleri geliştirmek için kullandıkları ortak uygulama yollarını anlamaya çalışmalısınız.
İş mantığı kusurları, araştırmacıdan hedef hakkında belirli bir düzeyde deneyim ve bilgi talep ettiğinden sıklıkla zayıflar ve bu nadiren sağlanır. Bu makalede, mantık kusurlarını test etmenin önemini ve bu zayıflığın nasıl etkili güvenlik açıklarına yol açabileceğini araştırdık.
Demek iş mantığı kusurlarını aşma konusunda yeni bir şey öğrendiniz… Şu anda becerilerinizi test etme zamanı! Savunmasız laboratuvarlar ve CTF’ler üzerinde pratik yaparak başlayabilir veya… Intigriti’deki 70’ten fazla genel hata ödül programımıza göz atabilirsiniz ve kim bilir, belki bir sonraki gönderiminizde bir ödül kazanabilirsiniz!