영향
행 수준 보안(RLS)이 [S1]에 제대로 적용되지 않은 경우 공격자는 애플리케이션 논리를 우회하여 데이터베이스의 레코드를 읽거나 업데이트하거나 삭제할 수 있습니다. 이로 인해 공개 익명 API 키에만 액세스할 수 있는 사용자에게 PII(개인 식별 정보) 또는 민감한 애플리케이션 데이터가 노출되는 경우가 많습니다.
근본 원인
Supabase는 Postgres 행 수준 보안을 사용하여 데이터베이스 수준에서 데이터 액세스를 관리합니다. 이는 데이터 [S1] 보안의 기본입니다. Next.js 환경에서 개발자는 서버 측 렌더링 [S2] 중에 보안을 유지하기 위해 쿠키와 세션을 올바르게 처리하는 Supabase 클라이언트를 생성해야 합니다. 취약점은 일반적으로 다음과 같은 경우에 발생합니다.
- 테이블은 RLS를 활성화하지 않은 상태에서 생성되므로 공개 익명 키 [S1]를 통해 액세스할 수 있습니다.
- Supabase 클라이언트가 Next.js에서 잘못 구성되어 사용자 인증 토큰을 데이터베이스 [S2]에 제대로 전달하지 못합니다.
- 개발자가 실수로 클라이언트 측 코드에서
service_role키를 사용하여 모든 RLS 정책 [S1]를 우회합니다.
구체적인 수정
- RLS 활성화: Supabase 데이터베이스 [S1]의 모든 테이블에 대해 행 수준 보안이 활성화되어 있는지 확인합니다.
- 정책 정의:
SELECT,INSERT,UPDATE및DELETE작업에 대한 특정 Postgres 정책을 생성하여 사용자의 UID [S1]를 기반으로 액세스를 제한합니다. - SSR 클라이언트 사용: Next.js에서 서버 측 인증 및 세션 지속성 [S2]를 올바르게 관리하는 클라이언트를 생성하려면
@supabase/ssr패키지를 구현합니다.
FixVibe가 이를 테스트하는 방법
FixVibe는 이미 배포된 앱 및 저장소 검사를 통해 이 문제를 다루고 있습니다. 패시브 baas.supabase-rls 모듈은 동일한 원본 JavaScript 번들에서 Supabase URL 및 익명 키 쌍을 검색하고, PostgREST에 공개 테이블 메타데이터를 요청하고, 제한된 읽기 전용 선택을 수행하여 고객 데이터를 변경하지 않고 익명 데이터 노출을 확인합니다. 또한 Repo 스캔은 repo.supabase.missing-rls를 실행하여 ENABLE ROW LEVEL SECURITY 없이 공개 테이블을 생성하는 SQL 마이그레이션에 플래그를 지정하고, 비밀 스캔은 브라우저에 도달하기 전에 서비스 역할 키 노출을 찾습니다.