UYGULAMA GÜVENLİĞİ:
KİMLİK DOĞRULAMA
Uygulama kullanıcılarının kimliklerini teyit etmek ve yetkilerini belirlemek günümüz uygulamalarının işlevselliğini doğrudan etkileyen önemli unsurlardan bir tanesidir. Kişisel ve kurumsal e-posta hesaplarımızın yopmail.com adresleri gibi bütün dünyaya açık olduğu bir dünyada ne ticaret yapabilirdik ne de e-postayı bugünkü haliyle kullanabilirdik. Bu nedenle herhangi bir uygulama geliştirirken kullanıcılarının kimliklerinin teyit edilmesi ve yetkilerinin denetlenmesi son derece önemlidir.
İşlev sorunlarını bir kenara bırakırsak, kimlik doğrulama herhangi bir uygulamanın güvenliğinin ilk aşaması gibi düşünülebilir. A kullanıcısının B kullanıcısına ait bilgilere ulaşması veya C kullanıcısının D kullanıcısı adına işlemler yapmasını bir kenara bırakalım. Herhangi birinin A kullanıcısı gibi uygulamaya giriş yapabilmesi bile başlı başına büyük sorunlar oluşturur.
Kullanıcı kimlik doğrulaması sürecini düşündüğümüzde yerine getirildiğinden emin olmamız gereken birkaç farklı işlev var;
- Kullanıcının kimliğinin doğrulaması
- Başarısız giriş denemelerinin ele alınması
- Başarılı ve başarısız giriş denemelerinin kayıt (log) altına alınması
- Kullanıcının çıkış yapması halinde oturumun imha edilmesi
Belli durumlarda (örn: finans uygulamalarında) kullanıcının oturumunun belli bir sürenin sonunda imha edilip yeniden oturum açılması gerekebilir.
Kullanıcı kimlik doğrulama sürecinin güvenliği düşünüldüğünde bazı tedbirlerin alınması şarttır. İlk akla gelen iki kademeli kimlik doğrulama olsa bile, kullanıcı adlarının korunmasından parola politikalarına kadar geniş bir yelpazedeki önlemler düşünülmelidir.
Uygulama güvenliğinin her alanında olduğu gibi burada da karar büyük ölçüde uygulamanın işlevine, sektörüne veya önem derecesine bağlı olsa da, aşağıdakilerin değerlendirilmesinde fayda olacaktır;
- Güçlü parola kullanımının mecbur tutulması
- Parolaların kullanım sürelerinin belirlenmesi
- “Parolamı unuttum” sürecinin güvenliği
- Güvenli iletişim yöntemlerinin kullanımı
- Uygulama veritabanında tutulan parolalarının şifreli tutulması
Sızma testleri sırasında uygulamaların giriş ekranlarıyla ilgili en sık karşılaştığımız sorunları aşağıda toparladık;
- Şifrelenmeden iletilen hassas bilgiler: Yerel ağda çalışan uygulamaların ya SSL sertifikasının olmaması ya da kendinden imzalı ve tarayıcıda hata veren SSL sertifikası kullanılması.
- Kaba kuvvet saldırılarına açık giriş ekranı: CAPTCHA, süre kısıtlaması, hesap kilitleme, vb. parola tahmin saldırılarına karşı herhangi bir tedbir olmaması
- SQL injection ile kullanıcı giriş sürecinin atlatılması: Kimlik doğrulaması için yapılan veritabanı sorgusuna müdahale edilmesi.
- “Password spraying” saldırılarının öngörülmemesi: 2019 yılında milyonlarca e-posta adresi ve parola internete düştü. Kuruluşların kendilerine ait parolaların ifşa olup olmadığını takip etmesini sağlayacak pek çok yöntem varken bunların kullanılmaması sonucunda ifşa olmuş parolanın yerel ağ uygulamalarında geçerli olması.
- Zayıf parola kullanımı: Password1 de gördük, nail123 de… kullanıcıların kolay tahmin edilebilir parolalar kullanması sonucunda kritik kurumsal uygulamalara giriş yapmak mümkün oluyor
- Zayıf siber güvenlik hijyeni: Fazla söze gerek yok, bkz. Şekil A-1
Daha seyrek de olsa rastladığımız bir iki başlık da şunlar;
- Kullanıcı bölümüne kimlik doğrulamasız erişim
- Tahmin edilebilir oturum çerezi
Son zamanlarda çıkan ve kullanıcı giriş ekranlarını etkileyen bazı zafiyetlere bakarak uygulama geliştirirken bu aşamada dikkat edilmesi gerekenler konusunda fikir sahibi olabiliriz.
phpList 3.5.0: Gevşek karşılaştırma
İki öğe karşılaştırılırken PHP yazılımcıya birkaç farklı seçenek sunar. Projenin yetişmesi gerektiği için veya etkisi gözden kaçırıldığı zaman “gevşek karşılaştırma” sorunları ortaya çıkıyor. Bu zafiyetler aslında uygulamanın yazılımcının ondan yapmasını istediği şeyi yaptığı ancak uygulamanın ve geliştiricinin beklentilerinin farklı olduğu durumlar olarak da özetlenebilir. Bu durumda;
- A == B yazılırsa A ile B’nin EŞİT olması gerekir
- A === B yazılırsa A ile B’nin AYNI olması gerekir.
Phplist 3.5.0 uygulaması kimlik doğrulaması yaparken girilen parolayı veritabanında tutulan parolayla karşılaştırırken aşağıdaki kod satırını kullanıyor;
!empty($passwordDB) && $encryptedPass == $passwordDB
Sorun aşikâr; kullanıcı tarafından girilen parola değerinin veritabanında tutulanla aynı olmasına gerek kalmıyor, eşit olması kimlik doğrulaması için yeterli oluyor.
Bu durumda kullanıcı tarafından belirlenen parola “TyNOQHUS” iken aynı SHA256 (uygulama parolaları SHA256 hash olarak tutuyor) sonucu verecek “34250003024812” parola ile de kullanıcı girişi yapılabilmektedir.
InfiniteWP Client: Yetersiz kontrol
Birden fazla WordPress sitesini yönetmeye imkân veren bu eklentinin 1.9.4.5’ten önceki sürümlerinin kimlik doğrulaması konusunda bazı eksikleri vardı.
Aşağıda görülen sonradan düzeltilen kod parçacığıdır;
İşaretli satıra eklenen “if” kontrolünün amacı bir önceki sürümde eksik olan bir kontrolü yerine getirmektir. Önceki sürümlerde istek doğru yapılandırılmışsa ve burada görülen “add_site” veya “readd_site” isteklerini barındırıyorsa ek kimlik denetimi yapılmadan isteği gönderen kullanıcı giriş yapmış sayılıyordu.
Basit ama can sıkıcı bir hata. Bu nedenle kod içerisinde bulunan ve girdi kabul eden bütün fonksiyonların doğru kimlik doğrulama mekanizmalarını işlettiğinden emin olmakta fayda var.
ZKBioSecurity: Kendine Bile Güvenmeyeceksin
Bina güvenlik yönetimi sistemi olan ZKTeco ZKBioSecurity 3.0 uygulamanın kurulu olduğu makineden gelen talepleri kimlik doğrulamasına gerek duymadan işlemek için bir yöntem belirlemiş. Ziyaretçi defteri, giriş denetimi, güvenlik kamerası yönetimi gibi birkaç farklı modülden oluşan yazılımın buna ihtiyaç duymasının amacı modüller arasındaki iletişimi kolaylaştırmak olabilir.
Kendisine gelen taleplerin çıkış IP adreslerini değerlendiren sistem çıkış IP adresini 127.0.0.1 olarak görürse 123456 parolasıyla otomatik olarak giriş yaptırıyor.
Bu zafiyetin istismarı biraz çaba gerektirse de 123456 gibi basit bir parolanın aşağıda görüldüğü gibi uygulamanın kaynak kodunda bulunması yeterince sıkıntılı bir durumdur.
College Management System:
SQL injection ile giriş 101
Okul yönetim sistemi “College Management System” 1.2 sürümünde bulunan SQL injection zafiyeti saldırganın uygulamaya okul müdürü olarak giriş yapmasına imkan veriyor.
Zafiyeti barındıran kod aşağıdaki gibidir;
Görüldüğü gibi kullanıcıdan alınan “emailid” girdisi işlenmeden/temizlenmeden kimlik doğrulaması için kullanılan SQL sorgusuna dahil ediliyor. Bu durumda saldırganın yapması gereken tek şey sorguya “doğru” yanıtının dönmesini sağlayacak bir değer belirlemek.
Bu durumda uygulamanın asıl sorguladığı şey emailid değerinin olup olmadığıdır. Girilen SQL injection kodunun devamındaki # işareti sorgunun bu noktadan sonrasının yorum olarak değerlendirilmesini sağladığı için parola değeri için ayrıca bir kontrol yapılmaz. Veritabanında da bir değer görmesi halinde bunu doğru kabul edip giriş sağlayacaktır.
Citrix SD-WAN: SQL injection ile giriş 201
Citrix SD-WAN cihazlarının 10.2.3’ten önceki sürümleri üzerinde SQL injection sonucunda kimlik doğrulama süreci tamamen atlatılabiliyordu.
SD-WAN cihazı kendisine gelen JSON taleplerinin giriş yapmış bir kullanıcıya ait olup olmadığını elbette kontrol ediyordu ancak bu kontrolün yapılış şekli SQL injection açığıyla bir araya geldiğinde son derece tehlikeli bir sonuç doğurdu.
Süreci adım adım ele alırsak;
1. SD-WAN’a gelen JSON isteği içerisindeki site adı argümanı kontrol edilmeden/temizlenmeden bir SQL sorgusuna dahil ediliyor
2. SD-WAN single sign-on özelliğinin kullanılıp kullanılmadığını teyit etmek için kullanıcıya ait bir jeton (token) olup olmadığı kontrol ediyor ve yoksa giriş yapmasını istiyor. Varsa işlemi gerçekleştiriyor
3. SD-WAN’ın jetonu aradı dizin olan /tmp içerisinde istenilen özellikte bir jeton oluşturacak bir SQL injection saldırısı yapılıyor (JSON üzerinden site adı argümanından faydalanarak)
4. SD-WAN jeton değerini /tmp dizininde aradığında buluyor ve işlemin yetkili bir kullanıcı tarafından talep edildiği sonucuna varıyor. Aşağıda bu değerlendirmenin yapıldığı kod parçacığını görebilirsiniz:
Kimlik Doğrulama Konusunda Dikkat Edilmesi gerekenler
Kullanıcı giriş işlevinin uygulamanın muhtemelen en görülen ve en sık hedef alınacak yeri olduğu unutulmamalıdır. Bu nedenle giriş ekranlarını oluştururken aşağıdaki noktalara dikkat etmekte fayda olacaktır;
- Kullanıcı girişi için alınan değerler mutlaka temizlenmeli/filtrelenmelidir
- Kullanıcıların güçlü parola kullanmasını zorunlu hale getirmek
- CAPTCHA, vb. yöntemlerle parola tahmin saldırılarının engellenmesi
- İki kademeli kimlik doğrulama yöntemleri ile parola tahmin edilse bile saldırganın giriş yapmasının engellenmesi
- Başarılı ve başarısız giriş denemelerinin kayıt altına alınması
- Oturumların belli sürelerin sonunda bitirilip kullanıcının yeniden giriş yapmaya zorlanması
- Kullanıcı girişi sırasında bağlantının şifreli yapılması, kullanıcı bilgilerinin POST metodu ile gönderilmesi
- Yetkili hesapların giriş ekranın internetten yalıtılması (yapılabiliyorsa)
- Hassas/kritik işlevlerden önce tekrar kimlik doğrulaması istenmesi (uygunsa)
- “Parolamı unuttum” akışının güvenliğinin sağlanması
Kimlik doğrulama sürecinin oluşturulması göründüğünden daha zor olabiliyor. Üstelik, kimlik doğrulama uygulamanın güvenlik seviyesinin en önemli bileşenlerinden birisini oluşturuyor. Bu nedenle uygulama geliştirme telaşının içerisinde zaman ayırıp güvenlik açısından değerlendirmek çok önemlidir.
Daha güvenli uygulamalar geliştirmenize yardım etmek istiyoruz!
Güvenli uygulama geliştirme eğitimleri, danışmanlık hizmetleri ve uygulama sızma testleri için bize sparta@sparta.com.tr adresinden ulaşabilirsiniz.