Neon Data API ve Postgres RLS, 27 saldırılı denetimden geçti; yalnızca 15 dakikalık bir yetki geri alma boşluğu kaldı

The DevOps Daily'in dev.to'daki yazısı, giderek yaygınlaşan bir mimarinin güvenlik denetimini belgeliyor: backend kodu olmayan, tarayıcının yönetilen bir veritabanı uç noktasıyla konuştuğu ve tüm erişim kurallarını Postgres'in uyguladığı bir uygulama. Ekip, statik dosyalardan, Neon Auth ve Neon Data API üzerinden çok kiracılı bir ekip görev panosu oluşturdu, ardından 27 farklı yoldan onu kırmaya çalıştı.

Uygulama sunucusuz nasıl çalışıyor

Makaleye göre tarayıcı statik dosyaları yüklüyor, Neon Auth üzerinden oturum açıyor ve tüm sorguları Neon Data API üzerinden yürütüyor; bu, her istekte JWT'yi doğrulayan ve sorguyu kimliği doğrulanmış bir role göre çalıştıran PostgREST uyumlu bir uç nokta. Ortada bir API sunucusu, serverless fonksiyon veya middleware yok.

Ekipler Neon Auth organizasyonlarına karşılık geliyor. Bir kullanıcı bir organizasyonu etkinleştirdiğinde, verilen token bunu bir claim içinde belirtiyor ve Neon Auth, kullanıcının üyesi olmadığı bir organizasyon için token vermeyi reddediyor. Postgres tarafında bir auth fonksiyonu bu claim'i okuyor, tablo varsayılanları bunu bir org_id sütununa damgalıyor ve her satır bazlı güvenlik politikası bununla karşılaştırma yapıyor. Ayrı bir politika, silme işlemlerini yalnızca imzalı claim'inde owner veya admin rolü taşıyan kullanıcılara izin veriyor.

Sütun bazlı yetkiler ikinci bir savunma katmanı oluşturuyor. Kimliği doğrulanmış rol, tasks tablosunda yalnızca title ve done sütunlarına insert ve update yapabiliyor; org_id ve created_by sütunları token'dan türetilen varsayılanlarla dolduruluyor, yani bir istemci bir satırı asla başka bir kiracıya taşıyamıyor. Anonymous rolünden her şey geri alınmış durumda. Bir dashboard fonksiyonu security definer olarak, çağıranın organizasyonuna sabitlenmiş bir WHERE koşuluyla çalışıyor ve execute yetkisi PUBLIC'ten geri alınmış.

Yirmi yedi saldırı, yirmi yedi ret

Denetim betiği üç kullanıcıyla oturum açıyor: hedef ekibin sahibi alice, onun bir üyesi olan bob; ve rakip bir ekibin, tamamen geçerli bir hesaba sahip sahibi eve. Eve, ilk ekibe 25 farklı yol ve ekip içindeki yanlış rolden iki ayrıcalık denemesi yapıyor. Liste arasında özenle hazırlanmış filtreler, gömülü join'ler, aggregate sayımları, sahte token'lar, bir alg:none token, kendi anahtarıyla imzalanmış bir token, toplu update'ler ve diğer ekibin satır id'lerini hedefleyen upsert'ler var. 27 denemenin tamamı reddedildi.

Doğrulama, yalnızca bir status-code kontrolünden daha sıkı: her saldırı tam olarak beklenen yanıtı döndürmeli ve kurbanın satırlarının her sütunu öncesi ve sonrasıyla karşılaştırılıyor; dolayısıyla sessizce veri değiştiren bir ret dahi testi başarısız bırakırdı.

Bilerek kırmak

Ekip daha sonra dört gerçekçi yanlış yapılandırmayı tek tek devreye soktu. Üçü belirli saldırıların geçmesine izin verdi ve her durumda test paketi gerilemeyi işaretledi. Dördüncüsü — bir insert politikasına özensizce eklenen WITH CHECK (true) — tek başına hiçbir şey sızdırmadı, çünkü yetkiler katmanı istemciye zaten org_id sütununa erişim vermemişti. Ancak bu durum, üzerine daha geniş tablo geneli yetkiler eklendiğinde istismar edilebilir hale geliyor; yazarlar bunu asıl hata olarak tanımlıyor.

Politikaların durduramadığı tek şey: zaman

Bir üyeyi ekipten çıkarmak, tarayıcısında zaten duran token'ı geçersiz kılmıyor. Testte, yeni çıkarılmış bir üye okuma, yazma ve dashboard fonksiyonunu çağırmaya devam etti ve yaklaşık on beş buçuk dakika boyunca okumayı sürdürdü: token'ın 900 saniyelik yaşam süresi artı yaklaşık 28 saniye.

Yazarların gösterdiği çözüm, politikaların içinden Neon Auth'un üyelik tablosuna danışmak; bu, erişimi anında kesti. Medyan maliyet okuma ve yazma için bir milisaniyenin altında, fonksiyon çağrısı için ise yaklaşık 5 ms ekstra oldu. Genel gecikme kayda değer değildi: Data API istekleri medyan değerde 41 ila 44 ms ölçüldü; aynı adrese düz TCP bağlantısı 40 ms sürdüğü için gidiş-dönüş süresinin neredeyse tamamı ağdan kaynaklanıyor, yetkilendirmeden değil.

Neden önemli

Statik bir ön yüz artı PostgREST tarzı bir data API artı satır bazlı güvenlikten oluşan backend'siz desen yayılıyor, çünkü sunucu kodlarının整个 bir sınıfını ve beraberindeki hataları ortadan kaldırıyor. Bu denetim, desene dair teorik bir tartışma yerine nadir görülen deneysel bir doğrulama ve iki ana bulgusu Neon'un ötesine de geçerli. Birincisi, katmanlı savunmalar işe yarıyor: bir politikadaki hata, kiracı sütununu dokunulmaz kılan sütun bazlı yetkiler tarafından sınırlandırıldı. İkincisi, JWT tabanlı yetkilendirme her zaman token'ın yaşam süresine eşit bir geri alma penceresi taşır ve üyelik kontrolünü veritabanına taşımak bu pencereyi yaklaşık bir milisaniyeye mal olarak kapatır. Tam SQL ve saldırı betikleri, benzer bir yığını kullanan veya düşünün herkes için GitHub'da The-DevOps-Daily/neon-data-api-rls olarak yayınlandı.