Spring Boot /actuator/env sanitizer'ı standart dışı isimli gizli bilgileri atlıyor

Bulgular

dev.to üzerinde paralel olarak İngilizce ve İspanyolca sürümleriyle yayımlanan bir geliştirici incelemesi, Spring Boot'un /actuator/env endpoint'i için yerleşik maskelemesinin yalnızca genel güvenlik sözlüğüyle eşleşen property adlarını koruduğunu, gerçek dünyadaki sızıntıların ise bu kelimeleri içermeyen adlar üzerinden gerçekleştiğini savunuyor.

Gönderiye göre sanitizer, bir property anahtarı password, secret, key, token veya credentials kelimelerini içerdiğinde değeri yıldız işaretleriyle değiştiriyor. Bu kelimeleri içermeyen herhangi bir anahtar — DB_PASSWORD yerine DB_PASS, API_TOKEN yerine API_AUTH ya da WEBHOOK_SIGNING, PARTNER_SHARED_VALUE ve INTERNAL_CIPHER gibi girdiler — tek bir karakteri bile maskelenmeden endpoint'in JSON yanıtına ulaşıyor.

Varsayılanlar neden yetersiz kalıyor

Yazarın iddiası sanitizer'ın kötü yazılmış olduğu değil, tasarımı gereği genel olması: Spring'in geliştiricilerinin öngördüğü kelimeleri kapsıyor, her ekibin gerçekte icat ettiği diyalekti değil. İsimlendirme kararları teslim tarihi baskısı altında alınıyor ve kimse sonradan dönüp bunları bir maskeleme desenine eklemiyor. Yazar, kod incelemesinde tam olarak bu boşluğu gördüğünü bildiriyor: adı hiçbir zaman "secret" kelimesini içermediği için bir staging yapılandırmasında tamamen görünür durumda olan, paylaşılan gizli değer tarzı bir bilgi.

Gönderi ayrıca resmi Spring Boot Actuator belgelerine atıf yapıyor; belgeler değerlerin açığa çıkarılmadan önce sanitize edildiğini ve bu davranışın, son framework sürümlerinde eski anahtar kelime listeli Sanitizer yaklaşımının yerini alan SanitizingFunction arayüzü üzerinden genişletilebilir olduğunu doğruluyor. Belgelerin sağlayamayacağı şey ise projenizin kullandığı adların kataloğu — bu denetim, uygulamayı yapılandıran kişinin sorumluluğunda kalıyor.

Yetkilendirme maskeleme değildir

Yazarın forumlarda ve devralınan yapılandırmalarda tekrar tekrar gördüğü bir reçete, management.endpoint.env.show-values=when-authorized ayarını etkinleştirip sorunun çözüldüğünü düşünmek. Bu ayar kimlerin değerleri görebileceğini düzenler; hangi değerlerin yetkili görüntüleyicilere maskesiz görüneceği konusunda hiçbir şey söylemez. Maliyet, dahili bir rolün — bir izleme servisi veya operasyon panosunun — endpoint'i meşru biçimde okuduğunda ve değişken adı varsayılan deseni kaçırdığı için kimsenin maskelemeyi düşünmediği kimlik bilgileriyle karşılaştığında ortaya çıkar.

Zinciri genişletmek

Gönderide gösterilen çözüm, ekibe özel bir düzenli ifade içeren özel bir SanitizingFunction bean'i — örnekte pass, auth, signing, shared ve cipher kelimeleriyle büyük/küçük harf duyarsız eşleşen bir desen kullanılıyor — eşleşme durumunda maskelenmiş bir değer döndürüyor, aksi halde veriyi olduğu gibi geçiriyor. Spring Boot kayıtlı her fonksiyonu zincir halinde sırayla çalıştırıyor ve bunlardan herhangi biri gerektiğine karar verirse maskeleme uygulanıyor; özel bean, varsayılanların yerine geçmek yerine zincire ekleniyor.

Yazar ilgili bir tuzağa da dikkat çekiyor: üretimde Vault veya AWS Secrets Manager kullanan ekipler, application-staging.yml içinde yine de garip adlandırılmış değişkenler bırakabilir ve devralınan, üzerine yazılmış bir özel regex, hassas adların alt çizgili veya büyük/küçük harf karışık varyantlarını kaçırabilir.

Tekrarlanan hatalar

Gönderi, pratikte görülen birçok başarısızlık modunu listeliyor: yetkilendirme ve sanitizasyonu tek bir ayar olarak görmek; eski bir projeden bir regex'i mevcut ekibin kurallarına uyarlamadan kopyalamak; garip adlandırılmış bir değişkenin gerçekten maskelenerek çıktığını doğrulayan bir testi hiç yazmamak; sorunun yalnızca üretim ortamına ait olduğunu varsaymak — oysa staging ve paylaşılan geliştirme ortamları çoğu zaman entegrasyon testleri için gerçek üçüncü taraf kimlik bilgileri barındırır; ve bir Spring Boot sürüm yükseltmesinin desen listesini genişleteceğini ummak — oysa framework, sürümden sürüme yalnızca kendi varsayılan anahtar kelimelerini korur.

Neden önemli

Yazarın en keskin sonucu şu: bakımsız bir özel sanitizer, hiç olmamasından daha kötü olabilir, çünkü kapsama yokken güven üretir. Kimse periyodik olarak kodda hangi property adlarının göründüğünü denetlemiyorsa, /actuator/env'yi tamamen devre dışı bırakmak daha güvenli bir karardır. Actuator endpoint'lerini localhost ötesinde çalıştıran her ekip için pratik çıkarım şudur: her ortam için application.yml ve .env içindeki her anahtarın denetlenmesi, ekibin gerçek adlandırma kurallarını yansıtan bir sanitizer deseni ve alışılmadık adların maskelendiğini kanıtlayan bir test — çünkü düz metin yolu asla kendiliğinden kapanmaz.