Supabase RLS satırları koruyor ama sütunları korumuyor: kullanıcılar kendilerine admin yetkisi verebiliyor

Güvenlik kontrol listesi projesi SniffPup'un dev.to'daki bir yazısı, rutin bir row level security kurulumunu yetki yükseltme açığına dönüştüren bir Supabase tuzağına dikkat çekiyor: RLS policy'leri satır düzeyinde çalışır ve bir update'in hangi alanlara dokunabileceği konusunda hiçbir şey söylemez. role veya is_admin gibi bir yetki göstergesi, kullanıcıların zaten düzenleyebildiği bir profiles tablosunda duruyorsa, oturum açmış bir kullanıcı bunu tarayıcıdan, herkese açık anon key ile değiştirebilir.

RLS satır kapsamlıdır, sütun kapsamlı değil

Supabase'ın istemciye açık tablolar için standart savunması row level security'dir. Tipik bir kurulum, her kullanıcıya profiles tablosunda tek bir satır verir ve satırın yalnızca oturum açan kullanıcıya ait olduğunu kontrol eden bir update policy'si ekler. Bu kontrol, payload'un içeriğinden bağımsız olarak geçer. Görünen adınızı değiştirmek serbesttir; hatalı yapılandırılmış bir tabloda, aynı isteğe privileged bir role değerini eklemek de öyle.

Yetki yükseltme nasıl gerçekleşiyor

Supabase, Postgres veritabanını tarayıcı istemcilerine üretilmiş bir REST API üzerinden sunar; anon key tasarım gereği herkese açıktır ve kapı bekçiliğini RLS yapar. Yazıya göre, kullanıcıların güncelleyebildiği bir tabloda role veya admin sütunu varsa, istemcinin bu sütunu kendi satırına yaptığı bir update'e dahil etmesini hiçbir şey engellemez. Veritabanı açısından bu yazma işlemi meşrudur, çünkü policy yalnızca satır sahipliğini doğrulamıştır, başka hiçbir şeyi değil. Bu sütuna daha sonra bakarak yetkileri belirleyen herhangi bir uygulama mantığı, saldırganı administrator olarak görecektir: çalınmış kimlik bilgisi yok, atlanan policy yok.

Yazının önerileri

Önerilen denetim iki dakika sürüyor: profiles tablosunda role veya admin sütunu olup olmadığını kontrol edin. Varsa iki çözümden birini seçin — update'lere yalnızca güvenli sütunlarda izin verin ya da role verisini kullanıcıların yazamadığı bir tabloya taşıyın. Yazıya eşlik eden sniffpup.com'daki rehber SQL'i de içeriyor. Yazı aynı zamanda açıkça tanıtımcı: SniffPup günlük iki dakikalık bir kontrolü e-posta ile gönderiyor ve uygulamaları benzer açıklar için taramayı teklif ediyor; adını yazarın siyah Pomeranian köpeği Ember'dan alıyor ki, yazının açılış hikâyesine göre Ember kendisine en üst güvenlik görevini vermiş.

Neden önemli

Bu hata modu tam da her şeyin doğru yapılandırılmış görünmesi nedeniyle tehlikeli. RLS'yi etkinleştirmek, kullanıcıların yalnızca kendi satırlarını görebildiğini ve düzenleyebildiğini doğrulamak ve yayına almak yaygın bir iş akışıdır; bu akış sıradan testleri geçer, çünkü açık yalnızca bir istemci kasıtlı olarak bir update payload'una privileged bir alan eklediğinde ortaya çıkar. Etki alanı uygulama düzeyinde yetki yükseltmesidir: bir kullanıcının, her istemcinin zaten elinde olan public key dışında hiçbir şeye ihtiyaç duymadan tek bir istekte admin hakları basması. Çıkarılacak ders Supabase'ın ötesinde genellenebilir — authorization satır başına olduğu kadar sütun başına da düşünülerek yapılmalıdır ve yetkiyi kodlayan her alan, güvenilmeyen istemcilerin erişebildiği tabloların dışında tutulmalıdır.