Use of Hardcoded Password Açıklığı (CWE-798) (CWE-259)
Bu makalede Use of Hardcoded Password (CWE-798) (CWE-259), yani Kodda Açık Bir Şekilde Parola Bulundurulması, diğer ifadeyle Koda Şifre Yazılması açıklığı anlatılacaktır.

Açıklık Önem Derecesi:

Düşük

Açıklığın Etkisi:

Hassas Bilgilere Yetkisiz Erişim, Bilgi İfşası, Sızma girişimlerinde saldırının boyutunun artması

Açıklığın Açıklaması:

Uygulama geliştiricileri uygulama kaynak kodlarına parola bilgisi gömebilmektedirler. Bu hassas veriler kimlik bilgilerini doğrulama, bir web api hizmetine istek yapma (api key) v.b. nedenler için yer alabilir. Güvenliğe derinlikli defans (depth of defence) perspektifinden yaklaşacak olursak kaynak kodda bu tarz hassas verilerin açık bir şekilde yer alması güvenlik riski teşkil etmektedir.

Uygulama güvenliğinde temel esas saldırganların içeriye hiçbir şekilde girememesidir. Fakat bazen güvenlik ne kadar üst seviyede olursa olsun saldırganın içeri girmesi devasa bir yüzeyde sadece bir boşluk yakalamasına bakabilmektedir. Dolayısıyla güvenliği daha garanti hale getirmenin yolu güvenliğe katman stratejisiyle yaklaşmaktan geçer. Bu ise örneğin uygulamanıza veya ağınıza gelecekte olası bir sızma girişimi yapıldığında şayet girişim başarılı olursa saldırganın içerideyken verebileceği zararı minimize edecek, belki de tam manasıyla sıfırlayacak iç katmanınızdaki güvenliğinizle mümkündür. Uygulama sunucunuza sızıldığı senaryoyu ele alacak olursak saldırgan örneğin uygulama kaynak kodunu okuyarak oturum açma kullanıcı adı ve şifre bilgilerini veya web servis erişim bilgilerini (api anahtarını), v.b. ele geçirebilir. Bu sayede belki sadece web sunucu içerisinde uygulamanın kök dizininde sıkışıp kalacakken şimdi edindiği bilgi doğrultusunda uygulamanın saklı arayüzlerine atlama yapabilir veya diğer bağlantı noktası web servise erişebilir. Uygulama üzerinden yetki ölçüsünde bu şekilde daha da ilerleyebilir ve uzanabildiği ölçüde atlamalar yapabilir.

Uygulamanızın deployment metoduyla servis edildiği durumu ele alacak olursak ve saldırganın yine web sunucunuza sızdığını düşünecek olursak saldırganın uygulama kök dizininde sadece deploy edilmiş web uygulamanızı görmesi onu engellemeyecektir. Saldırgan edindiği deploy edilmiş uygulama dosyalarına tersine mühendislik araçları (örn; Microsoft Documents resmi web sitesinde bahsedilen Ildasm.exe (IL Disassembler) aracını) kullanarak içerlerinde şifre addedilebilecek string taraması yapabilir ve kritik verileri yine elde edebilir. Ayrıca eğer saldırgan parola bilgisini ele geçirecek olursa bu parola uygulamanın yeni bir sürümü derlenmediği sürece (yani parola kolayca değiştirilemeyeceğinden) kötüye kullanımı devam edecektir. Dahası eğer bu uygulama sayısız sisteme komple veya modül olarak dağıtılırsa sistemin çalınan parolası otomatik olarak dağıtılan tüm sistemlere girilmesine olanak verecektir. Dolayısıyla bu v.b. bilgi toplamalar ile saldırganların derine inme ihtimallerini engellemek / asgariye çekmek için kaynak kodlardaki parola hassas verisinin saklanması önerilmektedir.

Microsoft resmi sayfası der ki:

