gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-ci-cd/supabase-security.md'] to uk

Browse Source
This commit is contained in:
Translator
2025-09-29 23:07:31 +00:00
parent 0bb6d5300f
commit bdeade9f6b
1 changed files with 153 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-ci-cd/supabase-security.md
+153 -43
View File
@@ -1,49 +1,49 @@
# Supabase Security
# Supabase Безпека
{{#include ../banners/hacktricks-training.md}}
## Основна інформація
Згідно з їх [**цільовою сторінкою**](https://supabase.com/): Supabase є відкритим джерелом альтернативою Firebase. Розпочніть свій проект з бази даних Postgres, аутентифікації, миттєвих API, Edge Functions, підписок в реальному часі, зберігання та векторних вбудовувань.
As per their [**landing page**](https://supabase.com/): Supabase is an open source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, Storage, and Vector embeddings.
### Піддомен
### Субдомен
В основному, коли створюється проект, користувач отримає піддомен supabase.co, наприклад: **`jnanozjdybtpqgcwhdiz.supabase.co`**
Коли створюється проєкт, користувач отримає субдомен supabase.co, наприклад: **`jnanozjdybtpqgcwhdiz.supabase.co`**
## **Конфігурація бази даних**
> [!TIP]
> **Ці дані можна отримати за посиланням, наприклад `https://supabase.com/dashboard/project/<project-id>/settings/database`**
> **This data can be accessed from a link like `https://supabase.com/dashboard/project/<project-id>/settings/database`**
Ця **база даних** буде розгорнута в певному регіоні AWS, і для підключення до неї можна використовувати: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (це було створено в us-west-1).\
Пароль - це **пароль, який користувач ввів** раніше.
Ця **база даних** буде розгорнута в певному регіоні AWS, і для підключення до неї можна використовувати: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (цей був створений в us-west-1).\
Пароль — це **пароль, який користувач встановив** раніше.
Отже, оскільки піддомен є відомим і використовується як ім'я користувача, а регіони AWS обмежені, можливо, варто спробувати **брутфорсити пароль**.
Тому, оскільки субдомен відомий і використовується як ім'я користувача, а регіони AWS обмежені, можливо спробувати **brute force the password**.
Цей розділ також містить опції для:
- Скидання пароля бази даних
- Налаштування пулінгу з'єднань
- Налаштування SSL: Відхилити з'єднання в чистому тексті (за замовчуванням вони увімкнені)
- Налаштування SSL: відхиляти підключення у відкритому тексті (за замовчуванням вони дозволені)
- Налаштування розміру диска
- Застосування мережевих обмежень і заборон
- Застосування мережевих обмежень та блокувань
## Конфігурація API
> [!TIP]
> **Ці дані можна отримати за посиланням, наприклад `https://supabase.com/dashboard/project/<project-id>/settings/api`**
> **This data can be accessed from a link like `https://supabase.com/dashboard/project/<project-id>/settings/api`**
URL для доступу до API supabase у вашому проекті буде виглядати так: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
URL для доступу до supabase API у вашому проєкті буде виглядати так: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
### анонімні API ключі
### anon API ключі
Він також згенерує **анонімний API ключ** (`role: "anon"`), наприклад: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk`, який застосування повинно використовувати для контакту з API ключем, що був відкритий у нашому прикладі.
Вона також згенерує **anon API key** (`role: "anon"`), наприклад: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk`, який застосунок має використовувати, щоб звертатися до API, наведеного в нашому прикладі в
Можна знайти API REST для контакту з цим API в [**документації**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server), але найцікавіші кінцеві точки будуть:
It's possible to find the API REST to contact this API in the [**docs**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server), but the most interesting endpoints would be:
<details>
<summary>Signup (/auth/v1/signup)</summary>
<summary>Реєстрація (/auth/v1/signup)</summary>
```
POST /auth/v1/signup HTTP/2
Host: id.io.net
@@ -72,7 +72,7 @@ Priority: u=1, i
<details>
<summary>Увійти (/auth/v1/token?grant_type=password)</summary>
<summary>Вхід (/auth/v1/token?grant_type=password)</summary>
```
POST /auth/v1/token?grant_type=password HTTP/2
Host: hypzbtgspjkludjcnjxl.supabase.co
@@ -99,61 +99,171 @@ Priority: u=1, i
```
</details>
Отже, коли ви виявите клієнта, який використовує supabase з піддоменом, який їм було надано (можливо, що піддомен компанії має CNAME на їх supabase піддомен), ви можете спробувати **створити новий обліковий запис на платформі, використовуючи supabase API**.
Отже, коли ви виявляєте клієнта, який використовує supabase з піддоменом, що йому було надано (можливо, піддомен компанії має CNAME, спрямований на їхній піддомен supabase), ви можете спробувати **створити новий акаунт на платформі, використовуючи supabase API**.
### секретні / service_role API ключі
### секретні / service_role api keys
Секретний API ключ також буде згенеровано з **`role: "service_role"`**. Цей API ключ повинен бути секретним, оскільки він зможе обійти **Row Level Security**.
Також буде згенеровано секретний API key з **`role: "service_role"`**. Цей API key має залишатися секретним, оскільки він дозволяє обходити **Row Level Security**.
API ключ виглядає так: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354`
The API key looks like this: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354`
### JWT Secret
**JWT Secret** також буде згенеровано, щоб програма могла **створювати та підписувати користувацькі JWT токени**.
Також буде згенеровано **JWT Secret**, щоб додаток міг **створювати та підписувати кастомні JWT tokens**.
## Аутентифікація
### Реєстрація
> [!TIP]
> За **замовчуванням** supabase дозволить **новим користувачам створювати облікові записи** у вашому проекті, використовуючи раніше згадані API кінцеві точки.
> За **замовчуванням** supabase дозволяє **новим користувачам створювати акаунти** у вашому проєкті, використовуючи вказані вище API endpoints.
Однак ці нові облікові записи за замовчуванням **потрібно буде підтвердити свою електронну адресу**, щоб мати можливість увійти в обліковий запис. Можна активувати **"Дозволити анонімні входи"**, щоб дозволити людям входити без підтвердження своєї електронної адреси. Це може надати доступ до **неочікуваних даних** (вони отримують ролі `public` та `authenticated`).\
Це дуже погана ідея, оскільки supabase стягує плату за активного користувача, тому люди можуть створювати користувачів і входити, а supabase стягне плату за них:
Однак ці нові акаунти за замовчуванням **повинні підтвердити свою електронну пошту**, щоб мати змогу увійти в акаунт. Можна увімкнути опцію **"Allow anonymous sign-ins"**, щоб дозволити людям входити без підтвердження email. Це може надати доступ до **неочікуваних даних** (вони отримують ролі `public` та `authenticated`).\
Це дуже погана ідея, оскільки supabase стягує плату за активного користувача, тож люди можуть створювати користувачів і заходити в систему, а supabase буде стягувати за них плату:
<figure><img src="../images/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
#### Auth: Server-side signup enforcement
Приховування кнопки реєстрації на фронтенді недостатньо. Якщо **Auth сервер все ще дозволяє реєстрацію**, зловмисник може викликати API напряму з використанням публічного `anon` ключа і створити довільних користувачів.
Швидкий тест (з неавторизованого клієнта):
```bash
curl -X POST \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-d '{"email":"attacker@example.com","password":"Sup3rStr0ng!"}' \
https://<PROJECT_REF>.supabase.co/auth/v1/signup
```
Expected hardening:
- Disable email/password signups in the Dashboard: Authentication → Providers → Email → Disable sign ups (invite-only), or set the equivalent GoTrue setting.
- Перевірте, що API тепер повертає 4xx на попередній виклик і новий користувач не створюється.
- Якщо ви покладаєтесь на invites або SSO, переконайтесь, що всі інші провайдери вимкнені, якщо вони явно не потрібні.
## RLS and Views: Write bypass via PostgREST
Використання Postgres VIEW для «приховування» чутливих стовпців і експонування його через PostgREST може змінити спосіб оцінки привілеїв. У PostgreSQL:
- Ordinary views execute with the privileges of the view owner by default (definer semantics). In PG ≥15 you can opt into `security_invoker`.
- Row Level Security (RLS) applies on base tables. Table owners bypass RLS unless `FORCE ROW LEVEL SECURITY` is set on the table.
- Updatable views can accept INSERT/UPDATE/DELETE that are then applied to the base table. Without `WITH CHECK OPTION`, writes that don’t match the view predicate may still succeed.
Risk pattern observed in the wild:
- A reduced-column view is exposed through Supabase REST and granted to `anon`/`authenticated`.
- PostgREST allows DML on the updatable view and the operation is evaluated with the view owner’s privileges, effectively bypassing the intended RLS policies on the base table.
- Result: low-privileged clients can mass-edit rows (e.g., profile bios/avatars) they should not be able to modify.
Illustrative write via view (attempted from a public client):
```bash
curl -X PATCH \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-H "Prefer: return=representation" \
-d '{"bio":"pwned","avatar_url":"https://i.example/pwn.png"}' \
"https://<PROJECT_REF>.supabase.co/rest/v1/users_view?id=eq.<victim_user_id>"
```
Hardening checklist for views and RLS:
- Віддавайте перевагу експонуванню базових таблиць з явними наданнями найменших привілеїв і точними RLS-політиками.
- Якщо потрібно експонувати представлення:
- Зробіть його неоновлюваним (наприклад, включіть вирази/joins) або забороніть `INSERT/UPDATE/DELETE` на представленні для всіх ненадійних ролей.
- Забезпечте виконання `ALTER VIEW <v> SET (security_invoker = on)` — щоб використовувалися привілеї того, хто викликає (invoker), замість привілеїв власника.
- Для базових таблиць використовуйте `ALTER TABLE <t> FORCE ROW LEVEL SECURITY;` — щоб навіть власники підлягали RLS.
- Якщо дозволяєте запис через updatable view, додайте `WITH [LOCAL|CASCADED] CHECK OPTION` і доповнювальні RLS на базових таблицях, щоб гарантувати, що записуються/змінюються лише дозволені рядки.
- В Supabase уникайте надання `anon`/`authenticated` будь-яких прав на запис у представлення, якщо ви не перевірили end-to-end поведінку за допомогою тестів.
Detection tip:
- Від імені `anon` та тестового користувача `authenticated` спробуйте виконати всі CRUD-операції проти кожної відкритої таблиці/представлення. Будь-який успішний запис у місці, де ви очікували відмови, свідчить про неправильну конфігурацію.
### OpenAPI-driven CRUD probing from anon/auth roles
PostgREST exposes an OpenAPI document that you can use to enumerate all REST resources, then automatically probe allowed operations from low-privileged roles.
Fetch the OpenAPI (works with the public anon key):
```bash
curl -s https://<PROJECT_REF>.supabase.co/rest/v1/ \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Accept: application/openapi+json" | jq '.paths | keys[]'
```
Шаблон перевірки (приклади):
- Прочитати один рядок (очікується 401/403/200 залежно від RLS):
```bash
curl -s "https://<PROJECT_REF>.supabase.co/rest/v1/<table>?select=*&limit=1" \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>"
```
- Перевірте, що UPDATE заблоковано (використовуйте неіснуючий filter, щоб уникнути зміни даних під час тестування):
```bash
curl -i -X PATCH \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-H "Prefer: return=minimal" \
-d '{"__probe":true}' \
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>?id=eq.00000000-0000-0000-0000-000000000000"
```
- Тест INSERT заблоковано:
```bash
curl -i -X POST \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-H "Prefer: return=minimal" \
-d '{"__probe":true}' \
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>"
```
- Перевірте, що DELETE заблоковано:
```bash
curl -i -X DELETE \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>?id=eq.00000000-0000-0000-0000-000000000000"
```
Рекомендації:
- Автоматизуйте попередні перевірки для обох `anon` та мінімально `authenticated` користувачів і інтегруйте їх у CI, щоб виявляти регресії.
- Розглядайте кожну відкриту table/view/function як первинну поверхню. Не припускайте, що view «успадковує» ту ж RLS політику, що й її базові таблиці.
### Паролі та сесії
Можна вказати мінімальну довжину пароля (за замовчуванням), вимоги (за замовчуванням немає) та заборонити використання зламаних паролів.\
Рекомендується **покращити вимоги, оскільки стандартні є слабкими**.
Можна вказати мінімальну довжину пароля (за замовчуванням), вимоги (за замовчуванням відсутні) та заборонити використання leaked passwords.\
Рекомендується **покращити вимоги, оскільки значення за замовчуванням слабкі**.
- Сесії користувачів: Можна налаштувати, як працюють сесії користувачів (тайм-аути, 1 сесія на користувача...)
- Захист від ботів та зловживань: Можна активувати Captcha.
- User Sessions: Можна налаштувати, як працюють сесії користувачів (таймаути, 1 сесія на користувача...)
- Bot and Abuse Protection: Можна увімкнути Captcha.
### Налаштування SMTP
### SMTP Settings
Можна налаштувати SMTP для надсилання електронних листів.
Можна вказати SMTP для відправки листів.
### Розширені налаштування
### Advanced Settings
- Встановити час закінчення терміну дії токенів доступу (3600 за замовчуванням)
- Встановити виявлення та відкликання потенційно скомпрометованих токенів оновлення та тайм-аут
- MFA: Вказати, скільки факторів MFA можна зареєструвати одночасно на одного користувача (10 за замовчуванням)
- Максимальна кількість прямих з'єднань з базою даних: Максимальна кількість з'єднань, що використовуються для аутентифікації (10 за замовчуванням)
- Максимальна тривалість запиту: Максимальний час, дозволений для запиту Auth (10 с за замовчуванням)
- Set expire time to access tokens (3600 by default)
- Set to detect and revoke potentially compromised refresh tokens and timeout
- MFA: Вказати, скільки MFA факторів може бути зареєстровано одночасно для одного користувача (за замовчуванням 10)
- Max Direct Database Connections: Максимальна кількість з'єднань, що використовуються для auth (за замовчуванням 10)
- Max Request Duration: Максимальний час для Auth request (за замовчуванням 10s)
## Сховище
## Storage
> [!TIP]
> Supabase дозволяє **зберігати файли** та робити їх доступними через URL (використовує S3 контейнери).
> Supabase дозволяє **зберігати файли** і робити їх доступними за URL (використовує S3 buckets).
- Встановити обмеження на розмір завантажуваного файлу (за замовчуванням 50 МБ)
- З'єднання S3 надається з URL, як: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
- Можна **запросити S3 ключ доступу**, який складається з `access key ID` (наприклад, `a37d96544d82ba90057e0e06131d0a7b`) та `secret access key` (наприклад, `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`)
- Встановіть обмеження на розмір файлу для завантаження (за замовчуванням 50MB)
- The S3 connection is given with a URL like: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
- Можна **запитати S3 access key** які складаються з `access key ID` (e.g. `a37d96544d82ba90057e0e06131d0a7b`) та `secret access key` (e.g. `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`)
## Edge Functions
Можна також **зберігати секрети** в supabase, які будуть **доступні через edge functions** (їх можна створювати та видаляти з вебу, але неможливо отримати їх значення безпосередньо).
У Supabase також можна **зберігати secrets**, які будуть **доступні by edge functions** (їх можна створювати та видаляти з веба, але неможливо безпосередньо прочитати їх значення).
## References
- [Building Hacker Communities: Bug Bounty Village, getDisclosed’s Supabase Misconfig, and the LHE Squad (Ep. 133) – YouTube](https://youtu.be/NI-eXMlXma4)
- [Critical Thinking Podcast – Episode 133 page](https://www.criticalthinkingpodcast.io/episode-133-building-hacker-communities-bug-bounty-village-getdisclosed-and-the-lhe-squad/)
- [Supabase: Row Level Security (RLS)](https://supabase.com/docs/guides/auth/row-level-security)
- [PostgreSQL: Row Security Policies](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)
- [PostgreSQL: CREATE VIEW (security_invoker, check option)](https://www.postgresql.org/docs/current/sql-createview.html)
- [PostgREST: OpenAPI documentation](https://postgrest.org/en/stable/references/api.html#openapi-documentation)
{{#include ../banners/hacktricks-training.md}}