Sızan API Anahtarları ve Sırlar: GitHub, .env ve Frontend Sızıntıları, Etkileri ve Önleme
Bir API anahtarı, veritabanı parolası ya da gizli token, koda gömülü kaldığında ya da yanlışlıkla GitHub'a, frontend paketine veya bir yedeğe sızdığında, saldırganlar bunu dakikalar içinde bulur. Sonuç bulut hesabınızın ele geçmesi, veri ihlali ve yüksek faturalar olabilir. Sızan anahtarların nasıl bulunduğunu, etkilerini ve sır yönetimi ile nasıl önleneceğini kaynaklı anlattık.
Sızan API Anahtarları ve Sırlar: GitHub, .env ve Frontend Sızıntıları, Etkileri ve Önleme
Hızlı Cevap: Sır sızıntısı, bir API anahtarının, veritabanı parolasının, gizli tokenin ya da özel anahtarın erişilebilir bir yere düşmesidir. En sık üç yerden sızar, birincisi koda gömülüp GitHub gibi bir kod deposuna gönderilmesi, ikincisi frontend (tarayıcı) paketine ya da mobil uygulamaya gömülmesi, üçüncüsü bir yedeğin, log dosyasının ya da yanlış yapılandırmanın açığa çıkması. Saldırganlar bu anahtarları elle aramaz, GitHub ve internet genelini otomatik tarayan botlarla dakikalar içinde bulurlar. Etkisi ağırdır, sızan bir bulut anahtarıyla saldırgan sunucularınızı ele geçirebilir, veritabanınızı okuyabilir ya da adınıza yüksek faturalar biriktirebilir. Önlemenin yolu üç ilkedir, sırrı asla koda gömmemek (bir sır kasası ya da ortam değişkeni kullanmak), depoyu ve paketleri sır tarayıcılarla denetlemek, ve bir sır sızarsa hemen iptal edip yenilemek (rotasyon).
Modern uygulamalar onlarca dış servise bağlanır, ödeme, e-posta, bulut, yapay zeka. Her bağlantı bir anahtar gerektirir, ve bu anahtarlar uygulamanın en değerli sırlarıdır. Bir anahtarı sızdırmak, evinizin anahtarını sokakta bırakmak gibidir. Kaynak kodun bütünsel güvenlik denetimini ve sır taramasının nerede durduğunu kaynak kodu güvenlik denetimi, SAST, DAST, SCA yazımızda anlattık. Bu yazı özellikle sır sızıntısına, yani en sık ve en ucuz istismar edilen açıklardan birine odaklanır.
Sırlar nereden sızar
Sır sızıntısının birkaç klasik kaynağı vardır ve hepsi önlenebilir.
- Kod deposu (GitHub, GitLab). Bir geliştirici, hız için anahtarı doğrudan koda yazar ve sonra bunu depoya gönderir. Depo herkese açıksa anahtar anında görünür, kapalı olsa bile git geçmişinde kalır ve bir sızıntıda ortaya çıkar.
- Frontend paketi. Tarayıcıda çalışan JavaScript koduna gömülen her sır, ziyaretçi tarafından görülebilir, çünkü tarayıcıya inen her şey açıktır. Gizli bir anahtar asla frontend'e konmamalıdır.
- Mobil uygulama (APK). Bir mobil uygulamanın içine gömülen anahtar, uygulama tersine mühendislikle açıldığında çıkarılabilir.
- Yedekler, loglar ve yapılandırma. Bir veritabanı yedeği, bir log dosyası ya da yanlış izinli bir .env dosyası, sırları açığa çıkarabilir.
Saldırganlar sızan anahtarları nasıl bulur
Kritik gerçek şudur, saldırganlar bu anahtarları tek tek elle aramaz. GitHub ve internet genelini sürekli tarayan otomatik botlar, belirli anahtar biçimlerini (örneğin bulut sağlayıcılarının anahtar desenleri) arar ve bir eşleşme bulduğunda saniyeler içinde kullanır. Bu yüzden bir anahtar yanlışlıkla bir depoya gönderildiğinde, onu birkaç dakika sonra silseniz bile, bot çoktan bulmuş olabilir. Bir sır bir kez sızmışsa, artık gizli değildir, tek güvenli yol onu iptal etmektir.
Etkileri, tek bir anahtar neye mal olur
Sızan bir anahtarın etkisi, o anahtarın neye eriştiğine bağlıdır, ve çoğu zaman düşünülenden ağırdır.
| Sızan sır | Saldırganın yapabileceği |
|---|---|
| Bulut sağlayıcı anahtarı | Sunucuları ele geçirme, veri silme, adınıza yüksek fatura biriktirme |
| Veritabanı parolası | Tüm müşteri verisini okuma, değiştirme, silme, veri ihlali |
| Ödeme sağlayıcı anahtarı | Sahte işlem, para akışına müdahale |
| E-posta servisi anahtarı | Adınıza toplu oltalama maili gönderme |
| Yapay zeka API anahtarı | Adınıza yüksek kullanım faturası, kota tükenmesi |
| Yönetici tokeni | Sisteme tam erişim, kalıcı arka kapı |
Bir bulut anahtarının sızması, tek başına bir şirketi bitirebilecek bir veri ihlaline yol açabilir. Kişisel veri söz konusuysa bu KVKK kapsamında bir ihlaldir ve bildirim gerektirir, süreci KVKK veri ihlali bildirimi, 72 saat yazımızda anlattık.
Nasıl önlenir, üç ilke
1. Sırrı asla koda gömme. Anahtarlar koddan ayrı tutulmalıdır. Sunucu tarafında ortam değişkenleri (environment variables) ya da bir sır kasası (secret manager, vault) kullanın. Frontend'e ise hiçbir gizli anahtar konmaz, gizli işlemler her zaman sunucu tarafında yapılır.
2. Depoyu ve paketleri tara. Bir sır tarayıcı (secret scanner), kod deposunda ve derlenmiş paketlerde sızmış anahtar desenlerini otomatik arar. GitHub gibi platformlar yerleşik gizli tarama sunar, ve derleme hattınıza bir tarama adımı ekleyerek sırların depoya girmeden yakalanmasını sağlayabilirsiniz. Bu, kaynak kod denetiminin doğal bir parçasıdır.
3. Sızarsa hemen iptal et ve yenile (rotasyon). Bir sır sızdıysa, en önemli adım onu hemen iptal edip yeni bir anahtarla değiştirmektir. Anahtarların düzenli olarak yenilenmesi (rotasyon) ve her anahtara yalnızca ihtiyacı olan en dar yetkinin verilmesi (en az ayrıcalık ilkesi), sızıntının etkisini sınırlar.
Bir kez sızan bir anahtarı depodan silmek yeterli değildir, çünkü git geçmişinde kalır ve muhtemelen çoktan kopyalanmıştır. Sızan anahtar her zaman iptal edilmelidir.
Bir sızıntıdan sonra ne yapılır
Bir anahtarın sızdığını fark ederseniz, sırayla, sızan anahtarı hemen iptal edin, yeni bir anahtar oluşturup dağıtın, o anahtarla erişilen sistemlerde şüpheli aktivite olup olmadığını inceleyin, ve git geçmişini temizleyin. Bir saldırganın anahtarı kullanıp kullanmadığını anlamak adli bir incelemedir, loglar üzerinden yetkisiz erişim aranır. Hesap ve sistem ele geçirmenin adli tarafını hesap ele geçirme, account takeover yazımızda ele aldık.
Sıkça Sorulan Sorular
Anahtarı depodan sildim, güvende miyim? Hayır. Anahtar git geçmişinde kalır ve muhtemelen otomatik botlar tarafından çoktan kopyalanmıştır. Tek güvenli yol, anahtarı iptal edip yenisiyle değiştirmektir.
Frontend'e API anahtarı koymak zorundayım, ne yapmalıyım? Gizli bir anahtar asla frontend'e konmamalıdır. Gizli işlemleri sunucu tarafına taşıyın, frontend yalnızca sizin sunucunuzla konuşsun ve gizli anahtar yalnızca sunucuda kalsın.
Kapalı (private) depoda anahtar tutmak güvenli mi? Hayır. Kapalı depolar da sızabilir, erişimi olan biri ayrılabilir ya da hesap ele geçebilir. Sırlar depoda değil, bir sır kasasında ya da ortam değişkeninde tutulmalıdır.
Sızan anahtarı saldırgan kullandı mı, nasıl anlarım? O anahtarla erişilen sistemin loglarında beklenmedik erişim, olağandışı bölgeler ve alışılmadık kullanım aranır. Bu bir adli inceleme konusudur.
Kaynaklar
- OWASP, Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
- CWE-798, Use of Hard coded Credentials: https://cwe.mitre.org/data/definitions/798.html
- GitHub, gizli tarama (secret scanning) belgeleri: https://docs.github.com/en/code-security/secret-scanning
- NIST SP 800-57, anahtar yönetimi önerileri: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
Kodunuzda ve paketlerinizde sızan anahtarları taramak, bir sızıntıyı incelemek ve sır yönetimini kurmak için DSET ile iletişime geçin.
Kimliğinizi doğrulayın
Yetkilendirilmiş erişim alanı. Tüm giriş denemeleri kayıt altına alınır.