mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-06 04:41:21 -08:00
Translated ['', 'src/pentesting-ci-cd/supabase-security.md'] to hi
This commit is contained in:
Translator
@@ -2,44 +2,44 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## मूल जानकारी
|
||||
## बुनियादी जानकारी
|
||||
|
||||
उनके [**लैंडिंग पृष्ठ**](https://supabase.com/) के अनुसार: Supabase एक ओपन-सोर्स Firebase विकल्प है। अपने प्रोजेक्ट को एक Postgres डेटाबेस, प्रमाणीकरण, तात्कालिक APIs, Edge Functions, रीयलटाइम सब्सक्रिप्शन, स्टोरेज, और वेक्टर एम्बेडिंग के साथ शुरू करें।
|
||||
As per their [**landing page**](https://supabase.com/): Supabase is an open source Firebase alternative. अपने प्रोजेक्ट की शुरुआत Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, Storage, and Vector embeddings के साथ करें।
|
||||
|
||||
### उपडोमेन
|
||||
### Subdomain
|
||||
|
||||
बुनियादी रूप से जब एक प्रोजेक्ट बनाया जाता है, तो उपयोगकर्ता को एक supabase.co उपडोमेन प्राप्त होगा जैसे: **`jnanozjdybtpqgcwhdiz.supabase.co`**
|
||||
जब कोई project बनाया जाता है, user को एक supabase.co subdomain मिलेगा जैसे: **`jnanozjdybtpqgcwhdiz.supabase.co`**
|
||||
|
||||
## **डेटाबेस कॉन्फ़िगरेशन**
|
||||
|
||||
> [!TIP]
|
||||
> **इस डेटा को एक लिंक से एक्सेस किया जा सकता है जैसे `https://supabase.com/dashboard/project/<project-id>/settings/database`**
|
||||
> **यह डेटा इस तरह के लिंक से एक्सेस किया जा सकता है `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 में बनाया गया था)।\
|
||||
पासवर्ड वह **पासवर्ड है जो उपयोगकर्ता ने पहले डाला था**।
|
||||
यह **database** किसी AWS region में deploy होगा, और इसे कनेक्ट करने के लिए आप इस तरह कनेक्ट कर सकते हैं: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (this was crated in us-west-1).\
|
||||
पासवर्ड वह **password है जो user ने पहले डाला था**।
|
||||
|
||||
इसलिए, चूंकि उपडोमेन एक ज्ञात है और इसका उपयोग उपयोगकर्ता नाम के रूप में किया जाता है और AWS क्षेत्र सीमित हैं, यह संभव हो सकता है कि **पासवर्ड को ब्रूट फोर्स करने की कोशिश की जाए**।
|
||||
इसलिए, चूंकि subdomain ज्ञात है और इसे username के रूप में उपयोग किया जाता है और AWS regions सीमित हैं, इसलिए संभव है कि पासवर्ड को **brute force the password** करने की कोशिश की जा सके।
|
||||
|
||||
इस अनुभाग में निम्नलिखित विकल्प भी शामिल हैं:
|
||||
इस सेक्शन में निम्न विकल्प भी होते हैं:
|
||||
|
||||
- डेटाबेस पासवर्ड रीसेट करें
|
||||
- कनेक्शन पूलिंग कॉन्फ़िगर करें
|
||||
- SSL कॉन्फ़िगर करें: प्लेन-टेक्स्ट कनेक्शनों को अस्वीकार करें (डिफ़ॉल्ट रूप से ये सक्षम होते हैं)
|
||||
- डिस्क आकार कॉन्फ़िगर करें
|
||||
- नेटवर्क प्रतिबंध और प्रतिबंध लागू करें
|
||||
- Configure SSL: प्लेन-टेक्स्ट कनेक्शनों को अस्वीकार करें (डिफ़ॉल्ट रूप से वे सक्षम होते हैं)
|
||||
- डिस्क साइज कॉन्फ़िगर करें
|
||||
- नेटवर्क प्रतिबंध और बैन लागू करें
|
||||
|
||||
## API कॉन्फ़िगरेशन
|
||||
|
||||
> [!TIP]
|
||||
> **इस डेटा को एक लिंक से एक्सेस किया जा सकता है जैसे `https://supabase.com/dashboard/project/<project-id>/settings/api`**
|
||||
> **यह डेटा इस तरह के लिंक से एक्सेस किया जा सकता है `https://supabase.com/dashboard/project/<project-id>/settings/api`**
|
||||
|
||||
आपके प्रोजेक्ट में Supabase API तक पहुँचने के लिए URL होगा: `https://jnanozjdybtpqgcwhdiz.supabase.co`।
|
||||
अपने प्रोजेक्ट के supabase API तक पहुँचने के लिए URL इस तरह होगा: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
|
||||
|
||||
### एनोन API कुंजी
|
||||
### anon api keys
|
||||
|
||||
यह एक **एनोन API कुंजी** (`role: "anon"`), जैसे: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` उत्पन्न करेगा, जिसका उपयोग एप्लिकेशन को हमारे उदाहरण में प्रदर्शित API कुंजी से संपर्क करने के लिए करना होगा।
|
||||
यह एक **anon API key** (`role: "anon"`), जैसे: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` भी जेनरेट करेगा, जिसे application को API से संपर्क करने के लिए उपयोग करना होगा जो हमारे example में एक्सपोज़ किया गया है
|
||||
|
||||
इस API से संपर्क करने के लिए API REST को [**डॉक्स**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server) में पाया जा सकता है, लेकिन सबसे दिलचस्प एंडपॉइंट होंगे:
|
||||
इस API से संपर्क करने के लिए API REST आप [**docs**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server) में पा सकते हैं, लेकिन सबसे दिलचस्प endpoints होंगे:
|
||||
|
||||
<details>
|
||||
|
||||
@@ -99,61 +99,171 @@ Priority: u=1, i
|
||||
```
|
||||
</details>
|
||||
|
||||
तो, जब भी आप किसी क्लाइंट को supabase का उपयोग करते हुए पाते हैं, जो उपडोमेन उन्हें दिया गया है (यह संभव है कि कंपनी का एक उपडोमेन उनके supabase उपडोमेन पर CNAME हो), आप **supabase API का उपयोग करके प्लेटफॉर्म में एक नया खाता बनाने की कोशिश कर सकते हैं**।
|
||||
तो, जब भी आप किसी क्लाइंट को उनके दिए गए सबडोमेन के साथ supabase का उपयोग करते हुए पाते हैं (संभव है कि कंपनी का कोई सबडोमेन उनके supabase सबडोमेन पर CNAME कर दिया गया हो), तो आप **supabase API का उपयोग करके प्लेटफ़ॉर्म पर एक नया अकाउंट बना कर देख सकते हैं**।
|
||||
|
||||
### गुप्त / सेवा_भूमिका 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 गुप्त
|
||||
### JWT Secret
|
||||
|
||||
एक **JWT गुप्त** भी उत्पन्न होगा ताकि एप्लिकेशन **कस्टम JWT टोकन बना और साइन कर सके**।
|
||||
एक **JWT Secret** भी जनरेट किया जाएगा ताकि एप्लिकेशन **कस्टम JWT टोकन बना कर साइन** कर सके।
|
||||
|
||||
## प्रमाणीकरण
|
||||
|
||||
### साइनअप
|
||||
### Signups
|
||||
|
||||
> [!TIP]
|
||||
> **डिफ़ॉल्ट** रूप से supabase आपके प्रोजेक्ट पर **नए उपयोगकर्ताओं को खाते बनाने की अनुमति देगा** जो पहले उल्लेखित API एंडपॉइंट्स का उपयोग करते हैं।
|
||||
> डिफ़ॉल्ट रूप से supabase आपके प्रोजेक्ट पर पहले बताए गए API endpoints का उपयोग करके **नए उपयोगकर्ताओं को अकाउंट बनाने** की अनुमति देगा।
|
||||
|
||||
हालांकि, इन नए खातों को, डिफ़ॉल्ट रूप से, **अपने ईमेल पते को मान्य करना होगा** ताकि वे खाते में लॉगिन कर सकें। यह संभव है कि **"अनाम साइन-इन की अनुमति दें"** सक्षम किया जाए ताकि लोग बिना अपने ईमेल पते को मान्य किए लॉगिन कर सकें। इससे **अप्रत्याशित डेटा** तक पहुंच मिल सकती है (उन्हें `public` और `authenticated` भूमिकाएँ मिलती हैं)।\
|
||||
यह एक बहुत बुरी विचार है क्योंकि supabase सक्रिय उपयोगकर्ता के लिए शुल्क लेता है, इसलिए लोग उपयोगकर्ता बना सकते हैं और लॉगिन कर सकते हैं और supabase उन पर शुल्क लेगा:
|
||||
हालाँकि, ये नए अकाउंट्स, डिफ़ॉल्ट रूप से, **लॉगिन करने के लिए अपना ईमेल पता सत्यापित करना आवश्यक होगा**। यह संभव है कि **"Allow anonymous sign-ins"** सक्षम किया जा सके ताकि लोग अपना ईमेल सत्यापित किए बिना लॉगिन कर सकें। इससे उन्हें **अनपेक्षित डेटा** तक पहुंच मिल सकती है (उन्हें `public` और `authenticated` रोल मिलते हैं)।\
|
||||
यह बहुत बुरा विचार है क्योंकि supabase सक्रिय उपयोगकर्ता के आधार पर चार्ज करता है, इसलिए लोग यूज़र्स बना कर लॉगिन कर सकते हैं और supabase उन पर चार्ज कर देगा:
|
||||
|
||||
<figure><img src="../images/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### Auth: सर्वर-साइड साइनअप प्रवर्तन
|
||||
|
||||
Frontend में signup बटन छिपाना पर्याप्त नहीं है। अगर **Auth सर्वर अभी भी signups की अनुमति देता है**, तो एक हमलावर सीधे API को सार्वजनिक `anon` key के साथ कॉल कर सकता है और मनमाने उपयोगकर्ता बना सकता है।
|
||||
|
||||
त्वरित परीक्षण (एक अनप्रमाणित क्लाइंट से):
|
||||
```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.
|
||||
- Verify the API now returns 4xx to the previous call and no new user is created.
|
||||
- If you rely on invites or SSO, ensure all other providers are disabled unless explicitly needed.
|
||||
|
||||
## RLS and Views: Write bypass via PostgREST
|
||||
|
||||
Using a Postgres VIEW to “hide” sensitive columns and exposing it via PostgREST can change how privileges are evaluated. In 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 नीतियों के साथ एक्सपोज़ करना प्राथमिकता दें।
|
||||
- यदि आपको किसी view को एक्सपोज़ करना ही है:
|
||||
- इसे non-updatable बनाएं (उदा., expressions/joins शामिल करके) या सभी untrusted roles के लिए view पर `INSERT/UPDATE/DELETE` को deny करें।
|
||||
- लागू करें `ALTER VIEW <v> SET (security_invoker = on)` ताकि owner के बजाय invoker के privileges का उपयोग हो।
|
||||
- बेस टेबल्स पर `ALTER TABLE <t> FORCE ROW LEVEL SECURITY;` का उपयोग करें ताकि मालिक भी RLS के अधीन हों।
|
||||
- अगर updatable view के माध्यम से लिखने की अनुमति दे रहे हैं, तो `WITH [LOCAL|CASCADED] CHECK OPTION` और बेस टेबल्स पर समकक्ष RLS जोड़ें ताकि केवल अनुमत rows ही लिखे/बदलें जा सकें।
|
||||
- Supabase में, तब तक `anon`/`authenticated` को views पर कोई write privileges न दें जब तक आपने end-to-end व्यवहार को tests से सत्यापित न कर लिया हो।
|
||||
|
||||
Detection tip:
|
||||
- `anon` और एक `authenticated` टेस्ट यूज़र से, हर एक्सपोज्ड table/view के खिलाफ सभी CRUD ऑपरेशन्स आजमाएँ। जहाँ denial की उम्मीद थी वहां कोई सफल write हो तो वह misconfiguration का संकेत है।
|
||||
|
||||
### OpenAPI-driven CRUD probing from anon/auth roles
|
||||
|
||||
PostgREST एक OpenAPI दस्तावेज़ एक्सपोज़ करता है जिसका उपयोग आप सभी REST resources को सूचीबद्ध करने के लिए कर सकते हैं, और फिर 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[]'
|
||||
```
|
||||
Probe pattern (examples):
|
||||
- एक पंक्ति पढ़ें (RLS के अनुसार 401/403/200 की उम्मीद):
|
||||
```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"
|
||||
```
|
||||
Recommendations:
|
||||
- पहले किए गए प्रोब्स को `anon` और न्यूनतम रूप से `authenticated` उपयोगकर्ता दोनों के लिए ऑटोमेट करें और रिग्रेशन पकड़ने के लिए उन्हें CI में इंटीग्रेट करें।
|
||||
- प्रत्येक एक्सपोज़ की गई टेबल/व्यू/फ़ंक्शन को एक प्रथम-श्रेणी सतह की तरह मानें। यह न मानें कि कोई view उसके base tables के समान RLS स्थिति “inherits” करता है।
|
||||
|
||||
### पासवर्ड और सत्र
|
||||
|
||||
यह न्यूनतम पासवर्ड लंबाई (डिफ़ॉल्ट द्वारा), आवश्यकताओं (डिफ़ॉल्ट द्वारा कोई नहीं) और लीक हुए पासवर्ड का उपयोग करने से रोकने के लिए संकेत देने की संभावना है।\
|
||||
यह अनुशंसा की जाती है कि **डिफ़ॉल्ट आवश्यकताओं को सुधारें क्योंकि वे कमजोर हैं**।
|
||||
यह संभव है कि न्यूनतम पासवर्ड लंबाई (डिफ़ॉल्ट रूप से), आवश्यकताएँ (डिफ़ॉल्ट रूप से नहीं) और leaked पासवर्ड का उपयोग न करने का विकल्प निर्धारित किया जा सके।\
|
||||
सुझाया जाता है कि **डिफ़ॉल्ट आवश्यकताओं को सुधारें क्योंकि वे कमजोर हैं**।
|
||||
|
||||
- उपयोगकर्ता सत्र: यह निर्धारित करना संभव है कि उपयोगकर्ता सत्र कैसे काम करते हैं (टाइमआउट, प्रति उपयोगकर्ता 1 सत्र...)
|
||||
- बॉट और दुरुपयोग सुरक्षा: कैप्चा सक्षम करना संभव है।
|
||||
- User Sessions: यह कॉन्फ़िगर करना संभव है कि user sessions कैसे काम करें (timeouts, 1 session per user...)
|
||||
- Bot and Abuse Protection: Captcha सक्षम किया जा सकता है।
|
||||
|
||||
### SMTP सेटिंग्स
|
||||
### SMTP Settings
|
||||
|
||||
ईमेल भेजने के लिए SMTP सेट करना संभव है।
|
||||
|
||||
### उन्नत सेटिंग्स
|
||||
|
||||
- एक्सेस टोकन के लिए समाप्ति समय सेट करें (डिफ़ॉल्ट 3600)
|
||||
- संभावित रूप से समझौता किए गए रिफ्रेश टोकन का पता लगाने और रद्द करने के लिए सेट करें और टाइमआउट
|
||||
- MFA: यह इंगित करें कि प्रति उपयोगकर्ता एक बार में कितने MFA कारक पंजीकृत किए जा सकते हैं (डिफ़ॉल्ट 10)
|
||||
- अधिकतम डायरेक्ट डेटाबेस कनेक्शन: प्रमाणीकरण के लिए उपयोग किए जाने वाले कनेक्शनों की अधिकतम संख्या (डिफ़ॉल्ट 10)
|
||||
- अधिकतम अनुरोध अवधि: अधिकतम समय जो एक प्रमाणीकरण अनुरोध के लिए अनुमति दी जाती है (डिफ़ॉल्ट 10 सेकंड)
|
||||
- access tokens के लिए expire time सेट करें (3600 डिफ़ॉल्ट)
|
||||
- संभावित रूप से compromised refresh tokens का पता लगाने और revoke करने तथा timeout सेट करने का विकल्प
|
||||
- MFA: यह निर्दिष्ट करें कि प्रति उपयोगकर्ता एक साथ कितने MFA factors enroll किए जा सकते हैं (डिफ़ॉल्ट 10)
|
||||
- Max Direct Database Connections: auth के लिए उपयोग किए जाने वाले कनेक्शनों की अधिकतम संख्या (डिफ़ॉल्ट 10)
|
||||
- Max Request Duration: Auth request के लिए अनुमत अधिकतम समय (डिफ़ॉल्ट 10s)
|
||||
|
||||
## संग्रहण
|
||||
## Storage
|
||||
|
||||
> [!TIP]
|
||||
> Supabase **फाइलों को स्टोर करने** और उन्हें URL के माध्यम से सुलभ बनाने की अनुमति देता है (यह S3 बकेट का उपयोग करता है)।
|
||||
> Supabase आपको **फ़ाइलें स्टोर करने** की अनुमति देता है और उन्हें URL के माध्यम से उपलब्ध कराता है (यह S3 buckets का उपयोग करता है)।
|
||||
|
||||
- अपलोड फ़ाइल आकार सीमा सेट करें (डिफ़ॉल्ट 50MB)
|
||||
- S3 कनेक्शन एक URL के साथ दिया गया है जैसे: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
|
||||
- यह **S3 एक्सेस कुंजी** का अनुरोध करना संभव है जो एक `access key ID` (जैसे `a37d96544d82ba90057e0e06131d0a7b`) और एक `secret access key` (जैसे `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`) द्वारा बनाई जाती है।
|
||||
- अपलोड फ़ाइल आकार सीमा सेट करें (डिफ़ॉल्ट 50MB है)
|
||||
- S3 कनेक्शन एक URL के साथ दिया जाता है जैसे: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
|
||||
- आप **request S3 access key** कर सकते हैं जो एक `access key ID` (उदा. `a37d96544d82ba90057e0e06131d0a7b`) और एक `secret access key` (उदा. `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`) से बनती हैं
|
||||
|
||||
## एज फ़ंक्शंस
|
||||
## Edge Functions
|
||||
|
||||
यह संभव है कि **supabase में गुप्त जानकारी** भी स्टोर की जा सके जो **एज फ़ंक्शंस द्वारा सुलभ होगी** (इन्हें वेब से बनाया और हटाया जा सकता है, लेकिन इनका मूल्य सीधे एक्सेस करना संभव नहीं है)।
|
||||
supabase में भी **store secrets** करना संभव है जो **accessible by edge functions** होंगे (इन्हें web से बनाया और deleted किया जा सकता है, लेकिन उनके मान तक सीधे पहुंचना संभव नहीं है)।
|
||||
|
||||
## 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}}
|
||||
|
||||
Reference in New Issue
Block a user