Web uygulamaları, saldırganların ihlalleri gerçekleştirmek için kullandıkları en önemli vektörlerdir. Verizon’un “Veri İhlali Araştırma Raporu”na (PDF) göre, incelenen tüm ihlallerin kabaca %70’inin yolu Web uygulamalarıydı.
300’den fazla Web uygulaması sızma testi yaptıktan sonra nedenini anlıyorum. Geliştiriciler, güvenlik açıkları oluşturan aynı güvenlik yanlış adımlarını atmaya devam ediyor. Genellikle güvenli çerçeveler kullanmazlar ve güvenlik kodunu ve kimlik doğrulama işlemlerini kendileri yazmaya çalışırlar.
Ürünleri pazara hızlı bir şekilde sunmak için geliştiricilerin ne kadar baskı altında olduğuna dikkat etmek önemlidir. Mümkün olduğu kadar güvenli olması gerekmese de, olabildiğince hızlı bir şekilde tanıtabilecekleri özellik sayısına göre ödüllendirilirler. Bu, güvenlik kısayollarının kullanılmasına ve ileride Web uygulamalarında güvenlik açıklarına yol açar.
Daha Güvenli Uygulamalar İçin Beş Ders
Pen test uzmanları, şeytanın avukatı rolünü oynar ve uygulama geliştiricilerin saldırganların nereden ve nasıl erişim elde ettiğini göstermek için oluşturdukları şeye tersine mühendislik uygular. Sonuçlar yaygın temel hataları vurguladı. İşte yazılım geliştirme şirketlerinin uygulamalarını daha güvenli hale getirmek için öğrenebilecekleri beş ders.
- Saldırganlar hala siteler arası komut dizisinden (XSS) yararlanıyor. XSS, uzun süredir popüler bir Web uygulaması güvenlik açığı olmuştur. 2021’de, uygulama geliştirme çerçevelerindeki iyileştirmeler nedeniyle Açık Web Uygulaması Güvenliği Projesi (OWASP) ilk 10 listesinden çıktı, ancak yaptığımız neredeyse her sızma testinde hala belirgin.
Genellikle düşük riskli olarak düşünülür, ancak hesabın ele geçirilmesi, veri hırsızlığı ve bir uygulamanın altyapısının tamamen ele geçirilmesi gibi XSS riskleri ciddi olabilir. Birçok geliştirici, olgun girdi doğrulama kitaplığı kullanmanın ve uygun HttpOnly tanımlama bilgisi niteliklerini ayarlamanın yeterli olduğunu düşünür, ancak XSS hataları, özel kod kullanıldığında hala bir yol bulur. Örneğin, WordPress sitelerini ele alalım – bir yöneticiyi hedef alan bir XSS saldırısı kritiktir, çünkü kimlik bilgileri kullanıcının eklentileri yüklemesine izin verir, böylece sunucuda kod benzeri kötü amaçlı yükler yürütür.
- Otomatik tarayıcılar yeterince ileri gitmiyor. Yalnızca otomatik araçları kullanarak Web uygulamalarını tarıyorsanız, güvenlik açıklarının çatlaklardan sızma olasılığı yüksektir. Bu araçlar, hatalı biçimlendirilmiş verileri sistemlere enjekte eden bir yöntem olan bulanıklaştırmayı kullanır, ancak bu teknik yanlış pozitifler oluşturabilir.
Tarayıcılar genellikle modern Web geliştirme ile güncel değildir ve JavaScript tek sayfa uygulamaları, WebAssembly veya Graph için en iyi sonuçları sunmaz. Karmaşık güvenlik açıkları, bunları doğrulamak için el yapımı bir yüke ihtiyaç duyar ve bu da otomatikleştirilmiş araçları daha az etkili hale getirir.
Güvenlik açıklarının ve açıkların en doğru ve ayrıntılı analizi için bir insan unsuru gereklidir, ancak bu tarayıcılar, düşük asılı meyveyi hızlı bir şekilde bulmak için tamamlayıcı bir kaynak olabilir.
- Kimlik doğrulama evde geliştirildiğinde, genellikle çok zayıftır. Kimlik doğrulama, bir Web uygulamasının güvenliğini sağlamak için her şeydir. Geliştiriciler kendi unutulmuş parola iş akışlarını oluşturmaya çalıştıklarında, genellikle bunu en güvenli şekilde yapmazlar.
Kalem testi yapanlar genellikle diğer kullanıcıların bilgilerine erişim elde eder veya rollerine uygun olmayan aşırı ayrıcalıklara sahip olur. Bu, saldırganların kullanıcıları hesaplarından kilitlemesine veya uygulamanın güvenliğini aşmasına olanak tanıyan yatay ve dikey erişim denetimi sorunları oluşturur.
Her şey bu protokollerin nasıl uygulandığı ile ilgili. Örneğin, Güvenlik Onayı İşaretleme Dili (SAML) kimlik doğrulaması, güvenliği artırmanın bir yolu olarak giderek daha popüler hale gelen tek oturum açma protokolüdür, ancak bunu yanlış uygularsanız, kilitlediğinizden daha fazla kapı açmış olursunuz.
- Saldırganlar, iş mantığındaki kusurları hedefler. Geliştiriciler, bir müşterinin kullanım senaryosunu gerçekleştirip gerçekleştirmediklerini belirlemek için özelliklere bakar. Bir saldırganın bu özelliği kötü amaçla nasıl kullanabileceğini belirlemek için genellikle merceğin diğer tarafından bakmıyorlar.
Harika bir örnek, bir e-ticaret sitesi için alışveriş sepetidir. İş açısından kritiktir, ancak çoğu zaman güvenli değildir; bu da ödeme sırasında toplamın sıfırlanması, ödeme sonrasında ürün eklenmesi veya ürünlerin diğer SKU’larla değiştirilmesi gibi ciddi güvenlik açıkları oluşturur.
Geliştiricileri, birincil kullanım senaryosuna odaklandıkları ve diğer, tipik olarak hain kullanımları tanımadıkları için suçlamak zordur. Performansları, özelliği sunmaya dayalıdır. Yöneticilerin madalyonun diğer yüzünü görmeleri ve iş mantığının güvenlik mantığıyla ilişkili olması gerektiğini anlamaları gerekir. Alışveriş sepeti veya kimlik doğrulama iş akışı gibi en yüksek iş değerine sahip özellikler muhtemelen genç bir geliştiricinin işi değildir.
- İyi bir penetrasyon testinde “kapsam dışı” yoktur. Web uygulamaları, içine giren kaynak ve varlık sayısına bağlı olarak hızla karmaşık hale gelebilir. Ana uygulamanın işlevselliğini sağlayan arka uç API sunucularının dikkate alınması gerekir.
Tüm bu harici varlıkları ve bunların geliştiricilerin oluşturdukları şeyle nasıl bağlantı kurduklarını sızma testleri yapan güvenlik denetçileriyle paylaşmak önemlidir. Geliştirici, bu varlıkların “kapsam dışı” olduğunu ve dolayısıyla bunlardan sorumlu olmadığını düşünebilir, ancak bir saldırgan kumdaki bu çizgiye saygı göstermez. Sızma testlerinin gösterdiği gibi, hiçbir şey “kapsam dışı” değildir.
Bir Denge Sorusu
Yazılım geliştirme şirketleri bu yaygın risklerden bazılarını önceden anladığında, güvenlik denetçileriyle daha iyi ilişkiler kurabilir ve sızma testlerini daha az sancılı hale getirebilir. Hiçbir şirket geliştiricilerini geride tutmak istemez, ancak geliştiriciler, yaratıcılığı güvenlik çerçeveleriyle dengeleyerek nerede özgürlükleri olduğunu ve uygulamaları güvende tutan korkuluklarla nerede uyum sağlamaları gerektiğini bilirler.