🔐 **SQL Injection در WHERE Clause: جایی که فیلتر می‌شکند**

وقتی یه برنامه‌نویس فکر می‌کنه کافیه ورودی کاربر رو مستقیم توی کوئری بذاره، دقیقاً همون‌جاست که شما وارد می‌شید.

**WHERE Clause چرا آسیب‌پذیره؟**
بیشتر SQLi های کلاسیک همین‌جا اتفاق میفته. وقتی اپلیکیشن ورودی شما رو بدون sanitization توی شرط WHERE قرار میده، می‌تونید منطق کوئری رو کاملاً تغییر بدید. از bypass authentication تا استخراج کل دیتابیس.

**تشخیص اولیه**
با یه پیلود ساده شروع کنید. اگه error گرفتید یا رفتار صفحه تغییر کرد، احتمالاً injectable هست. نکته کلیدی: همیشه اول تعداد ستون‌ها رو با `ORDER BY` پیدا کنید، بعد برید سراغ `UNION SELECT`.

**اشتباه رایج تسترها**
خیلی‌ها فقط `' OR '1'='1` رو تست می‌کنن و ول می‌کنن. اما اگه اپلیکیشن فقط یه ردیف برمی‌گردونه، باید با `LIMIT` و `OFFSET` کار کنید تا به بقیه داده‌ها برسید.

💻 **مثال عملی:**
```
# تست اولیه
GET /products?id=1'

# شناسایی تعداد ستون‌ها
GET /products?id=1 ORDER BY 3--

# استخراج داده با UNION
GET /products?id=-1 UNION SELECT null,username,password FROM users--
```

🔗 **ابزار/منبع:** sqlmap + Burp Suite برای تست سریع‌تر

#WebHacking #هک_وب #OWASP #SQLInjection

@codacker_ir

―――――――――――――――――
🎓 مسترکلاس یادگیری هک از صفر تا حرفه‌ای
🔗 codacker.ir/product/hs-masterclass

🔐 **Broken Access Control: وقتی دیوار امنیتی فقط یک پرده‌ست**

چرا IDOR سال‌هاست صدرنشین OWASP Top 10 باقی مونده؟ چون توسعه‌دهنده‌ها هنوز فکر می‌کنن مخفی کردن URL یعنی امنیت!

**Broken Access Control** یعنی کاربر بتونه به منابعی دسترسی پیدا کنه که حق نداره. ساده‌ترین شکلش IDOR (Insecure Direct Object Reference) هست: فقط با تغییر یک عدد در URL، به اطلاعات بقیه کاربرا دسترسی پیدا می‌کنی.

مشکل اصلی اینجاست که بک‌اند فرض می‌کنه اگه کاربر لاگین کرده، پس مجازه همه‌چیز رو ببینه. این فرض اشتباهه. هر درخواست باید جداگانه چک بشه که آیا این کاربر خاص، به این منبع خاص، دسترسی داره یا نه.

💻 **مثال عملی:**
```
# درخواست اصلی کاربر
GET /api/invoices/1337

# مهاجم فقط ID رو تغییر می‌ده
GET /api/invoices/1338
GET /api/invoices/1339

# اگه سرور چک نکنه ownership:
→ اطلاعات فاکتور بقیه لو می‌ره 💀
```

🔗 **ابزار/منبع:** Burp Suite + Autorize Extension

#OWASP #WebSecurity #امنیت_وب #IDOR #AccessControl

@codacker_ir

―――――――――――――――――
🎓 مسترکلاس یادگیری هک از صفر تا حرفه‌ای
🔗 codacker.ir/product/hs-masterclass

🔐 **حمله IDOR: وقتی یک عدد ساده، کل دیتابیس رو لو میده**

یکی از ساده‌ترین و در عین حال مخرب‌ترین آسیب‌پذیری‌های وب، جایی پنهانه که کمتر کسی بهش شک می‌کنه: همون عدد توی URL.

**IDOR یا Insecure Direct Object Reference** زمانی رخ میده که سرور بدون اعتبارسنجی مناسب، به یه شناسه (مثل user_id یا order_id) اعتماد می‌کنه. کافیه مهاجم عدد ۱۰۲۳ رو به ۱۰۲۴ تغییر بده و به اطلاعات کاربر دیگه دسترسی پیدا کنه.

این باگ توی OWASP Top 10 زیرمجموعه **Broken Access Control** قرار داره و دلیلش معمولاً یه اشتباه رایج توسعه‌دهنده‌هاست: فرض بر اینکه "کاربر این URL رو نمی‌بینه پس امنه" 🙄

برای تست، هر جا پارامتر عددی دیدی (id, uid, doc, file) تغییرش بده. Sequential باشه؟ جای شک داره. UUID هم همیشه امن نیست اگه predictable باشه.

💻 **مثال عملی:**
```
# درخواست اصلی کاربر
GET /api/invoices?id=4521

# تست IDOR - تغییر شناسه
GET /api/invoices?id=4522
GET /api/invoices?id=4520

# با Burp Intruder اتوماتیک تست کن
# Payload: Numbers 1-10000
```

🔗 **ابزار/منبع:** Burp Suite + Autorize Extension

#WebHacking #هک_وب #OWASP #IDOR #BugBounty

@codacker_ir

―――――――――――――――――
🎓 مسترکلاس یادگیری هک از صفر تا حرفه‌ای
🔗 codacker.ir/product/hs-masterclass