API Kimlik Doğrulamasında Veritabanına Neden Güvenilmemeli
SQL injection ile hash değiştirerek tenant ele geçirme riski, HMAC-SHA512 pepper imzalama ve çok katmanlı tenancy kontrolleriyle nasıl önlenir, teknik detaylarıyla anlatılıyor.
Bu yazı, API kimlik doğrulamasında veritabanını 'nihai gerçek kaynağı' olarak görmenin gizli ama ciddi bir güvenlik açığı yarattığını gösteriyor. Klasik yaklaşımda API anahtarları hash'lenip veritabanında saklanır; ancak bir saldırgan, herhangi bir SQL injection açığı bularak kurbanın satırındaki hash'i kendi geçerli anahtarının hash'iyle değiştirebilir. Bu durumda saldırgan kendi meşru anahtarını kullanarak kurbanın kimliğine bürünür ve tüm tenant sınırını aşar.
Çözüm olarak Sturdy Statistics, basit hash yerine sunucu tarafında saklanan gizli bir 'pepper' ile HMAC-SHA512 imzası kullanıyor. İmza yalnızca sırrı değil; anahtar kimliği, rotasyon versiyonu ve org-id gibi yapısal bağlamı da kapsıyor. Org-id, URL path parametresinden alınıp imzaya dahil edildiği için, veritabanında hash değiştirilse bile yanlış org-id imzayı geçersiz kılıyor. Pepper hiçbir zaman veritabanına yazılmadığından, tam okuma-yazma erişimi olan bir saldırgan bile geçerli anahtar üretemiyor.
Ayrıca rotasyon versiyonunun veritabanı tetikleyicileriyle yalnızca artabilecek şekilde kilitlenmesi, eski (iptal edilmiş) anahtarların 'zombi' olarak geri getirilmesini engelliyor. Sistem, routing, authentication, application ve database schema olmak üzere dört ayrı katmanda tenancy doğrulaması yaparak 'Defense in Depth' ilkesini uyguluyor. Son olarak, prev-hash ve grace-period alanlarıyla kesintisiz anahtar rotasyonu sağlanıyor; ancak bu esneklik de dikkatli tasarlanmazsa aynı rollback riskini yeniden gündeme getirebiliyor.