"Uygulama kodlarına gömülen bağlantı string'leri güvenlik zafiyetlerine ve bakım problemlerine yol açabilmektedir. Uygulamanın kaynak kodu içerisinde derlenmiş şifrelenmemiş bağlantı string'leri Ildasm.exe (IL Disassembler) aracı kullanılarak görüntülenebilir. Dahası her bağlantı string değişimi gerektiği zaman uygulamanız tekrar tekrar derlenmek zorunda kalabilir. Bu nedenlerden dolayı uygulama içerisinde depolu olan bağlantı string'lerinin uygulama yapılandırma dosyasına taşınmasını önermekteyiz." (https://docs.microsoft.com, 03/30/2017)

Uygulama parolaları açık metin olarak kaynak kodlarda yer aldığında "Use Of Hardcoded Password" açıklığı olarak işaretlenirler. Uygulamalardaki bu açıklığa şöyle bir örnek verilebilir:

Java - Güvensiz Kod: 

bool isAdmin(String username, String password) {

    bool isMatch = false; 
    
    if (username.equals("admin")) {
        if (password.equals("P@ssw0rd"))
            return isMatch = true;
    }
    
    return isMatch;
}

Bu örnekte kullanıcı kimlik doğrulaması yapılmaktadır ve parola kıyaslamasındaki geçerli parola hardcoded (açık bir şekilde) yer almaktadır. Bu güvensiz bir kullanımdır. Güvenli hale dönüştürülmüş hali ise şu şekildedir:

Java - Güvenli Kod: 

bool isAdmin(String username, String password) {

    bool adminPrivs = false;
    
    if (authenticateUser(username, password)) { 
        UserPrivileges privs = getUserPrivileges(username);
        
        if (privs.isAdmin)
            adminPrivs = true;
    }
    
    return adminPrivs;

}

Bu güvenli kullanım örneğinde yapılan kimlik doğrulamada geçerli parola hardcoded (açık bir şekilde) yer almamaktadır. authenticateUser() metodu gelen kullanıcı adı ve parolayı içerisinde veritabanından geçerli kullanıcı adı ve parola bilgilerini çekerek kıyaslamaktadır.

Uygulamalardaki bu açıklığa bir başka örnek olarak şu da verilebilir:

Javascript - Güvensiz Kod: 

// [Vulnerable] Hardcoded Account Password

var username = request.body.username;
var password = request.body.password;
var admin_username = "admin";
var admin_password = "5up3r53cr3t";

if (username == admin_username && password == admin_password) {
    // Authenticate
}
else {
    // Reject
}

Bu örnekte yine kullanıcı kimlik doğrulaması yapılmaktadır ve parola kıyaslamasındaki geçerli parola hardcoded (açık bir şekilde) yer almaktadır. Bu güvensiz bir kullanımdır. Güvenli hale dönüştürülmüş hali ise şu şekildedir:

Javascript - Güvenli Kod: 

// [SECURE] Authenticating by Querying the Database with Credentials

var username = request.body.username;
var password = secureHashImplementation(request.body.password);

connection.query('SELECT * FROM users WHERE name=? AND hashed_password=?',[username, password], function(err,results) {

    if (error) {
        // handle error
    }
    if (results.length == 1) {
        // Authenticate
    }

});

Bu güvenli kullanım örneğinde yapılan kimlik doğrulamada geçerli parola hardcoded (açık bir şekilde) yer almamaktadır. Parola veritabanında hash’li bir şekilde yer almaktadır. Kimlik doğrulamada kullanıcıdan gelen parolanın önce hash’i alınmaktadır ve sonra veritabanına sorgu yapılarak kullanıcı adı ve parola hash’i kıyaslanmaktadır.

Parola v.b. hassas veriler kaynak koda gömülmemelidirler. Diğer türlü kaynak kodda açık bir şekilde parola bulundurulması açıklığı şeklinde ele alınırlar. Bu açıklıktan her çeşit uygulama etkilenir. Fakat “özellikle” dağıtılan uygulamalar (yani masaüstü uygulamalar, router firmware uygulamaları, firewall firmware uygulamaları, yazıcı firmware uygulamaları v.b.) veya açık kaynak kodlu uygulamalar daha çok etkilenir.

Eğer şu sorulardan herhangi bir tanesine evet deniyorsa kurum uygulama tarif edilen bu açıklıktan etkileniyordur:

  • Kaynak koddaki hesap bilgileri hassas bir bileşene mi erişim izni veriyor (örn; Bir veritabanına, bir dosya depolamasına, bir API’ye veya bir servise) ?

  • Kaynak koddaki hesap bilgileri production (yayın) ortamında mı kullanılıyor?

  • Kaynak koddaki hesap bilglerini güncellemeden önce uygulamayı yeniden dağıtmak mı gerekiyor?

Uygulama kaynak kodlarında açık bir şekilde parola olunca;

  • Nadiren değişecekleri için güvenlik noktasında daha az güvenlidirler.

  • Kodda açık metin halinde yer aldıklarından çok görünürdürler. Eğer kötü niyetli bir kimse (öreğin harici bir kurum çalışanı) bunları görürse (uygulama admin parolaları, web api parolaları gibi) uygulama risk altına girer.


Açıklığın Önlemi:

“Kullanıcı parolaları” veritabanında veya bir dizin hizmetinde (linux veya windows directory service’te - örn; Active Directory’de) güçlü bir tek yönlü şifreleme algoritması (örn; bcrypt, scrypt, PBKDF2 veya Argon2 v.b.) ile şifrelenerek tutulmalıdır. Kullanıcı parola kıyaslamalarında kullanıcı taraflı gelen parola aynı tek yönlü şifreleme algoritması kullanılarak şifrelenmelidir ve oluşan hash ile veritabanındaki / dizin hizmetindeki hash kıyaslanmak suretiyle işlemlerin yürütülmesi yolu takip edilmelidir.

“Sistem parolaları” ise bir dosyada (config dosyasında / properties dosyasında,… veya v.b. dosyada) veya veritabanında tersine çözümlenebilir bir şekilde şifrelenerek tutulmalıdır. Şifrelemeyi açmak için bir deşifreleme anahtarı kullanılmalıdır. Şifreleme anahtarları hardcoded (açık bir şekilde) olmamalıdır ve güvenli bir şekilde yönetilmelidir. Uygulama kaynak kodları yapılandırma dosyalarından veya veritabanından sistem parolalarını deşifreleme ile çekerek işlemlerini yürütmelidir.

Yararlanılan Kaynaklar:

  • https://www.owasp.org/index.php/Preventing_LDAP_Injection_in_Java
  • https://www.webguvenligi.org/wp-content/uploads/2007/11/authenticationtrk.pdf
  • https://www.owasp.org/index.php/Use_of_hard-coded_password
  • https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/connection-strings-and-configuration-files
  • https://stackoverflow.com/questions/4227921/how-can-we-have-two-connection-strings-in-web-config-and-switch-betweeen-them-in
  • https://stackoverflow.com/questions/5642474/setting-up-connection-string-in-asp-net-to-sql-server
  • https://www.c-sharpcorner.com/UploadFile/7d3362/various-ways-to-specify-connection-string-in-Asp-Net-web-app/
  • https://www.youtube.com/watch?v=v1EWUAYNA1g
  • https://www.youtube.com/watch?v=Gf3kFBAovXw
  • https://stackoverflow.com/questions/15365210/failed-to-encrypt-the-section-connectionstrings-using-provider-rsaprotectedco
Bu yazı 23.10.2025 tarihinde, saat 04:14:42'de yazılmıştır.
Yazar : Hasan Fatih ŞİMŞEK Görüntülenme Sayısı : 8
Yorumlar
Henüz yorum girilmemiştir.
Yorum Ekle
*
* (E-posta adresiniz yayınlanmayacaktır.)
*
*

#Arşiv

#Giriş
ID :
Şifre :