🔐 **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

🔐 **حمله 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

# وقتی یه آپستروف کل دیتابیس رو لو داد

سال ۲۰۰۸، هکری به اسم Alberto Gonzalez با تیمش بیش از ۱۳۰ میلیون شماره کارت اعتباری رو از شرکت Heartland Payment Systems دزدید. نقطه‌ی ورود؟ یه SQL Injection ساده روی یه فرم ورودی که کسی فکرش رو نمی‌کرد.

---

ماجرا اینجاست که SQL Injection یکی از قدیمی‌ترین آسیب‌پذیری‌هاست — ولی هنوز توی OWASP Top 10 جا داره. چرا؟ چون اکثر توسعه‌دهنده‌ها ورودی کاربر رو مستقیم می‌ریزن توی کوئری. وقتی یه فرم لاگین داری که این کوئری رو اجرا می‌کنه:

SELECT * FROM users WHERE username='$input' AND password='$pass'

کافیه تو فیلد username بنویسی:

' OR '1'='1' --

کوئری می‌شه:

SELECT * FROM users WHERE username='' OR '1'='1' --' AND password='...'

شرط همیشه true می‌شه. رمز عبور چک نمی‌شه. تو داخلی.

---

اینجاست که اکثرا فکر می‌کنن تموم شد — ولی تازه شروع شده. وقتی توسعه‌دهنده‌ها می‌فهمن چه خبره، شروع می‌کنن به فیلتر کردن. کلماتی مثل SELECT`، `UNION`، --` رو بلاک می‌کنن. اینجا bypass فیلترها مطرح می‌شه.

یه تکنیک رایج اینه که از comment های inline استفاده کنی تا کلمات کلیدی رو بشکنی:

UN/**/ION SEL/**/ECT null, username, password FROM users--

یا از تغییر case استفاده کنی چون بعضی فیلترها case-sensitive هستن:

uNiOn SeLeCt null, table_name FROM information_schema.tables--

یا اگه فیلتر فضای خالی رو می‌گیره، از %09 یا /**/ به عنوان جایگزین استفاده کنی.

---

نکته‌ای که خیلی‌ها نادیده می‌گیرن اینه: **SQL Injection فقط توی فرم‌ها نیست.** هدرهای HTTP، کوکی‌ها، پارامترهای URL — هر جایی که داده از کاربر گرفته می‌شه و وارد کوئری می‌شه، سطح حمله‌ته. ابزاری مثل sqlmap همین سطح‌ها رو به صورت خودکار اسکن می‌کنه — ولی قبل از اینکه به ابزار تکیه کنی، باید بدونی دستی چطور کار می‌کنه. ابزار بدون درک، فقط سروصداست.

#WebHacking

@codacker_ir

هک یک ابزار نیست ، یک طرز فکره